Mail Archives: djgpp-workers/2003/08/11/10:21:30
--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
<HTML><FONT FACE=3Darial,helvetica><FONT SIZE=3D3 FAMILY=3D"SERIF" FACE=3D"=
Georgia" LANG=3D"0">In a message dated 8/11/2003 1:01:40 AM Eastern Standard=
Time, eliz AT elta DOT co DOT il writes:<BR>
<BR>
<BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT=
: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px"></FONT><FONT COLOR=3D"#000000"=
style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D2 FAMILY=3D"SANSSERIF" FACE=3D"A=
rial" LANG=3D"0">>Long doubles have 64 bits of mantissa, with a separate=20=
sign. We<BR>
>should have no problems representing, and thus printing, 2**64-2.<BR>
<BR>
In a long double, the mantissa includes the integer bit, unlike in a<BR>
float or a double. Se we lose one bit.<BR>
</BLOCKQUOTE></FONT><FONT COLOR=3D"#000000" style=3D"BACKGROUND-COLOR: #fff=
fff" SIZE=3D2 FAMILY=3D"SANSSERIF" FACE=3D"Arial" LANG=3D"0"><BR>
<BR>
</FONT><FONT COLOR=3D"#000000" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D3=
FAMILY=3D"SERIF" FACE=3D"Georgia" LANG=3D"0">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.<BR>
</FONT><FONT COLOR=3D"#000000" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D2=
FAMILY=3D"SANSSERIF" FACE=3D"Arial" LANG=3D"0"><BR>
</FONT><FONT COLOR=3D"#000000" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D2=
FAMILY=3D"SANSSERIF" FACE=3D"Arial" LANG=3D"0"><BR>
<BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT=
: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">>The fact that Linux can get=
it right means that the format can<BR>
>represent the numbers just fine.<BR>
<BR>
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<BR>
by a debugger; I'm quite sure these bit patterns are okay.) Since<BR>
_doprnt does some amount of math on its argument, loss of precision<BR>
beyond the significant digits is inevitable. One should expect<BR>
singular failures like that.</BLOCKQUOTE></FONT><FONT COLOR=3D"#000000" sty=
le=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D2 FAMILY=3D"SANSSERIF" FACE=3D"Arial=
" LANG=3D"0"><BR>
<BR>
</FONT><FONT COLOR=3D"#000000" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D3=
FAMILY=3D"SERIF" FACE=3D"Georgia" LANG=3D"0">The arithmetic involved is sim=
ple for `f' format:<BR>
<BR>
1. Split the floating number into its sign, integer and fraction components.=
<BR>
2. Convert the components separately to their external representations.<BR>
3. Print as required.<BR>
<BR>
This is essentially what I did when I wrote floating-to-ASCII functions for=20=
the CDC 1604 -- 40 years ago.<BR>
<BR>
Here are the bit patterns for the previous examples with an extra one thrown=
in:<BR>
<BR>
</FONT><FONT COLOR=3D"#000000" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D2=
FAMILY=3D"SANSSERIF" FACE=3D"Arial" LANG=3D"0">Demo =
=3D 18446744073709551615.000, Exp_and_Sign =3D 403e, FracBits =3D fff=
fffffffffffff<BR>
Demo - 1 =3D 18446744073709551613.000, Exp_and_Sign =3D 403e, FracBits =3D f=
ffffffffffffffe<BR>
Demo - 2 =3D 18446744073709551613.000, Exp_and_Sign =3D 403e, FracBits =3D f=
ffffffffffffffd<BR>
</FONT><FONT COLOR=3D"#000000" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D3=
FAMILY=3D"SERIF" FACE=3D"Georgia" LANG=3D"0"><BR>
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>
<BR>
<BR>
<BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT=
: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px"></FONT><FONT COLOR=3D"#000000"=
style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D2 FAMILY=3D"SANSSERIF" FACE=3D"A=
rial" LANG=3D"0"><BR>
(Btw, I have a vague recollection we already had this discussion in<BR>
the past, with this same example.)<BR>
</BLOCKQUOTE><BR>
</FONT><FONT COLOR=3D"#000000" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D3=
FAMILY=3D"SERIF" FACE=3D"Georgia" LANG=3D"0"><BR>
Quite so.</FONT></HTML>
--part1_9b.3c93a163.2c68fb23_boundary--
- Raw text -