Comments on: Beware ColdFusion Floating Point Integers

By: barneyb

barneyb — Sun, 19 Jul 2009 16:52:44 +0000

Ograll, Even just explicitly using java.math.BigDecimal (and BigInteger) is perfectly sufficient in most cases. ColdFusion will treat it like any other java.lang.Number so you can use standard math operators on it and pass "numeric" type checks. Just a matter of ensuring you're using an instance of it and it's methods when it matters, which can be difficult, since ColdFusion uses java.lang.Double for everything. As such, you can START with floating point error if you're not careful. In my example, using the string constructor to either "Big" class and then comparing would have been equally successful, but since simply comparing the strings I'd be passing to the constructors also worked, it saves a pile of typing. The moreso because I was actually comparing strings that just happened to be valid numbers (). Yay for implicit type conversions!

By: Ograll

Ograll — Sun, 19 Jul 2009 16:41:26 +0000

This is not a problem with just CF but floating point in general. Floating point is an approximation at best of the real numbers. There are very few numbers in the Real Line that can be exactly represented by Floating point, the rest get rounded at some point, consider pi, 1/3, or sqrt(2). In the examples you present you have past ability for the Significand of the floating point system to represent your numbers. One of the strange oddities of Floating point is that its accuracy goes down as the number moves away from 0 on the real line. As a matter of a fact when you hit the number 1 you have already passed 50% of the numbers that Floating point can represent.

Due to these factors most bank software avoids floating point, and if you want big numbers you need to get yourself a large number package.

By: Jamie Krug

Jamie Krug — Thu, 16 Jul 2009 03:43:14 +0000

BTW, if you read my post at http://bit.ly/3FyZnM, you'll see that I solved my rounding issue in the same way: cast to string to "lose" the floating point representation. While I was at it, I had my round UDF also enable you to round to a specified decimal point.

By: Jamie Krug

Jamie Krug — Thu, 16 Jul 2009 03:41:11 +0000

Yeah, I discovered a bug in the round() function a while back, which seems to be related. I blogged about it back in February (http://bit.ly/3FyZnM) and reported it to Adobe's "wish/bug list" back then. I just confirmed that the bug still exists in ColdFusion 9 beta 1 as well as OpenBD 1.1. Railo does not suffer this bug (neither 3.0 nor 3.1).

Basically, #round(4000.5)# outputs 4001, and you'd expect #round(4.0005*1000)# to output the same, but AdobeCF and OpenBD output 4000 for the latter.

FWIW, for your first example above, Railo 3.1.0.22 outputs neither what you'd expect nor what Adobe CF outputs, but rather "true true true true false true." This suggests that I might be able to find a similar round() function "bug" in Railo as well.

I guess all that is to say: you make a good point, Barney :) Beware of floating point representations in CFML!

By: Ben Nadel

Ben Nadel — Thu, 16 Jul 2009 00:51:07 +0000

I remember the first time I ran into number problems – trying to NumberFormat() the dollar amount for a merger in the billions of dollars. CF didn't care to treat that as a valid number :) Good to know there are easy work arounds to some of the number limitations. Thanks.