asmith@acorn.co.uk (Andy Smith) (05/20/91)
There is no doubt that the 28S and the 48SX are brilliant calculators, but one thing still puzzles me. Certainly with the 28S, although much better than most calculators (3/3=1, 2/3*3=1) it is still not "accurate" due to the limitations of how it stores numbers. 1/3*3 still gives 0.999999999. Does the 48 still suffer from this limitation? A calculator that I wrote for the Archimedes uses 64 bit Floating point, but I cheat and round numbers up or down on the last digit of the calculation. Could a similar idea not be used on the 48? Could numbers tending to an integer be rounded up or down on the 16th or so decimal place if that number were a 9 or a 1 respectively?? What say you?? Andy
conte@crest.crhc.uiuc.edu (Tom Conte) (05/21/91)
In article <7174@acorn.co.uk>, asmith@acorn.co.uk (Andy Smith) writes: > [Stuff about FP limitations] > the 48 still suffer from this limitation? > > What say you?? > > Andy No amount of floating-point wizardry will remove such problems completely. The designers of the 28S consulted with Kahan, who won the Turing award in-part for his efforts designing the floating-point format that was used (IEEE/ANSI stadard 754). (The format was designed for a broad class of machines and not solely for the 28S!) So, yes it's bad. But, no, it can't get much better either. ------ Tom Conte Center for Reliable and High-Performance Computing conte@uiuc.edu University of Illinois, Urbana-Champaign, Illinois Fast cars, fast women, fast computers
pausch@saaf.se (Paul Schlyter) (05/21/91)
In article <7174@acorn.co.uk> asmith@acorn.co.uk (Andy Smith) writes: >There is no doubt that the 28S and the 48SX are brilliant calculators, but >one thing still puzzles me. Certainly with the 28S, although much better >than most calculators (3/3=1, 2/3*3=1) it is still not "accurate" due to the >limitations of how it stores numbers. 1/3*3 still gives 0.999999999. Does >the 48 still suffer from this limitation? Of course. THis is a limitation inherent in using BCD representaion for floating-point numbers. 1/3 is 0.33333333....... infinetley, so it must be rounded off somewhere. Suppose we round off after 12 digits: 0.333333333333 Now we want to multiply this with 3 - the answer to this IS 0.999999999999 to 12 decimal places. If one decides to always round up 0.999999999999 to 1.0000000000 just to get 1/3*3 right, one is faced with another problem: 3 * 0.333333333333 will then yield the result 1.0000000000 instead of the correct result 0.999999999999 . How do you handle this problem? The simple fact that one must live with is that ALL floating-point arithmetic may introduce round-off errors (unless one computes with infinite precision, which for practical reasons are impossible). By using BCD instead of pure binary floating-point numbers one is assured that things like 1/10*10 will always be exactly right, but that's only because 10 is the internal base for the floating-point number. The round-off errors still sometimes shows up, like in 1/3*3. There's really nothing you can do about it, without introducing other undesireable side-effects. -- --- Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF) InterNet: pausch@saaf.se FidoNet: 2:201/600.2
taber@ultnix.enet.dec.com (Patrick St. Joseph Teahan Taber) (05/21/91)
In article <7174@acorn.co.uk>, asmith@acorn.co.uk (Andy Smith) writes: |>There is no doubt that the 28S and the 48SX are brilliant calculators, but |>one thing still puzzles me. Certainly with the 28S, although much better |>than most calculators (3/3=1, 2/3*3=1) it is still not "accurate" due to the |>limitations of how it stores numbers. 1/3*3 still gives 0.999999999. Does |>the 48 still suffer from this limitation? |> If a calculator gave me 2/3*3 = 1, I think I'd ditch it. But there's good news in the case of 1/3*3 -- the answer is "it depends." If you have the calculator in STD mode, it gives .99999999etc (which is the right thing to do.) If the calculator is in FIX mode, SCI mode or ENG mode, it gives 1. It's Two! Two! Two solutions in one! -- >>>==>PStJTT Patrick St. Joseph Teahan Taber, KC1TD "Nerd" is so demeaning, I prefer "fashion-impared."
frank@grep.co.uk (Frank Wales) (05/22/91)
In article <7174@acorn.co.uk> asmith@acorn.co.uk (Andy Smith) writes: >There is no doubt that the 28S and the 48SX are brilliant calculators, but >one thing still puzzles me. Certainly with the 28S, although much better >than most calculators (3/3=1, 2/3*3=1) it is still not "accurate" due to the >limitations of how it stores numbers. 1/3*3 still gives 0.999999999. Does >the 48 still suffer from this limitation? All computers "suffer" from some version of this. There are infinitely many numbers that cannot be represented on machines with finite precision arithmetic; that's why examples are so easy to find. For example, 0.1 is an infinitely-recurring fraction in binary, and uses of it exhibits the same kind of problem you mention above. Choosing the number of digits to use is a classic engineering trade-off: accuracy v { cost speed space }. N-bit binary floating point has the unfortunate property of sometimes being unable to store exactly what the User entered (unless the User works in binary too). Modern calculators work directly in decimal rather than binary to eliminate the noise introduced by the interbase conversions. This also helps enhance the User's confidence in the machine. >A calculator that I wrote for the Archimedes uses 64 bit Floating point, but >I cheat and round numbers up or down on the last digit of the calculation. Why do you do consider this "cheating"? >Could a similar idea not be used on the 48? The 48 performs calculations to at least 15 decimal digits of accuracy internally, rounding results to 12 (some complex calculations use more precision for greater reliability). The example you cite above is a particular case of a general problem, and HP have taken great care, over almost 20 years, to ensure that their calculators have answers which are both accurate (within the limitations of their precision) and repeatable. This latter criterion is more noticeable on HP machines than on those of the competition, and is one reason why HP calculators do *not* use guard digits except internally. The effect of this is visible in a calculation like root(2). Perform this on some calculator, write down the result visible in the display to the greatest precision the machine displays, then subtract that written number from the original result. If the answer isn't 0, the machine is hiding something from you. Appreciating that serious mathemetical work sometimes needs to distinguish 3.14159265359, the closest 12-digit version of pi, from pi itself is the reason why pi (and e) are treated specially by the 28 and 48. This is especially true after a dozen functions have been applied to the number; sometimes its origin has an effect on the meaning of the calculation (preserving the origin of all numbers in the machine is a potentially useful but seriously unwieldy proposition for a calculator). >Could numbers tending to an integer be rounded up or down on the 16th or >so decimal place if that number were a 9 or a 1 respectively?? I'm not sure what you mean here by "tending to an integer." If an integer result is expected, provide one. Otherwise don't, since the calculator cannot read the mind of the User and guess than an integer is what would be the "right" answer. Sometimes, 1.00000000001 *is* the right answer. These "problems" come about because the machine is attempting to represent all possible numbers within its dynamic range using only edited highlights of the number line. No matter which highlights it uses, (i.e., which base, and how far apart), it still cannot be truly "accurate" for all but a tiny fraction of the possible numbers it could be called upon to represent. It's all a part of the magic of making the discrete look continuous. :-) -- Frank Wales, Grep Limited, [frank@grep.co.uk<->uunet!grep!frank] Kirkfields Business Centre, Kirk Lane, LEEDS, UK, LS19 7LX. (+44) 532 500303