[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] Bug in mpz_get_d

From: Camm Maguire
Subject: Re: [Gcl-devel] Bug in mpz_get_d
Date: Tue, 15 Dec 2009 09:49:39 -0500
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)

Paul Zimmermann <address@hidden> 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                                        address@hidden
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]