I've reached different conclusions.

• perl's implemetation of % is far from a perfect tool for deciding oddness of a 'number':

  Perl> print "$_: ", $_ % 2 
      for 1e308, 1e308 + 1, 
          1.999999999999999, 1.9999999999999999999;;
  1e+308:  0
  1e+308:  0
  2:  1
  2:  0
  [download]

  There are dozens of other examples.

• 'Oddness' is an inherently integer concept and a boolean condition. Using an inherently non-integer, non-boolean operator to test for an inherently integer, boolean condition is just plain wrong!

  Whilst reals can hold integer values and a much larger range of them than integers, but that does not mean using an inherently non-integer, non-boolean operator to test for an inherently integer, boolean condition is works.

  At the very least it has to be coded as if( ( $real % 2 ) == 1 ) {...};, but even that is fraught with the problems of floating point accuracy as shown above.

• perl's attempt to abstract away different types of numbers, and transparently move between unsigned & signed integers and reals is far from complete. And at the margins, downright dangerous. In my book, this is unforgivable:

  use Devel::Peek;;
  $n = 9_999_999_998; 
  print Dump( $n ); 
  print $n & 1; 
  print Dump( $n );;
  
  SV = NV(0x1844044) at 0x19920c4
    REFCNT = 1
    FLAGS = (NOK,pNOK)
    NV = 9999999998
  
  1
  SV = PVNV(0x1985a0c) at 0x19920c4
    REFCNT = 1
    FLAGS = (NOK,pIOK,pNOK,IsUV)
    UV = 4294967295
    NV = 9999999998
    PV = 0
  [download]

  Silently permitting bit-wise boolean operations on numbers that are reals, and beyond the range of unsigned integers, is just plain weird.

• Benchmarks make bad justifications for syntactic preferences.
• Bad benchmarks are bad justifications for anything.
• In the end, there is no abstraction that can beat the programmers knowledge of his applications needs.

  What if's about the future make bad justifications for anything.

  What if that was sum 1 .. 2**30;?