Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!unido!rwthinf!cip-s01!berg
From: berg@cip-s01.informatik.rwth-aachen.de (AKA Solitair)
Newsgroups: comp.sys.handhelds
Subject: Re: HP48 units bug
Message-ID: <3532@rwthinf.UUCP>
Date: 20 Sep 90 11:58:50 GMT
References: <1990Sep19.024034.15518@mintaka.lcs.mit.edu>
Sender: news@rwthinf.UUCP
Reply-To: berg%cip-s01.informatik.rwth-aachen.de@unido.bitnet
Lines: 36

Christopher B. Moore writes:
>I have discovered what appears to be a previously unreported bug in my 
>revision D ROMs.  The units application fails to properly handle units
>with fractional powers.  The problem is easy to demonstrate by taking the

It was reported here some months ago.

[...]
>called HP calculator support today (9/18).  I was told that they were
>aware that the calculator behaves in this fashion and that the engineers
>who designed it made a "concious decision" to round fractional powers of
>units in order to make the calculator faster.
[...]
>fast calculators that give incorrect results are completely worthless, he
[...]
>I find it astonishing that HP would conciously produce a computational device
>that gives incorrect results and claim that it was done to promote speed of 
>computation.

Don't be so hard on them.  If you've ever programmed yourself you must know
that there is always a speed/accuracy trade off.  I think they made the
right decision not to support fractional powers in units if it makes the
calculations significantly faster.  And I must say that I trust HP that much
that they really tried it first, but probably came up with a factor in the
order of magnitude of 5 or more for the increase in computing time.

The alternative would be to provide YAF (Yet Another Flag) that would
enable/disable this feature.  Although I think I already know why they didn't
do that: they probably would have to have both an all integer-math routine
AND an almost identical floating-point-math routine available (in order to
keep things speedy), and that seems like too much a waste of ROM-space.
-- 
Sincerely,                 berg%cip-s01.informatik.rwth-aachen.de@unido.bitnet
           Stephen R. van den Berg.
"I code it in 5 min, optimize it in 90 min, because it's so well optimized:
it runs in only 5 min.  Actually, most of the time I optimize programs."