Hidden Special Characters in Variable

Question

I am having a weird issue and for the life of me cannot figure out the root cause.  I have a query that is pulling back some data including a summed money data type from sqlserver called totalAmount.  We are looping over these rows and adding up some totals of the rows such as:
<cfset myAA = 0 />
<cfset myAB = 0 />
<cfloop ... >
<cfif ... >
<cfset myAA = myAA + getPayments.totalAmount />
<cfelse>
<cfset myAB = myAB+ getPayments.totalAmount />
</cfif>
</cfloop>
At this point we add the 2 together...
<cfset mySum = myAA + myAB />
We are expecting this to be 0, but in one instance it is not so, even though it should be.
Outputting the two variables gives them as -75.03 and 75.03.  When these are added together the result is:
-1.05160324892E-012
If I do a trim like:
<cfset mySum = trim(myAA) + trim(myAB) />
It returns 0.  So it seems there is an additional character on one or both of those variables, but what is it and where is it coming from?  If I output:
(#myAA#) + (#myAB#)
I get (-75.03) + (75.03).  So no whitespace... If I do a len() on each I get 6 and 5.
If I do a compare such as #myAA# => #(myAA eq "-75.03")#
I get -75.03 => NO, same with the other.
So I am dumbfounded, it seems there is a control character there that is hidden and throwing this off.  Anyone have any suggestions on what to check or any ideas what the problem may be?  I would rather fix the problem at the root rather than throwing trim() around variables that should be numeric to begin with.
-Shawn

Answer 1

BKBK's explanation is slightly wide of the mark, in mentioning that floats are all stored with an intrinsically high number of decimal places.
You misquote me. I didn't say intrinsic. I said arbitrary, twice even.
I am aware of binary representation and storage of numbers in memory. However, I intentionally kept the technicalities to a minimum, without losing the essence, so that it can make sense to Smholstein.
Whilst they can have a high number of decimal places, they don't automatically (1 will be stored with no decimal places; 1.5 will be stored with one DP, etc), and the "number of decimal places" is not really the correct way of looking at it.  For one thing, all numbers are stored in binary, not decimal, so there is no such thing as a decimal place.  A Double is 64-bit, which - if I'm reading the spec right, gives around 15 digits of decimal precision, and an exponent (of 10) range of 308 orders.  So this means one could express 123456789012345 or 0.123456789012345E-308.  But one could not represent 1234567890.123456: it's good too high a level of precision (16 digits; wherein a Double can only do 15).
Secondly, decimal fractions are not very easy to express in binary.  The only way binary has to express a number is in varying powers of 2, eg: 42 is  101010 in binary (32+8+2 or 1*2^5 + 0*2^4 + 1*2^3 + 0*2^2 + 1*2^1 + 0*2^0).  When expressing fractions, it has to do the same thing.  2.5 is 1*2^1 + 0*2^0 + 1*2^-1. Easy.  But what about 2.3?  It's easy in decimal, but actually not possible to represent in binary (try expressing 0.3 only using sums of 2 raised to negative powers...).  So intrinsically, many many floating point numbers are not possible to completely accurately represent in binary; the computer can only make a reasonably good approximation by calculating it to a reasonable number of significant figures.  This means that under the hood, 2.3 might be represented as 2.3000000000000001 or something.  This is inate to floating point representation.
Brave attempt! However, there are far too many technicalities and intricacies about floating points than we have time or space for in this forum. It is sufficient to say that ColdFusion's underlying machine, Java, uses the IEEE 754 standard for representing floats and doubles. 
According to this standard, a  float is a single-precision, 32-bit floating-point number. Whereas a double is double-precision 64-bit floating-point number. A float requires up to 4 bytes of storage in memory, a double, 8 bytes. Floats have a precision of 23 binary digits, and doubles, 52.
Those are the limitations that make it impossible for the computer to represent, for example, 2.3 with exact precision. However, that doesn't mean that it is impossible to represent 2.3 in binary! It is infact possible to so, but it requires an arbitrarily large number of terms. Here it goes:
2.3 = 2 + 1/4 + 1/32 + 1/64 + 1/512 + 1/1024 + 1/8192 + 1/16384 + 1/131072 + 1/262144 + ...
Now, there's a vagary in CF that when one converts a floating point number to a string it internally "fixes" this approximation, so it'll convert 2.3000000000000001 to "2.3" as a string.  So if you output a float, it'll get "fixed", and if you use a float as an argument value for a string function (like trim), it'll also get "fixed".  That's why trimming your value seems to fix the problem.  It's really just a side-effect of the way CF converts floats to strings.
I think it's a bit more complicated than that. It can actually happen the other way round. That is, that ColdFusion may cast from the float 2.3 to the double 2.3000000000000001. That is what happened to Smholstein.
On the other hand, there are times when ColdFusion may round off numbers. This can happen, for example, if the number of digits after the decimal point exceeds, say, 12.
Run the following test. You will find that the 'fixing' you describe fails to work for y. The results are, respectively, 2.3 and 2.30000000001.
<cfset x = trim(2.300000000001)>
<cfset y = trim(2.30000000001)>
<!--- Add 0 to make ColdFusion convert to numbers --->
trim(2.300000000001) + 0 = <cfoutput>#x+0#</cfoutput><br>
trim(2.30000000001) + 0 = <cfoutput>#y+0#</cfoutput>