Re: [boost] [review] Multiprecision review scheduled for June 8th - 17th, 2012

Subject: Re: [boost] [review] Multiprecision review scheduled for June 8th - 17th, 2012
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-06-03 17:00:16

Le 03/06/12 21:24, Christopher Kormanyos a écrit :
> Thanks again Vicente.
>
>>>> I have run the test and I'm getting a lot of errors for
>
>>> 2) Could you please (with your compiler) create the
>>> reported number from string as
>>> cpp_dec_float_50(" -8.5665356058806096939e-10")?
>>> Then simply print it out with precision(13), fixed and showpos.
>>> This helps me see if the error is merely in printout or
>>> rather goes deeper into the class algorithms.
>> The result is
>> -0.0000000008567
> This is an issue of great concern. So the small number above
> can be successfully created and printed. Something else must
> be going on. I'll bet there is an initialization issue somewhere.
> We tested with GCC and MSVC. Clang does something
> different (either rightly or wrongly).
>
> You know, the number 12345678 is frequently used in the
> float I/O test case. And this number appears in a corrupted form
> in the error report. I wonder if clang has a different opinion
> on the default initialization of boost::array? That's how the
> limbs in cpp_dec_float are stored.
>
> Could you please send more examples of test case error
> reports that you receive? I really need to see more examples
> of the error text before I break down and get this other
> compiler running.

I have committed a log file error.txt under

svn ci -m "Multiprecision: added error log"
Adding         test/error.txt
Transmitting file data .
Committed revision 78803.
pc3:test viboes$ pwd
/sand/big_number/libs/multiprecision/test

Sorry fro the non orthodox transfer. Please, be free to remove it :-)
>
> <snip>
>
>>> Well, I guess this is simply a design choice. At this time,
>>> we decided to prohibit both narrowing as well as
>>> widening implicit conversion of binary arithmetic
>>> operations. This means that you need to explicitly
>>> convert both larger as well as smaller digit ranges
>>> in binary arithmetic operations. For example,
>>>
>>>      boost::multiprecision::cpp_dec_float_100 d = a * boost::multiprecision::cpp_dec_float_100(b);
>> This not answer my question "Why the implicit conversion from
>> cpp_dec_float_50 to cpp_dec_float_100 doesn't helps?". Have you an idea?
> I think we simply have different interpretations of explicit
> and implicit construction here. Perhaps mine will be wrong.
>
> Basically, you have d = a * b, where both d and a have 100
> digits, and a has 50 digits. The problem is with the (a * b)
> part of the expression. When computing (a * b), we are asking
> the compiler to do binary math such as
>
> "cpp_dec_float_100" = "cpp_dec_float_50" * "cpp_dec_float_100"
I would expect the implicit conversion from cpp_dec_float_50  to 
cpp_dec_float_100 to be found here, but I don't know why the compiler 
don't find it.
>
> Your expectation is quite reasonable. I mean everything
> like this works.
>
> "std::uint32_t" = "std::uint16_t" * "std::uint32_t"
>
>
>> Yes but it round while converting 100 digits to 50, and this should be
>> documented.
> No. I wish we *would* already have rounding in these cases.
> But we don't! In fact, the class constructor has a TODO-style comment
> indicating that it does not round.
Well, I don't know how a type that has less bytes to store the 
conversion could do it without rounding. Maybe you mean that you have 
taken just the first 50 digits, but this is a kind of rounding.
>
> Conversion to another digit range does not round.
> Since rounding occurs when printing the number,
> and because there are guard digits, you must
> be experiencing the "illusion" of rounding via
> a rounded printout.
Hmm, I should be missing something trivial :(

Best,
Vicente