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