val() is for converting a string to a number. You already have a number, so you needn't run the conversion on it. More specifically, val() coerces it's argument to a string, even if it's already a number, and then converts that string back to a number. So it's doing exactly what it's designed to do.
A better approach would be this: cost = ... neat computation ... cost = round(cost * 100) / 100; that'll round to the nearest cent, which in this case, would result in zero (since the 0.000000000000014 in error would round down and out of existance). If you're just looking for display, you can skip the rounding, and just use the raw result in dollarFormat() without an issue, because it does rounding automatically. Regarding the accuracy of floating point arithmetic, there's simply no way to get around it. Floating point number are always approximate, since there's a finite number of decimal places they can represent, and that leads to errors when computations are performed. As evidenced here, that error is usually very small - small enough to safely ignore. That ability to ignore the minute errors is what makes floating point arithmetic attractive, since doing it with absolute precision is enormously more expensive. cheers, barneyb On 12/6/05, sdaniels @ marketplacetech. com sdaniels @ marketplacetech. com <[EMAIL PROTECTED]> wrote: > >The reason is that floating point arithmetic is not exact. You end up > >with a very small error (1.42108547152E-014) that CF expresses as > >scientific notation. When you run val() on it, it strips the > >exponent, so you're left with something that's 14 orders of magnitude > >off of what the real result is. > > That is harsh. I have never ever run into this before and I am very afraid > that I could have a lot of code effected by this problem. What is it that I > am doing "incorrectly", using val()? It seems to me that either the floating > point calculation should be more accurate, or val() should correctly > interpret the scientific notation CF uses. I mean, if I do > dollarformat(val(shiptotal+subtotal+discount)) where shiptotal = 15.12 and > subtotal = 59.70 and the discount = -74.82 it seems logical to me to expect > the result to be $0.00, not $1.42. > -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:226267 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
