From: Kbwms AT aol DOT com Message-ID: <9b.3c93a163.2c68fb23@aol.com> Date: Mon, 11 Aug 2003 09:58:59 EDT Subject: Re: Anomaly in printf() To: djgpp-workers AT delorie DOT com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_9b.3c93a163.2c68fb23_boundary" X-Mailer: 8.0 for Windows sub 6011 Reply-To: djgpp-workers AT delorie DOT com --part1_9b.3c93a163.2c68fb23_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 8/11/2003 1:01:40 AM Eastern Standard Time, eliz AT elta DOT co DOT il writes: > >Long doubles have 64 bits of mantissa, with a separate sign. We > >should have no problems representing, and thus printing, 2**64-2. > > In a long double, the mantissa includes the integer bit, unlike in a > float or a double. Se we lose one bit. > The existence of a hidden bit in float or double representation is not germane. Let's stick to the discussion of converting a long double. > >The fact that Linux can get it right means that the format can > >represent the numbers just fine. > > AFAIU, the format is not the issue here. We are discussing the string > of digit characters that is produced by printing the numbers. (I'd be > interested in seeing the actual bit patterns of the numbers as shown > by a debugger; I'm quite sure these bit patterns are okay.) Since > _doprnt does some amount of math on its argument, loss of precision > beyond the significant digits is inevitable. One should expect > singular failures like that. The arithmetic involved is simple for `f' format: 1. Split the floating number into its sign, integer and fraction components. 2. Convert the components separately to their external representations. 3. Print as required. This is essentially what I did when I wrote floating-to-ASCII functions for the CDC 1604 -- 40 years ago. Here are the bit patterns for the previous examples with an extra one thrown in: Demo = 18446744073709551615.000, Exp_and_Sign = 403e, FracBits = ffffffffffffffff Demo - 1 = 18446744073709551613.000, Exp_and_Sign = 403e, FracBits = fffffffffffffffe Demo - 2 = 18446744073709551613.000, Exp_and_Sign = 403e, FracBits = fffffffffffffffd Please observe that 2^64-2 requires only 63 bits. There seems to be no excuse for sloppy conversion, whether or not long double has a hidden bit. > > (Btw, I have a vague recollection we already had this discussion in > the past, with this same example.) > Quite so. --part1_9b.3c93a163.2c68fb23_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message dated 8/11/2003 1:01:40 AM Eastern Standard= Time, eliz AT elta DOT co DOT il writes:

>Long doubles have 64 bits of mantissa, with a separate=20= sign. We
>should have no problems representing, and thus printing, 2**64-2.

In a long double, the mantissa includes the integer bit, unlike in a
float or a double. Se we lose one bit.

The existence of a hidden bit=20= in float or double representation is not germane. Let's stick to the d= iscussion of converting a long double.

>The fact that Linux can get= it right means that the format can
>represent the numbers just fine.

AFAIU, the format is not the issue here. We are discussing the string<= BR> of digit characters that is produced by printing the numbers. (I'd be<= BR> interested in seeing the actual bit patterns of the numbers as shown
by a debugger; I'm quite sure these bit patterns are okay.) Since
_doprnt does some amount of math on its argument, loss of precision
beyond the significant digits is inevitable. One should expect
singular failures like that.

The arithmetic involved is sim= ple for `f' format:

1. Split the floating number into its sign, integer and fraction components.=
2. Convert the components separately to their external representations.
3. Print as required.

This is essentially what I did when I wrote floating-to-ASCII functions for=20= the CDC 1604 -- 40 years ago.

Here are the bit patterns for the previous examples with an extra one thrown= in:

Demo = =3D 18446744073709551615.000, Exp_and_Sign =3D 403e, FracBits =3D fff= fffffffffffff
Demo - 1 =3D 18446744073709551613.000, Exp_and_Sign =3D 403e, FracBits =3D f= ffffffffffffffe
Demo - 2 =3D 18446744073709551613.000, Exp_and_Sign =3D 403e, FracBits =3D f= ffffffffffffffd

Please observe that 2^64-2 requires only 63 bits. There seems to be no= excuse for sloppy conversion, whether or not long double has a hidden bit.<= BR>

(Btw, I have a vague recollection we already had this discussion in
the past, with this same example.)

Quite so. --part1_9b.3c93a163.2c68fb23_boundary--