If perl's abstraction of numbers isn't good enough for you,

It's not "for me", it's "for my application".

it's easy enough to fix. use bignum;.

Ah! But ... if that's your answer to future proofing against speculative what-ifs

1. You either
   • need to use bignum; in every program always; or

     Which is going to make your programs crawl when it is completely unnecessary 99.99% of the time.

   • selectively choose when to use bignum;

     Which is no different to using integers, and integer operators selectively; knowingly.

   You cannot have it both ways. What's good for the goose is good for the gander.

2. You completely missed my point about sum 1 .. 2**30;, but that's my fault for not making it clear.

   Perl's reals are perfectly capable of holding sum 1 .. 2**30. There is no need for bignum.

   use List::Util qw[ sum ];
   
   $n = 576460752840294400; 
   printf "%20.f\n", $n;;
     576460752840294400
   [download]

   The problem is that trying to compute it (or even 1sum 1 .. 2**26 with List::Util::sum() crashes perl!

   It's a bug. But so is 99_999_999 & 1. No difference. Neither will allow you to future proof your application against speculative integer math that grows beyond certain limits.

   Then, when dealing with huge numbers, insert the bignum pragma, and you're done. A bit slow, perhaps, but accurate.

   When dealing with non-IV/UV values, don't use integer operations, and your done.

   You cannot have it both ways. What's good for the goose is good for the gander.

I think you're getting a bit paranoid here. In my definition of oddness, I stipulated that it was confined to the set of integers - so talking about floating point concerns seems a bit orthogonal to that question

I'm getting paranoid?.

I was responding to your citing of tye (getting paranoid) about what happens when using & 1 on integers that have been promoted to reals through growing beyond the integer range.

I was pointing out that using floats to hold oversized integers is at best a hack, and at worst dangerous because if you attempt to use integer operations on integers stored as floats, perl does very strange things.

I was also pointing out that adding a second hack to work around the limitations of the first hack--using % 2 to test for oddness--was compounding a problem and producing another, worse problem. Especially, if you compound that by using if( $n % 2 ) ... instead of the full if( $n % 2 == 0 )....

And that even if you do you the latter, you're still not "future proof", when your integers move beyond the range for which your reals are capable of representing integers accurately.