cmoore@space.mit.edu (Christopher B. Moore) (09/19/90)
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. This bug has been independently verified on another D-ROM and an E-ROM. I 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. When I pointed out to the person on the phone that the answer was WRONG, he agreed but said that it was done so that the calculator would be faster. When I told him that fast calculators that give incorrect results are completely worthless, he suggested that I simply type UBASE after every unit I enter. That fixes the bug sometimes, but trying UBASE of 1_m^.5/s^.5 gives 1_m/s. There is no way around it other than to ignore the units application completely. 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. If you care about units, call HP (503-757-2004) and tell them that this is a bug and that it should be fixed. They said that if they get enough complaints they _might_ fix it. It makes me wonder what other undocumented surprises reside in this machine. This is ridiculous. Christopher B. Moore cmoore@space.mit.edu
paulm@hpcvlx.cv.hp.com (Paul J. McClellan) (09/20/90)
> 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. ... > Christopher B. Moore > cmoore@space.mit.edu Please explain to us what physical quantity is represented by the square root of a Newton. The unit application was designed to solve useful problems in a reasonable amount of time and memory space, and fractional unit exponent support was intentionally omitted to achieve this. +--------------------------------------------------------------------+ | Paul J. McClellan | paulm@cv.hp.com | | Information Technology Operation | {backbone}!hplabs!hp-pcd!paulm | | Hewlett Packard Co. | | | 1000 N.E. Circle Blvd. | | | Corvallis, OR 97330 | | +--------------------------------------------------------------------+ | All relevant disclaimers apply. | +--------------------------------------------------------------------+
austern@ux5.lbl.gov (Matt Austern) (09/20/90)
In article <110540017@hpcvlx.cv.hp.com>, paulm@hpcvlx (Paul J. McClellan) writes: >Please explain to us what physical quantity is represented by the square >root of a Newton. The unit application was designed to solve useful >problems in a reasonable amount of time and memory space, and fractional >unit exponent support was intentionally omitted to achieve this. > In certain unit systems, the square root of a Newton (or, more precisely, the square root of a Newton*meter^2) is a unit of electric charge. More generally, I've seen fractional units quite often, in many contexts. (The other high-energy physicists on this group will, for example, recognize the expression mu^(4 - epsilon), where mu has units of mass or energy and epsilon is some small positive number.) Fractional units aren't always useful, but some people find them convenient for certain purposes. It's dangerous to assume that the unit system that is convenient for you is convenient for everyone! I'm not complaining about the lack of support for fractional units. (I noticed it a few months ago, posted it, and forgot about it.) Indeed, this feature probably isn't important for most people, and speed and space are important. Still, I think that this should have been mentioned in the manual. The behavior of the unit conversion commands doesn't match what the documentation says. And that is the definition of a bug, isn't it? -- Matthew Austern austern@lbl.bitnet Proverbs for paranoids, 3: If (415) 644-2618 austern@ux5.lbl.gov they can get you asking the wrong austern@lbl.gov questions, they don't have to worry about answers.
billw@hpcvra.CV.HP.COM (William C Wickes) (09/20/90)
Christopher 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 bug here is that the HP 48SX manual fails to document the unit management system properly; it should have specified that while 48 units may have fractional powers, those powers are converted to signed 8-bit integers for the sake of dimension checking. Thus while you can successfully add 1_m^.5 +1_cm^.5, you can also add 1_m^.5 + 1_cm^.4 without the 48 reporting an error. The dimension checking limitation also carries over to UBASE, and UFACT, which executes UBASE; these return meaningless results for fractional exponents. The HP customer support representative was correct in stating that this design was intentional. There is a considerable amount of processing involved in unit operations, and representing the base unit dimensions with small integers provides a considerable efficiency compared with using floating-point numbers. The loss of ability to handle fractional exponents in all circumstances was taken as a modest price to pay for the speed gain, given that the great majority of physical problems involves integer powers of units. There are many cases where fractional powers may appear then disappear in the course of calculations, but these can be generally be handled correctly within the 48 system with a little care in the order of operations. The HP 48SX unit management system is a valuable tool that can be applied to a wide range of physical problems (in 10 years of university physics research and teaching, I don't recall any unit manipulations that would have been intractable on a 48, although my memory may be biased). This is little consolation if it doesn't work for your particular problem, but there are other things you can't do on a 48. The key is proper documentation that lets you know the reach and limitations of your tools. We fell short in this case, but documenting the 48 for a very wide range of customers was and is a massive task. It might be helpful to the user community if Mr. Moore and others could to post some example problems involving fractional units, so that we can study how they might be dealt with on the 48. Bill Wickes billw@cv.hp.com
berg@cip-s01.informatik.rwth-aachen.de (AKA Solitair) (09/20/90)
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."
rrd@hpfinote.HP.COM (Ray Depew x2419) (09/20/90)
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?)
jmorriso@ee.ubc.ca (John Paul Morrison) (09/26/90)
Speaking of units, I wonder if the HP48 has support for logarithmic "units"
I don't have a 48, so I really don't know.
What I mean is: can the HP48 work with dB's? When you multiply two
numbers expressed
in dBs, you simply add the two quantities
ie 2 * 2 = 3 dB + 3 dB = 6 dB
but
1 + 1 = add by POWERS 0 dB and 0 dB = 10log(10**(0/10) + 10**(0/10))
= 3dB (so 0 + 0 = 3 ;-)
There would also be weird things when you considered the original units
and the fact that
your value is in dB. This would be interesting for summing powers of
things in dBm and dBW
that is the power in mW or in Watts. so 1 dBW = 30 dBm.
Just rambling on about effective radiated power...
------- _/__/ -----------------------------------------------------
_| ___| E l e c t r i c a l | John Paul Morrison
| | |_/ E n g i n E E r i n g |-------------------------
|/| __| U n i v e r s i t y | jmorriso@ee.ubc.ca
|-| |/__ o f B r i t i s h |-------------------------
| |_____| C o l u m b i a |ubc-cs!ee.ubc.ca!jmorriso
---- |__|/_| ------------------------------------------------------