perldata: Add details to hex, etc floats

[khwilliamson]

This addresses some of the issues in #18664, beyond the additions of 3e18f72.

• This set of changes may require a perldelta entry, and I need help deciding.

[tonycoz]

An example with a 2 digit exponent for one of the bitwise bases (hex etc) would better illustrate the base-10-ness of the exponent number vs the base-2-ness of the power.

[khwilliamson]

Good point; I've added two. The problem is to choose something that can be calculated in one's head. And I think that means only binary, and that is not introduced immediately

[sisyphus]

This set of changes may require a perldelta entry, and I need help deciding.

I would think that, since no change in behaviour has occurred, perldelta may remain unaltered.

I see this PR introduces the example 05p2 # 20 into the documentation, but there's a nasty little issue when hex/oct/bin integer expressions are allowed to include an exponent.
It's a problem that (I think) affects only those integer values that overflow the IV precision.
Consider the 72-bit value 0x123456789abcdeff00, where the "00" overflows the 64-bit IV.
(Perl-5.42.0, IV size is 64, and NV type is 'double'.)

Owner@DESKTOP-88J497T ~
$ perl -wle 'printf "%.17g\n", 0x123456789abcdeff00p0;'
Integer overflow in hexadecimal number at -e line 1.
Hexadecimal float: mantissa overflow at -e line 1.
1.3117684674637903e+18

Owner@DESKTOP-88J497T ~
$ perl -wle 'printf "%.17g\n", 0x123456789abcdeff00;'
Integer overflow in hexadecimal number at -e line 1.
Hexadecimal number > 0xffffffff non-portable at -e line 1.
3.3581272767073033e+20

(Ignore, for the moment at least, that there are lots of hex numbers "> 0xffffffff" that are quite portable when IVSIZE is 8.)
Both of those one-liners are given valid hex expressions that should be (but are not) treated identically.
The only sign that they are being treated differently is that the second warning differs. And I believe that neither of those "second" warnings have any part in explaining the difference in behaviour.

The latter one-liner produces the correct result, BTW.

I think this would need to be documented or fixed.
Simplest thing might be to have the documentation forbid the inclusion of an exponent in the use of integer expressions.
But I've been doing some investigating on this, and I think it's safe to provide an exponent so long as the given integer value
does not overflow the IV precision.

Are negative exponents in (what are otherwise) hex/oct/bin integer expressions to be allowed ?
I think they DWIM - but, again, only if the given integer expression does not overflow the IV precision.
(One other little caveat with hex/oct/bin floating point values is that mantissa overflow is dealt with by truncation, rather than rounding to nearest - but I don't see that as a blocker.)

@t-a-k might also have some helpful thoughts on this.

[khwilliamson]

(Ignore, for the moment at least, that there are lots of hex numbers "> 0xffffffff" that are quite portable when IVSIZE is 8.)

Somehow my response to this got lost. Perl takes the position that anything above 32 bits is non-portable. That may be an obsolete position, but it is what it is.

In indtend to fix the anomalies you pointed out

[sisyphus]

Perl takes the position that anything above 32 bits is non-portable.

Oh - okay. I was thinking it was a warning that shouldn't appear when IVSIZE is 8 but, if that's not the case, then there's no need to take any action.

It does seem a bit anomalous that there's no similar warning for decimal integer literals that overflow 32 bits:

>perl -wle "print 0xf23456789;"
Hexadecimal number > 0xffffffff non-portable at -e line 1.
65016260489

>perl -wle "print 65016260489;"
65016260489

But I don't mind if that inconsistency remains.