Re: Non-integer print output???

So why does perl convert a number that will obviously fit inside a 64 bit integer to floating point?

Firstly, note that the ** operator always returns an NV:

C:\>perl -MDevel::Peek -le "$x = 2 ** 3; Dump $x;"
SV = NV(0x47cd88) at 0x47cda0
  REFCNT = 1
  FLAGS = (NOK,pNOK)
  NV = 8

C:\>perl -MDevel::Peek -le "$x = 2 ** 49; Dump $x;"
SV = NV(0x33d148) at 0x33d160
  REFCNT = 1
  FLAGS = (NOK,pNOK)
  NV = 562949953421312

C:\>perl -MDevel::Peek -le "$x = 2 ** 50; Dump $x;"
SV = NV(0x47cd38) at 0x47cd50
  REFCNT = 1
  FLAGS = (NOK,pNOK)
  NV = 1.12589990684262e+15
[download]

(Maybe the question you should ask is "Why does the ** operator always return an NV ?". I don't know.)

What you've displayed is that perl sometimes decides that an NV will be printed (interpolated) as an integer, and sometimes printed as a float.
Obviously, non-integer NVs will always be printed as floats - no problems there.

Now, perl still adheres to the utterly fuckbrained notion that, when nvtype is double, print() will never present more than 15 significant digits.
And that's what you're seeing here.
The NV returned by the operation 2 ** 50 contains 16 significant digits which, by this idiotic rule, must be interpolated to 15 digits. And that's what perl duly does.
But if the NV contains an integer value comprising less than 16 significant digits that is in the range IV_MIN to UV_MAX (eg ~~2 ** 50~~ 2 ** 49), then it will be interpolated as an integer.

On a perl whose nvtype is ~~long double~~ fully quad IEEE 754 long double or __float128, you should find this particular anomaly to be absent - because the 15-digit limit does not apply there.
Thre's still an absurdly low limit, but it's large enough to prevent this particular case presented here.

Cheers,
Rob

Comment on Re: Non-integer print output??? Select or Download Code

Replies are listed 'Best First'.
Re^2: Non-integer print output??? by LanX (Saint) on Sep 10, 2021 at 09:12 UTC
> (Maybe the question you should ask is "Why does the * operator always return an NV ?". I don't know.)* The exponentiation operator a**b is IIRC optimized to generally handle float input for a and b and is approximating the result. The result is hence usually a float. Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery}	[reply]
Re^3: Non-integer print output??? by syphilis (Archbishop) on Sep 10, 2021 at 14:33 UTC
The exponentiation operator ab is IIRC optimized to generally handle float input for a and b and is approximating the result. Does this arise because C's pow/powl/powq functions take floating point inputs and return floating point values ? I've always assumed so, without ever really knowing. I'm a little surprised that the C language doesn't provide a pow() function that takes and returns signed long int (or signed long long int) values - though I guess such a function would easily overflow for relatively low input values. Cheers, Rob	[reply]
Re^4: Non-integer print output??? by bliako (Abbot) on Sep 10, 2021 at 17:18 UTC
interesting discussion here on what's the optimum way to do integer exponentiation, squaring is the standard but not the most optimal. https://stackoverflow.com/questions/101439/the-most-efficient-way-to-implement-an-integer-based-power-function-powint-int	[reply]
Re^4: Non-integer print output??? by LanX (Saint) on Sep 10, 2021 at 15:45 UTC
As I said, it's AFAIR an approximation algorithm. I quickly found efficient integer algorithms too, can't tell why they are not included. I suppose it's provided by the CPU/ MMU? Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery}	[reply]
Re^2: Non-integer print output??? by jwkrahn (Abbot) on Sep 10, 2021 at 01:19 UTC
Thanks for the info.	[reply]