Further, because the error can manifest itself within CFML constructs that you (the developer) have no control over, it can be hard to see both that a problem could exist or how to change exact comparisons to proximity comparisons. The fixFloatingPoint() UDF is designed to stably align a floating point value into a proximity value, but it has to be used explicitly.

Another way to do proximity alignment (if you can't remove the floating point computations), is to change bounds. For example, modify the first CFLOOP above to this (adding most of an extra step):

<cfloop from="#bounds.lower#" to="#bounds.upper + bounds.interval * 0.9#" index="i" step="#bounds.interval#">
  #i#<br />
</cfloop>

This may not be generally applicable to all situations, but in this particular case you could multiply the loop bounds by 10, use a step of 2 instead of .2, and multiply by .1 within the loop to get the values you want, which behaves correctly. Just another idea.

"Not exactly a helpful observation but I would point out that it is
never really safe to use equality tests on floating point numbers…

I guess I would have to ask *why* you are trying to test for floating
point equality rather than just a suitable proximity?

Have a play with this to see why comparing floating point numbers can
be problematic:

http://babbage.cs.qc.edu/IEEE-754/Decimal.html

If you enter 0.1, you'll see the 32-bit representation is different
for rounded vs non-rounded but if you enter 0.01 you'll see it is the
same for rounded vs non-rounded (and neither are equal to 0.01 within
the precision allowed by 32-bits). As you can imagine, lots of factors
come into play when manipulating floating point numbers – how constant
expressions are reduced, how optimization is performed on
subexpressions…"

In my case I was able to change my code to test for suitable proximity.

(I also checked the Railo source and it doesn't use BigDecimal for floating point values)

67
67.2
67.4
67.6
67.8

– At any rate, it should be there. Micha can reject it with a reason and people can do a search and read his reason.

Did you confirm that Railo exhibits the issues in the same way as ColdFusion? Though all things considered, I'm not convinced it's something that should be fixed by the engine. You can circumvent the problem with the explicit use of BigDecimal, but since those are java.lang.Numbers, implicit floating point correction could "break" very precise calculations with no recourse. Ground to tread carefully to be sure on the side of the CFML engines, since it's not a bug per se, but an issue with the CFML language.