ensure that stringstream round tripping works correctly

[cosurgi]

This line caught my attention. Maybe this one is related to this problem also, I'm not sure because I am skimming the code right now.

@sinandredemption @ckormanyos The problem is following: to fully express a binary-radix type in decimal-radix we need about 3 extra digits. See a very detailed discussion with John about this along with some code snippets in another PR.

[sinandredemption]

Hello @cosurgi

The file you mentioned has since been replaced (see this updated file). Since it does not rely on a stringstream round trip, would you suggest I create a seperate test to ensure that stringstream round tripping works correctly (possibly under test_double_float_io.cpp)?

Kind regards,
Fahad

[ckormanyos]

For the related topic of digits, digits10 and max_digits10 for double_float<T>, a separate cohesive issue for tracking is found in #21.

[cosurgi]

Yes, a specific test for roundtripping would do wonders here. Also to validate if I made no mistake in my comments in #21, as sometimes a double_float<double> will have 105 digits (if the lower one is a subnormal number) and sometimes will have 106 digits. As I mentioned in the other thread: testing all of this will be a lot easier with long double because there are no nuances regarding the implicit bits.

EDIT: as I am reading the rest of your comment I don't know why it always fails when assuming 106 digits precision. I would expect it to fail only when one component is subnormal.

EDIT2: ah! it is clear now: the implicit bit cannot participate in any of the arithmetic operations. For example addition needs a carrier bit to proceed with addition in the next part of the binary representation. But the implicit bit is sort of mute. It must be == 1. It cannot carry anything. So it cannot participate in the arithmetic operations. In multiplication this is especially important, because this mute bit would appear in more places.

[sinandredemption]

Hello @ckormanyos

You had mentioned about problems with correctness of stringstream round tripping in another comment.

We still have some problems with round-tripping

I was thinking of testing and resolving this issue since @cosurgi has also mentioned this in his PR. Therefore, I wanted to ask you if the Boost.Multiprecision library of arithmetic tests contains a specific test related to this issue. If not, I would go ahead and create one.

Note that in any case, since cpp_double_float<> uses Boost.Multiprecision-native string constructors, if problems arise we might have to resolve them by using a specialized string constructor for cpp_double_float<>.

[ckormanyos]

still have some problems with round-tripping

problems with correctness of stringstream round tripping

I believe we do, in fact have either problems or comprehension issues that we do not fully understand. I have often been slightly confused with the exact numeric limits of round tripping, I must admit that.

if the Boost.Multiprecision library of arithmetic tests contains a specific test related to this issue

Yes. There is a specific test. For the cpp_bin_float backend, for instance, a lot of that round tripping is located here. I believe my comment was based on an extremely hurried attempt of mine to adapt that file to our case of cpp_double_float.

Please take a look. If you come to the conclusion that we need to write a new test (and that might be exactly what you find, I'm not sure), then feel free to write one as you deem fit.

Thanks @sinandredemption

[ckormanyos]

a lot of that round tripping is located

Hi @sinandredemption

I was mistaken. I attempted to adapt test_float_io.cpp, which is located here.

As you might have noticed, I have established the preprocessor definition #define TEST_CPP_DOUBLE_FLOAT when testing the cpp_double_float<T> backend instantiated for float, double, long double, or boost::multiprecision::float128.

This particular test file includes a few includes that you need to look around a while to find if you make a first cut at compiling this file for our double-float case within a msvc prj. If you need any help, please call on me.

I found a couple of errors and failures after adapting that file to cpp_double_float using the preprocessor flag i mentioned.

[cosurgi]

During my experiments in decompostion of numbers I have found a difficult to represent decimal number: "0.0001159426521754598586599893650372905540280044078826904296875"
Please experiment with it, see if it's difficult to represent also in your experiments.