Re: This calculation is just wrong / computer can't count!

Tech-Archive recommends: Fix windows errors by optimizing your registry




"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:3qhgg3dnteb1i5f6teabqea2cnnhnoc8kd@xxxxxxxxxx
Why do you think pocket calculators do not have these errors? Why do you
think pocket
calculators and computers are using the same kind of arithmetic? In
either case, your
expectations are erroneous and you are not taking reality into
consideration. You can
wish all you want for infinite-precision arithmetic, but it isn't going to
happen.

Have you looked into the issues of "rational arithmetic"? This was a
short-lived
experiment in the late 1960s and early 1970s to provide the concept of
high precision in
the presence of division, and the trick was to not actually do the
division, but
essentially carry integer numerators and denominators symbolically through
the
computation. You can read up on this in old LISP manuals.

For example, there is no value 0.1 in rational arithmetic. There is a
value "1 / 10". The
numerators and denominators are carried through and no actual conversion
is done until
final printout, and then it is done to possibly hundreds of digits of
precision. So you
would never have 0.83333333 as any possible representation of 25/30; you
would actually
keep the symbolic numerator 25 and the symbolic denominator 30 as a
rational pair. If you
later added 1 to it, you would get the symbolic value 55/30 as the
rational pair (that is,
you would add 30/30 to 25/30 and get 55/30 as the result, and that's what
you would store:
the tuple <55, 30>). If you multiplied this by 1/10, you would get
55/300. If you
divided it by 7, you would get 55/2100 (1/7 * 55/300). If you want
precision, you pay a
high cost for it. Of course, you end up having to deal with printout.
Note that 1/3 * 3
is not necessarily 1.0; so if you printed out the result 1/3 you would get
0.3333333333333
until you ran out of digits. If you put this back in, you would get a
different rational
number to represent it, which would not be precisely 1/3, so if you
multiplied it by 3 you
would get 0.999999999999999 until you ran out of digits. [snip]

.... and when you format that answer for the screen, it would be rounded to
1.0. So NO PROBLEM. Do the maths to as many decimal places as you can
accurately handle, then do all rounding and display formatting in the last
stage.


.



Relevant Pages

  • Re: huge number calculator and library
    ... and 72 bit double precision. ... we also had a research lab that used analog computers. ... >>digits to 31 digits a question arose as to whether or not anyone KNEW of any ... why should the compiler raise an objection? ...
    (comp.lang.cobol)
  • Re: Calculating Wishes (was hpcatalog.com)
    ... But compared to modern computers, ... Sun-Earth distance useful even if it's know to a precision clearly ... digits of precision. ... > If a calculator offerred say 19 or more digits of precision, ...
    (comp.sys.hp48)
  • Re: [crit] Fallen
    ... works in AI would consider typed data to be a good thing... ... Or that computers can't be intelligent because they *don't* use organic ... I had a lot of difficulty get 3 digits of precision out of it. ...
    (rec.arts.sf.composition)
  • Re: float bug? perl 5.8, DBI and oracle 10.2.0
    ... precision numbers in oracle, you've got 38 decimal digits to play ... and with minimal coaxing perl will handle them as ... digits from a 32 bit floating point number - I'll go out on a limb ... and hazard that one can expect 12 or so digits from a 64 bit floating ...
    (perl.dbi.users)
  • Re: Strange Calculation Error in Excel (2)
    ... > Calling it a "mistake" suggests that you still do not understand. ... > an inevitable consequence of finite precision mathematics. ... BCD is rarely done in computers, ... precision or force me to display 10-decimal-point for every figure (clumsy ...
    (microsoft.public.excel.misc)