The problem with floating point (and binary floating point and decimal fractions) is not strictly Perl's fault.

Any calculation in floating point can end up accumulating rounding errors. This will happen in any language.

Conversion of a decimal fraction to binary floating point introduces a small "representation error" most of the time, because most decimal fractions turn out to be recurring binary ones. Conversion from binary to decimal, for example in print tends to round to some number of decimal digits, so "representation error" is usually hidden. This rounding on output can also mask some rounding errors. Any system that uses binary floaing point will suffer from this issue -- and most do !

If all you want to know is whether the value you have in your hands has a non-zero fractional part, then $x - int($x) will tell you. But, depending on how the value $x was arrived at, be prepared for this to tell you there is a fraction, despite print $x showing none... for example:

  my $x = (1 - 0.99) * 100 ;
  print $x, ($x - int($x)) ? " has fraction" : " no fraction", "\n" ;
[download]

Incidentally int($x) in Perl does not force its result into an integer form. If $x is a very large floating value, so large that there cannot be any fraction bits, it will simply return the original value of $x. If $x is a large floating value, with one or more fraction bits, but an integer part too big for integer form, it will discard the fraction bits but still return a floating point value. You are in no danger of things going wrong (as they would do if int tried to return, say, a 32-bit integer).

Just want to note that example may be fixed as follows:

my $x = (1 - 0.99) * 100 ;
print $x, ("$x" - int($x)) ? " has fraction" : " no fraction", "\n" ;
[download]

Thanks for the more detailed explanation, i didn't know about the print rounding. As for getting false positives, not a problem at all for my case. :)

If by "something truly dumb" you mean "equalness might fail due to rounding issues"