HP48 FAQ Section 11: Appendix C: Details of Bugs
| Previous | Contents | Next |
From: Joe Horn
Clear flag -53 first (the Precedence Flag).
On a Rev E, put '((1+2)/(3+4))^5' on the stack and press down-arrow. You'll see:
5
/ 1+2 \
| --- | (A)
\ 3+4 /
1+2
----------- (B)
(5)
(3+4)
Now set flag -53, then repeat the above procedure. First you see:
5
/ 1+2 \
| --- | (C)
\ 3+4 /
(5)
/ 1+2 \
| ----- | (D)
\ (3+4) /
Major difference: after pressing down-arrow, Rev J goes directly into graphic mode, so you have to press ON and then EXIT to get into the equation editor (which Rev E goes directly into). But that's petty cash compared to the following big change.
The same sequence of operations, first with flag -53 clear, then set, exactly as detailed above, yields these four displays in a Rev J:
5
/ (1+2) \
| ----- | (A')
\ 3+4 /
5
/ (1+2) \
| ----- | (B')
\ (3+4) /
5
/ (1+2) \
| ----- | (C')
\ 3+4 /
5
/ (1+2) \
| ----- | (D')
\ (3+4) /
Unfortunately (as you can see above) Rev J always puts parentheses around polynomial numerators. It is therefore impossible to use the ->GROB command on a Rev J to create a GROB that looks like expression (A) above; the simplest that can be had is expression (A').
Another minor change, while I'm at it: Rev A-E don't change the menu when you press REPL; Rev J automatically flips to the appropriate RULES menu.
From: Wlodek Mier-Jedrzejowicz
<wacm@doc.ic.ac.uk>
There is a rotation rate conversion bug in the HP48 G/GX which I have not seen reported here before, so after discussion with the folks at Corvallis I am posting this description. Warning: it is 159 lines long!
First - an example. Put the unit object 60_rpm in level 2 and the unit object 1_r/s in level 1, then execute the command CONVERT. You are asking the HP48 to convert a rotation rate of 60 revolutions per minute into an angular frequency in radians per second. 60 rpm is 1 revolution per second, or 2pi radians per second. No HP48 G/GX will give this answer! Not everyone uses rpm or is even aware of the existence of this unit - it is one of the extra units in the UTILS menu of the Equation Library - so here is a second example - add 2pi radians per second to one Hertz. Put 6.2832_r/s in level 1, 1_Hz in level 1, and add. You are adding an angular frequency of two pi (one cycle) per second to a rotation rate of one per second, so the result should be a frequency of two Hertz. On an HP48 S/SX that is the answer. On an HP48 G/GX it is not.
When units are converted, by CONVERT, or during arithmetic on unit objects, the level 2 object is first turned into "base units", and then the result is converted into the units of the level 1 object. On the HP48 S/SX, the "base unit" of angles is one rotation (or a "unit circle" or a revolution or a cycle). So, the angle unit of rpm (a revolution) or of Hz (a cycle if Hz is treated as a rotation rate) is already in base units - conversions to angles involving rpm and Hz automatically work correctly. On the HP48 G/GX, the "base unit" of angles is the current angle mode (DEG, RAD or GRAD) - so any conversion from rpm or Hz (or any formula which works in cycles, rotations, revolutions, unit circles) to angles should be preceeded by a conversion from the unit circle to the current angle. Apparently no-one noticed this would be necessary, because it all worked automatically on the HP48 S/SX.
So, when you convert 60_rpm to units of _r/s, an HP48 G/GX converts not 60 rotations but 60 "base angle units" per minute to radians/second. In RAD mode, you get 1 radian per second. In DEG mode you get 1 degree per second, and in GRAD mode you get 1 grad per second (in each case expressed in radians). That's three different answers, none of which is correct! Exactly the same happens if you convert 1_Hz to angles per second, and the inverse mistake is made if you convert angles per time to cycles or rotations divided by time.
I first learned of this bug from a member of HPCC (the British club for users of HP handhelds), Peter Embrey. He describes his troubles in articles in the first two 1994 issues of our club journal, DATAFILE (in Volume 13 number 1 pages 12 to 14 and V13n2p6). He was calculating the energy stored by a flywheel - given by the formula (1/2)*I*omega^2 and after a time he decided the answers had to be much too big when he CONVERTed from kg*m^2*(r/s)^2 to W*h on an HP48 GX. It turns out that (r/s) are the correct units to get the right answer, but the GX was converting to degrees per second as it was in DEG mode, so his answer was too large by a factor of (360/2pi)^2 - a factor of about 3,300. In this case, his HP48 SX was not much better, since it converted from radians to unit circles. The way to get the correct answer is to use an HP48 G or GX in RAD mode - or to divide out the radians from the formula before using CONVERT. This is not yet a bug, but needs as much care as does use of temperature units on the HP48. But when Peter tried to deal with the problem by working in rpm, he came upon the bug described above. My thanks to Peter for putting me on the trail!
Apparently this bug not been reported before - at least my friends in HP tell me that it was not on their list of known problems until I told them of it. (This means it is not fixed in the new revision R.) Why not - does everyone know about it and work around it without thinking to tell anyone else? Or does no-one use their HP48 to do calculations on rotating bodies - or do most people do calculations with rotating bodies in such a way that they do not encounter this problem? Could there be hundreds of students and engineers out there calculating and designing things on their HP48 G/GX and getting wildly inaccurate results? Has anyone built a disk drive or a jet engine which rotates far too fast and will disintegrate because of this? No, of course not, all engineers know that any design calculation absolutely must be repeated on two entirely separate calculators or computer programs! :-| Maybe some students have lost marks in exams because of this though - but please, this is not intended to restart the discussion as to whether calculators should be allowed in exams!
I want to underline again that apparently no-one has reported this before - which must mean that few people have been affected by it. It is therefore not a good reason to throw away your HP48 G/GX or get on a high horse and demand that HP replace your HP48 G/GX - but I think it is important that people be warned so they can take appropriate avoiding action. The rest of this message goes into more detail - if you never worry about rotation calculations then you can safely ignore the rest - though you might find it interesting, so don't stop yet :-)
One way to avoid this would be to add a new unit to the HP48 - call it what you like - the "cycle" or "rotation" or "revolution" or "unit circle". As I wrote above, this is already implied in the HP48 S/SX; to see this on an HP48 S/SX, put 360 degrees in level 1 and execute UBASE - the result is 1, meaning that 360 degrees are equivalent to one base unit of angle measurement, but that there is no named HP48 unit corresponding to this. In contrast, UBASE on an HP48 G/GX considers the base unit of angle measurement to be the radian, even though CONVERT behaves as though the base unit is the current angle mode. There appear to be two different norms for base angle units on the HP48 G/GX!
The whole subject gets very little mention in HP's manuals. In the original HP48 SX manual (two volumes, spiral bound), the section on "Dimensionless Units of Angle" in chapter 13, on page 198, warns the reader about the danger of using dimensionless units and states how angle units and scalars are treated. In the later HP48 S and HP48 SX manual (one volume), the same warning is given in "Converting Dimensionless Units of Angle", on page 13-12. The HP48 G Series User's Manual, in "Converting Angular Units" on page 10-7, says that conversion will interpret a scalar according to the current angle mode setting. (A scalar is a pure number with no units.)
For a detailed description, look in the HP48 S/SX edition of "HP48 Insights Vol II", section 21.4.3. This book is written by Dr Bill Wickes, who was the design team leader of the HP48 SX, and who wrote the "Insights" books largely to provide the sort of explanations and details that get left out of manuals. A good explanation of angle units is exactly the sort of thing one can find there! He explains the pitfalls and unavoidable contradictions of working with angles in the HP48 units system and points out that the HP48 S/SX make the somewhat arbitrary choice of using 2pi as the base unit of angles, thereby making conversions between angles per time and Hertz work correctly.
Maybe no-one on the HP48 G/GX team read this while they were making changes from the HP48 S/SX! Why did they change the base unit at all? Most likely they were trying to deal with another contradiction: the units system lets you add pure numbers to angles, since both are dimensionless. If you add the number 1 in level 2 to the unit object 0_r in level 1 on an HP48 S/SX, the number 1 is treated as 1 base unit, or 2pi radians, and the result is 6.2832_r - but if you take the SIN of the number 1 instead, it is not treated as 2pi, but as 1 unit of the current angle mode. The change made on the HP48 G/GX does resolve this contradiction, but at the cost of introducing the bug described above.
As mentioned, a way to resolve the problems involved would be to add the angle unit "cycle" explicitly to the HP48 units system. Hz would then be treated as cycles per second when used in calculations involving rotations - rpm would be treated as cycles per minute, and conversions would go from cycles to the appropriate angle units. This suggestion was made by Peter Embrey in his articles, and the folks at HP accept that this is a good solution - but they have not implemented it yet. In the meantime, be very, very careful when converting between units of rotation rate and units of angular frequency. I would urge everyone who does not yet have a copy of Insights II to buy one and read the relevant section - maybe that will even entice Bill Wickes into publishing his long-awaited HP48 G/GX version of the book!
I have not yet mentioned solid angles. In principle there should be no problem - on both the HP48 S/SX and the HP48 G/GX the base unit of solid angle is a "unit sphere", or 4pi steradians. On the HP48 S/SX you can add the pure number 1 to 0_sr and get 12.5664_sr (4pi steradians). The HP48 G/GX manuals imply that exactly the same should happen, but on my (version L) HP48 GX this gives the error message "Inconsistent Units". This is yet another undocumented difference between the Series S and Series G but at least it is no bug!
Apologies for making this description so long, I hope most people will agree that a subject like this deserves a careful description! For my next trick - some details on the HP48 Random Number Generator.
From: Eric Haas
<EHaas@ix.netcom.com>
Note: The < symbol below is actually the angle character.
The angular conversion bug is actually in the definition of the rpm unit. If you put 1_rpm on the stack, and type UBASE, you get 1.66666666667E-2_1/s. Notice that there is no angular unit in the definition. If the rpm unit is instead defined as 6_</s, all conversions to and from rpms will work just fine. As an easy work-around, define the unit RPM as 6_</s and use that instead of the built-in unit.
If desired, one could also define the unit HZ as 60_rpm or 360_</s. However, as Hz is sometimes used to describe things other than rotation rates, such a definition would not be appropriate for all circumstances.
| Previous | Contents | Next |