Subject:
|
Re: Soliciting comments (and help) with online form
|
Newsgroups:
|
lugnet.publish
|
Date:
|
Tue, 15 Dec 1998 03:48:49 GMT
|
Viewed:
|
700 times
|
| |
|
|
cjc@NOSPAMnewsguy.com (Mike Stanley) writes:
> Thanks for the comments. Todd seems to have solved the problem,
> although I'm honest enough to admit that the whole thing is beyond me.
> Oddly enough, when I went back and looked at the old broke version it
> did bad math on some even numbers as well.
>
> The new, seemingly fixed version can be seen here:
>
> http://www.guarded-inn.com/lego/auction/test1214.htm
>
> And no, I don't run a P60. :) Running a Celeron 300a overclocked to
> 450. But from Todd's explanation I almost think computer math on any
> machine might not be the exact sort of thing I've always thought it to
> be.
It depends on the software. Packages like Mathematica will always get .35 x
3 right (unless they're told to use standard floating-point arithmetic).
> I don't understand it, but I guess there are times when .35 x 3 is not
> 1.05. Makes no sense, though.
Most popular lanuages in use today (JavaScript included) use 32- or 64-bit
floating-point representations. So 3 is 3 because it can be represented
exactly by 1 + 2, but .35 ends up being represented 1/4 + 1/16 + 1/32 +
1/256 + 1/512 + 1/4096 + 1/8192 + ... (which is about 0.3499755859375 if the
calculation is only carried out a few steps). In any case, a number like
35 happens to come out less than .35 in its binary representation, which
is exactly 0.010110011001100110011001100110011001100...(repeating forever).
But the computer doesn't track the binary digits forever -- so you get
what's called "round-off error."
When you multiply the internal representation of .35 by 3, you get something
like 1.049926757813 (this would be assuming about 16-bit arithmetic rather
than 32; 32-bit arithmetic would give a value closer to 1.05).
The fix() function embedded in your web page truncates numbers to two places
past the decimal point, but it wasn't rounding to the nearest penny first --
(which I why I suggested adding 0.005 before it chops the number). That
compensates for the roundoff error in simple cases like this where only one
multiplication is involved. (If you have a long string of multiplications,
compensation for roundoff error becomes much more difficult.)
I don't know why the fix() function is so complicated (you got it from ISN
Toolbox from Infohiway, Inc.?)...if JavaScript has a Perl-like sprintf()
function, you should be able to say
x = sprintf("%.2f", y);
instead of
x = fix(y);
and then get rid of that broken fix() function.
Another alternative (Larry's suggestion) would be to do everything in
pennies, and then convert to dollars at the last possible moment by dividing
by 100. This is what I do in the AucZILLA code and it works great. Note,
however that you still have to be very careful of roundoff error when you
divide by 100 -- because dividing by 100 has the same problems as
multiplying by 1/100 -- and 1/100 is represented by the approximate value
1/128 + 1/512 + 1/8192 + 1/16384 + 1/32768 + 1/65536 + 1/262144 + 1/1048576
+ etc., which works out to about 0.00999927520752 in 20-bit arithmetic.
So you still need to do rounding even after dividing by 100, or else you may
see things like (contrived example) 67/100 -> .68999927835 . Zero-padding
the numbers is also important so that you get 70/100 -> .70 and not .7 .
--Todd
|
|
Message is in Reply To:
 | | Re: Soliciting comments (and help) with online form
|
| (...) Thanks for the comments. Todd seems to have solved the problem, although I'm honest enough to admit that the whole thing is beyond me. Oddly enough, when I went back and looked at the old broke version it did bad math on some even numbers as (...) (26 years ago, 14-Dec-98, to lugnet.publish)
|
10 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
