[Gcl-devel] Bug in mpz_get_d

[Camm Maguire]

Paul Zimmermann <Paul.Zimmermann at loria.fr> writes:

>> Please stop writing verbose message with kilobytes of irrelevant copied
>> text.  This is a bugs mailing list and not a dicussion forum.  After
>> many long messages, we have yet to see evidence that there is any bug in
>> GMP, just evidence of poor reading of documentation, and possibly poor
>> understanding of IEEE 754.
>

Please accept my apologies.  You are correct.  I did read and
understand the documentation.  I did not correctly understand the
implications of the rounding algorithm.

> here is a tentative to close that issue.
>
> Summary: for input a = 2^1000-1 = 10715086071862673...375, mpz_get_d(a) gives
> 1.0715086071862672E301, whereas Camm Maguire expected 1.0715086071862673E301.
>
> Explanation:
> 1) as said in the documentation, mpz_get_d truncates its input, thus 2^1000-1
>    is truncated to d = 2^1000-2^947, which is the largest 53-bit floating-point
>    number less or equal to a. We have d = 10715086071862672[0]...048.
> 2) when printed to 17 figures, d is rounded to nearest, which gives
>    1.0715086071862672E301.
>
> (Remember that double-precision floating-point numbers are stored in binary.)
>
> Thus I see no bug.
>

You are right.  Again, my apologies.  I did not see at first blush how
rounding toward zero in one base could result in an error of more than
one least significant digit in another base, but it is clearly true.


Take care, and thanks for your work on GMP.
-- 
Camm Maguire			     		    camm at maguirefamily.org
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah