Barney has it. This is not a cf problem, this is any computer
language problem. There have been entire papers written on the
subject.
And like he said, you shouldn't be using val() anyway. What you
probably mean to be using is evaluate() .
For example:
<cfset a = 15.12 />
<cfset b = 59.70 />
<cfset c = 74.82 />
<cfset d = evaluate(a + b) />
<cfset e = evaluate(d - c) />
<cfoutput>
a = #a#<br />
b = #b#<br />
c = #c#<br />
a + b = d. d = #d#<br />
d - c = e. e = #e#<br />
</cfoutput>
This is not a bug in cfmx. This is just the way it is...
On 12/6/05, Barney Boisvert <[EMAIL PROTECTED]> wrote:
> 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:226271
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=11502.10531.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
