Re: mismatch between Perl 5.6 and Perl 5.8 in printing high precision

On Apr 3, 6:58=A0am, Ilya Zakharevich <nospam-ab...@ilyaz.org> wrote:
> [A complimentary Cc of this posting was sent to
> sisyphus
> <sisyphus...@gmail.com>], who wrote in article <28eff3d6-c1b4-4679-9838-38=[/color
]
c295b4d...@i7g2000prf.googlegroups.com>:
> 
>
> Why this would be so? =A0At best, one is 0.99999999976716936, another is
> 9.9999999976716936/10. =A0I know no axiom of FP arithmetic which would
> make them equal...

Oh! ... ok. (I was thinking that perl should see the same mantissa in
both instances, and therefore store the same value.)

The other thing I note is that (with 52 bits of precision, plus the
implicit leading "1.") 0.99999999976716936 is represented in base 2
as:
1. 1111111111111111111111111111111000000000
000000000000e-1
And that converts back to 0.99999999976716936 (in base 10).

OTOH, 0.99999999976716925 is represented as:
1. 1111111111111111111111111111110111111111
111111111111e-1
And that converts back to 0.99999999976716925 (in base 10).

For my conversions, I'm using "round to nearest" mode - and I'm using
the mpfr C library (version 2.3.1) - which, according to its homepage
at http://www.mpfr.org/ provides "correct rounding" and "copies the
good ideas from the ANSI/IEEE-754 standard for double-precision
floating-point arithmetic (53-bit mantissa)". I've not yet had any
cause to take issue with those claims.

For me, (the recent versions of)perl are at odds with everything else
on my box in (apparently) insisting that 0.99999999976716936 has the
internal base 2 representation of:
1. 1111111111111111111111111111110111111111
111111111111e-1

Everything else uses an internal representation of
1. 1111111111111111111111111111111000000000
000000000000e-1.

Is that still not a perl bug ? (This FP stuff is just so damned
tricky, I never know what to think for sure :-)

Cheers,
Rob

Quoth sisyphus <sisyphus359@gmail.com>:
>
> For me, (the recent versions of)perl are at odds with everything else
> on my box in (apparently) insisting that 0.99999999976716936 has the
> internal base 2 representation of:
> 1. 1111111111111111111111111111110111111111
111111111111e-1

Do you know how it gets to that? Is it not simply calling your atof?

> Everything else uses an internal representation of
> 1. 1111111111111111111111111111111000000000
000000000000e-1.
>
> Is that still not a perl bug ? (This FP stuff is just so damned
> tricky, I never know what to think for sure :-)

I think the stated position is 'perl provides no guarantees about
anything to do with FP'. If you wish to implement, test, and document
something more consistent, please feel free.... :)

Ben

[A complimentary Cc of this posting was sent to
sisyphus
<sisyphus359@gmail.com>], who wrote in article <9223ba3f-712a-42f6-9a3d-4041582ea604@b5g200
0pri.googlegroups.com>:
> For me, (the recent versions of)perl are at odds with everything else
> on my box in (apparently) insisting that 0.99999999976716936 has the
> internal base 2 representation of:
> 1. 1111111111111111111111111111110111111111
111111111111e-1
>
> Everything else uses an internal representation of
> 1. 1111111111111111111111111111111000000000
000000000000e-1.
>
> Is that still not a perl bug ? (This FP stuff is just so damned
> tricky, I never know what to think for sure :-)

You may want to consult

perl -V:d_Gconvert

It might help you understand what happens...

Yours,
Ilya

[A complimentary Cc of this posting was NOT [per weedlist] sent to
Ilya Zakharevich
<nospam-abuse@ilyaz.org>], who wrote in article <ft1bvk$12uu$1@agate.berkeley.edu>: 
>
> You may want to consult
>
>   perl -V:d_Gconvert
>
> It might help you understand what happens...

Oups, it is THE OTHER direction!  In fact, I do not know what Perl
uses to parse FP numbers.  Let me check....  In 5.8.8:

#define Atof                            my_atof

which, essentially, calls Perl_my_atof2(), which OMG! calls a
home-brewed implementation!  Shame on us!  No wonder it behaves
fishy; coding string-to-num conversion is not for weaklings...

But before ringing the bell, please consider what is the *right*
answer.  E.g.,

0.99999999976716936 * 2**75
= 37778931854161068825399.29174657778843648

The integer part is essentially

 0b11111111111111111111111111111111000000
000000000000000000010000000101011100
1

Perl behaves as if it were

 0b11111111111111111111111111111110111111
111111111111111...

The rest as if it were

 0b11111111111111111111111111111111000000
000000000000000...

So indeed, Perl's implemenation is extremely buggy (as anything
written by people who do not LIVE WITH FP would be)...

Hope this helps,
Ilya

[A complimentary Cc of this posting was sent to
sisyphus
<sisyphus359@gmail.com>], who wrote in article <9223ba3f-712a-42f6-9a3d-4041582ea604@b5g200
0pri.googlegroups.com>:
> For me, (the recent versions of)perl are at odds with everything else
> on my box in (apparently) insisting that 0.99999999976716936 has the
> internal base 2 representation of:
> 1. 1111111111111111111111111111110111111111
111111111111e-1
>
> Everything else uses an internal representation of
> 1. 1111111111111111111111111111111000000000
000000000000e-1.

Yet another thought (that's just alias for Perl's printf):

pprintff .31g 0.99999999976716936
0.999999999767169245324

pprintff .31g 99999999976716936/100000000000000000
0.999999999767169245324

pprintff .31g 99999999976716936
99999999976716928

So it looks like whoever wrote Perl's Atof() thought (in their greate
wiseness) that one is allowed to translate the mantissa in 3
operations: convert the "integer mantissa" to an FP value, then
convert the corresponding 1000...000 to an FP value, then divide.

(The numerics people would immediately note that doing 3 operations
increases the maximal possible error 3 times, which is not allowed.
The trickyness of string-to-FP conversion is that it cannot be done
using just the precision of the FP primitives; one needs to get a
higher precision that this...)

Hope this helps,
Ilya