develooper Front page | perl.perl5.porters | Postings from February 2003

Re: [perl #20827] Unexpected scientific notation.

Thread Next
February 11, 2003 13:55
Re: [perl #20827] Unexpected scientific notation.
Message ID:
On Tue, Feb 11, 2003 at 09:35:48PM -0000, John Peacock wrote:
> (via RT) wrote:
> >     $ perl -wle '$x = 1597009560; print $x ** 2'
> >     2.5504395347313936e+18
> $ perl -wl -MMath::BigInt=:constant -e '$x = 1597009560; print $x ** 2'
> 2550439534731393600
> Just because Perl guessed right one time and not the other doesn't mean that
> should rely on consistent large number behavior.  There is always going to be 
> some point where NV's will happen when you would expect UV or IV's to be used. 
If this "some point" isn't at the maximum size of what fits in an
integer, than I think this fact should be documented clearly. If there's
no indication where this "some point" is, it would reduce the value of
-Dusemorebits to below the level of "useful". Or is it even so
1001 ** 2 can't be garanteed to stringify to 1002001?

> If you care about the correctness of your math, use M::BI.
> I think I can explain why Perl made the choices it did (and I can even look at
> the source code to see if I am right ;~), but I cannot believe that this shoul
> be considered to be a bug.

I most certainly do think it's a bug. The number to be squared was
carefully picked to be less than the square root of 0x7FFFFFFFFFFFFFFF.

> be considered to be a bug.  I suspect the multiplication is attempted first 
> using the IV's for speed, falling back to the NV's if the IV's overflow.  The 
> exponential goes straight for the jugular and uses NV's preferrentially, since
> the odds of overflowing the IV slot are so much greater.

I'd except that if the IV's would overflow. But why would they?


Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About