Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!hpfcso!hpfinote!rrd
From: rrd@hpfinote.HP.COM (Ray Depew x2419)
Newsgroups: comp.sys.handhelds
Subject: Re: HP48 units bug
Message-ID: <19080011@hpfinote.HP.COM>
Date: 20 Sep 90 16:52:55 GMT
References: <1990Sep19.024034.15518@mintaka.lcs.mit.edu>
Organization: Hewlett Packard CICD
Lines: 76

Christopher B. Moore says:

> 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
> square root of 1_N (that's one Newton) and then trying to convert to base
> units with UBASE.  The correct answer is, of course, 1_kg^.5*m^.5/s but the
> calculator returns 1_kg*m/s.  The calculator does not handle fractional powers
> of units, rather it simple rounds to the nearest integer power.  Another 
> interesting result is that the UBASE of 1_N^.3333333 returns 1_1/s.
> It appears
> that UFACT calls UBASE because it suffers from the same bug....

I think you guys are starting to see bugs around every corner.
 
[stuff about laying it all on the doorstep of Calculator support]

> There
> is no way around it other than to ignore the units application completely.

What?  And give up on the best "units" implementation yet in a handheld
machine?  Tell me, how many other machines with units let you do ANYTHING
other than simple unit conversions?  Ignore it if you want.  It's your loss.

[more stuff about laying it all on the doorstep of Calculator support]

> It makes me wonder what other undocumented surprises reside in this machine.
> This is ridiculous.

It makes ME wonder what other limitations people are going to discover, yell
"bug!" and demand an instant upgrade or refund.  THIS is ridiculous.

C'mon, guys.  If you hold the 48 sideways in your hand and use it to drive
16-penny nails, the display will turn a funny rainbow color, and even
resetting the calculator via the defibrillator port on the back, won't 
bring it back to normal.  That's not a bug, either.  You have to use the
machine the way it was intended to be used.

It's fascinating to watch the evolution of HP48 awareness in this notesgroup.
At first the discussions were on the level of "Wow, this machine can do 
anything!  There are NO limitations!"  Then they went to "Hey, look at this
neat trick I can do!"  Now they're coming to the point of "Hey, I found 
something the HP48 can't do," except that instead of calling it a limitation,
they're -- you're -- calling it a BUG.

A bug is something the machine wasn't intended to do in the first place.  
Its discovery makes designers uncomfortable, and they rush to fix it.  Bugs
are not intentionally designed in.

What you have discovered is not a bug.  It's a limitation.  You have explored
the territory covered by the HP48 OS so thoroughly that you have, in fact,
come to the edge of the territory, the boundary.  For this, you are to be
commended.

But don't stand there and cry "Not fair not fair."  That's a waste of your 
time & energy.  Instead, find a way around the problem.

(Actually, the workaround is so ridiculously simple, I'm surprised you didn't
discover it and include it in your posting:
                                __
	Instead of going:     \/     UBASE
                                       __
	Reverse it and go:    UBASE  \/  

I tried it with your 1_N example, and I got 1_kg^.5*m^.5/s  .  Isn't that
what you wanted?)

Follow Andreas G's example.  Find the limitations, accept them for what they
are, and then find a way around them.  But don't be so childish as to call
them bugs and demand that HP fix something that isn't broken.


Regards
Ray Depew
rrd@hpfitst1.hp.com
(Slightly peeved today.  Did anybody notice?)