HP48 Frequently Asked Questions List (FAQ): Appendix C: Details of Bugs https://www.hpcalc.org/hp48/docs/faq/48faq-11.

html

HP48 FAQ Section 11: Appendix C: Details of

11.1 The EquationWriter Bug

Rev E Behaviour

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 /

which is as it should be. But now press [orange-shift] [+]; see the message "Implicit () off"
momentarily; press [left-arrow] (not backspace), then press the [EXIT] softkey. The
expression gets mangled into this:
1+2
----------- (B)
(5)
(3+4)

which is not equal to expression (A) above! Bug, yes? Press ON to abort the process.

Now set flag -53, then repeat the above procedure. First you see:
5
/ 1+2 \
| --- | (C)
\ 3+4 /

which is the same as (A) above; but continuing as before, you see:
(5)
/ 1+2 \
| ----- | (D)
\ (3+4) /

which is equal to the original. Thus the bug can be worked around by keeping flag -53 set (not
a pleasant solution).
Rev J Behaviour

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.

1 of 5 2/1/2023, 4:51 PM
HP48 Frequently Asked Questions List (FAQ): Appendix C: Details of Bugs https://www.hpcalc.org/hp48/docs/faq/48faq-11.html

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 /

(notice the extra parentheses?) and then:

which is equal to (A'); nothing at all like expression (B) above! and then:
5
/ (1+2) \
| ----- | (C')
\ 3+4 /

which is the same as (A') above; and then:

which is also equal to (A'). No bug in Rev J.

SUMMARY: Rev A-E have a bug in the EquationWriter that can mangle expressions if flag -53 is
clear (the default) and if "Explicit Parentheses" mode is toggled. This bug has been fixed in Rev J.

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.

11.2 Rotation Rate to Angular Frequency Conversion Bug

From: Wlodek Mier-Jedrzejowicz <[email protected]>

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

2 of 5 2/1/2023, 4:51 PM
HP48 Frequently Asked Questions List (FAQ): Appendix C: Details of Bugs https://www.hpcalc.org/hp48/docs/faq/48faq-11.html

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!

3 of 5 2/1/2023, 4:51 PM
HP48 Frequently Asked Questions List (FAQ): Appendix C: Details of Bugs https://www.hpcalc.org/hp48/docs/faq/48faq-11.html

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!

4 of 5 2/1/2023, 4:51 PM
HP48 Frequently Asked Questions List (FAQ): Appendix C: Details of Bugs https://www.hpcalc.org/hp48/docs/faq/48faq-11.html

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.

Addition Insight:

From: Eric Haas <[email protected]>

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

Part of the HP Calculator Archive - http://www.hpcalc.org/

5 of 5 2/1/2023, 4:51 PM