Gsoc2021 quad float

[sinandredemption]

No description provided.

[ckormanyos]

Hi @sinandredemption I will follow your work here.

You will like the following: Check this out a preliminary first timing indication at #67

[ckormanyos]

Hi @sinandredemption I was looking at this PR and it is marked as a draft PR. Do you want review? Or simply keep going as draft?

[ckormanyos]

Hi @sinandredemption I took the liberty of (hopefully) improving or maybe fixing eval_floor directly within your branch.

The eval_floor function was not quite handling all the limbs of the quad-float type and this messed up conversion to string, therby causing numerous test failures.

Those tests in arithmetic_tests_qd.cpp are much better (but not yet fully passing) for number<cpp_quad-float<double>>. It seems like just a few problems with isinf and little stuff like that remain...

[sinandredemption]

In the case of cpp_quad_float<float>, string round-tripping broke for the number -4611686018427387904 (hex: 0xc000000000000000) due to round-off errors that could only be fixed with an extra decimal digit available. Hence the value of digits10 has been reduced by one.

[ckormanyos]

case of cpp_quad_float<float>, string round-tripping

Do you have any idea what is going on with add/sub/mul/div for cpp_quad_float<float>? Test cases are passing for instantiation with double, long double and boost::multiprecision::float128, but curiously seem to have problems with float instantiation.

[sinandredemption]

Do you have any idea what is going on with add/sub/mul/div for cpp_quad_float?

Unfortunately not. I tried to look into at (though not extremely vigorously) but couldn't find anything. See also this comment.

but curiously seem to have problems with float instantiation.

Yes. But in the string round tripping case, the cpp_quad_float<float> would technically need 29 decimal digits of precision to correctly round (I could be wrong, this needs to thorough bit-fiddling level introspection), so there is a chance that the round tripping problem was unrelated to the "bug" in subtraction.

EDIT: We can investigate further in #20 once we have a solid Boost-ified backend in place.

[ckormanyos]

the value of digits10 has been reduced by one

That seems perhaps OK. I would, however, be concerned that this might be the wrong place to fiddle around with the digits10 parameter. Maybe within the implementation(s) or offending code. Admittedly though, there has been much confusion surrounding limits of double/quad-float. So if that's best, then OK.

[sinandredemption]

Hi @sinandredemption I was looking at this PR and it is marked as a draft PR. Do you want review? Or simply keep going as draft?

Pardon me for getting lost in the flow of other discussions. I actually am looking for review, as might have been apparent by now. I will change the status of this PR soon enough.

[sinandredemption]

Maybe within the implementation(s) or offending code.

Yes, we can do that. Changing it back ASAP.

[ckormanyos]

Hi @sinandredemption I have no further review points.

Let's go with this and refine as we find steps in the future. I find that the quick fix on rd_string could be improved or perhaps I should better fix that on the Boost-utility-generic-level. But for now, full speed ahead. With my reduction of the exp10 range in the test code, let's move forward...

[ckormanyos]

Thank you Fahad. Great work on draft/first-impl of the mighty quad-float!

Cc: @sinandredemption and @cosurgi

[ckormanyos]

Hi @sinandredemption I made a few more fixe(s) for all kinds of picky compilers. Also tightened up some add/sub/mul/div test tolerances, and added Boost-like arithmetic_test_qf.cpp to CI.

Let's see how it plays in CI...

[sinandredemption]

The tolerances bits have been set to zero except for sqrt() where 3 tolerance bits are needed to pass the tests.

Could it be because of the extra precision loss in cpp_double_float since sqrt() uses it for the precision?

Makes me wonder, what it is that we are doing differently in cpp_double_float<> that makes us lose than final 1 bit of precision in add/sub, and two bits in mul/div? I think this deserves an issue of its own.

CC: @ckormanyos @cosurgi

[sinandredemption]

test_arithmetic_qf.cpp is failing now. I don't know what I've messed up, but I looked into it and it seems that the eval_log10 functions is weirdly enough evaluating logarithms incorrectly by a factor of exactly 10 in some cases (e.g. returning 0.97 instead of 9.7).

Could a specialized eval_log come to the rescue here?

[ckormanyos]

test_arithmetic_qf.cpp is failing now. I don't know what I've messed up, but I looked into it and it seems that the eval_log10 functions is weirdly enough evaluating logarithms incorrectly by a factor of exactly 10 in some cases (e.g. returning 0.97 instead of 9.7).

It's all running in my branch, essentially based exclusively on your results but with more clear tolerance parameters on some tests. The factor of 10 is what I saw from the string conversoin (I had thought). Anyway, CI in my branch is running with both df as well as qf Boost-like arithmetic tests and our own add/sub/mul/div/sqrt tests.

@sinandredemption maybe take a look there, in my branch where I straightened out a bunch of stuff...?

Could a specialized eval_log come to the rescue here?

Yes. This will be one of the things high on the list to specialize. I would rather specialize eval_log() and use a factor, but that's a trivial detail. My way of doing this is to first specialize eval_exp, then do eval_log with initial guess + 1 single Newton-Raphson step. See the work in cpp_double_float where I did exactly this method, with fine results...

[ckormanyos]

all running in my branch

@sinandredemption trust your already excellent work, Fahad. I just did a bit of tuning and cleaning in my branch. I've also taken quad-float down the road on a few spec funcs and it's looking good. I don't thing you should stray too far away...