Re: [boost] [Review Request] Multiprecision Arithmetic Library

Subject: Re: [boost] [Review Request] Multiprecision Arithmetic Library
From: Christopher Kormanyos (e_float_at_[hidden])
Date: 2012-04-15 05:49:15

>> I believe the expected output in the comment should be

>> 8.4147098480789650665250232163029899962256306079837106567275170999e-1

> Both sin and mysin(pi/4) output 
> 7.0710678118654752440084436210484903928483593768847403658833986900e-01 for 
> me - and my calculator agrees :-)

I guess I'm merely talking about the HTML documentation shown in
the link below. But maybe it's already been fixed elsewhere:
https://svn.boost.org/svn/boost/sandbox/big_number/libs/multiprecision/doc/html/boost_multiprecision/tut/floats/fp_eg/poly_eg.html

The example code in the HTML documentation uses mysin(1).
*Emphasize*: The argument is 1.
Whereas the "expected output" in the code comment in the
HTML documentation uses the number for the result of mysin(pi/4).
*Emphasize*: The argument is pi/4.

I apologize for giving you that code in an unscaled and
unfinished form in the first place. Sorry.

By the way, I looked at the compiler-generated assembly for
that polynomial expansion using template expressions
under x64 with VisualStudio2010. My jaw dropped to the floor!
It's baffling what the compiler does with expression templates
in combination with inlining, loop unrolling, constant folding, etc.
I would like to to take a closer look at this and really comprehend
the optimization potential.
The state of C++ compiler technology today is truly impressive!
I can hardly wait for VS2012 support for some of the new stuff.

>> I refactored the constants and got the tests running WRT trunk.
>> Two tests did not compile at first: test_arithmetic.cpp (line 468)
>> and test_float_io.cpp (line 204). The culprit is the compiler's failure to
>> resolve frexp(Real, int64). The compiler required a plain
>> integer argument. I believe that the compiler is correct
>> (Visual Studio 2010, SP1, in this case). Do you also experience
>> this problem?

> My mistake - I forgot to commit changes to default_ops.hpp - update again 
> and that should get it.  Sorry about that.

Great! I'll check it out.

>> All tests except one pass with my refactored code.
>> Unfortunately, test_float_io.cpp fails when round tripping
>> from cpp_dec_float to a string with a large exponent back
>> to cpp_dec_float. I believe that this problem can be solved
>> because I identified a potentially incorrect rounding and/or
>> digit inclusion when creating an exponent string in my
>> original code.

> OK good, I'd like that to work if possible, it seems like something users 
> would want and/or expect?

>> I have candidate changes in:
>> * cpp_dec_float.hpp
>> *trig.hpp
>> * floating_point_examples.cpp

OK. I committed:
* cpp_dec_float.hpp with 23 changes---all straightforward,
* trig.hpp with 2 changes

I also changed the way that the digits of precision progress in
Newton iteration for sqrt and atan. I needed this for high-precision.
But it's maybe still not as good as a real "order of the delta"
convergence check. But it doesn't matter at this stage in the game.

> Other than the expected value for sin(pi/4) please do go ahead and commit!
We just need to make the sample code agree with the comment
in the documentation. But I didn't check anything in for this.

> Many thanks, John.
Thanks to you, too. I believe that we're really moving along well, now.

Best regards, Chris.