j^j and the HP-33S



#5

An unintuitive mathematical fact:

jj = e-pi/2 = 0.207879576

where j = sqrt(-1) and j2 = -1

The proof (which is left as an exercise for the reader) requires the use of Euler's identity and trigonometric/hyperbolic identities derived therefrom:

ejx = (cos x) + j*(sin x)

sin jx = j * sinh x

cos jx = cosh x

On any RPN or RPL calculator designed and engineered by Hewlett-Packard with complex-number capabilities, jj can always be evaluated correctly. For example:

HP-15C        HP-42S

1 0
f Re<->Im ENTER
ENTER 1
y^x f CMPLX
ENTER
y^x

For the 32S, 32SII, 33S, and 41C* with Math or Advantage ROM, a different approach is used:

1
ENTER
0
ENTER
1
ENTER
0
f CMPLXy^x XEQ Z^W
(32/33) (41/Math/Adv)

This procedure works for all four calculators, but the 33S gives the incorrect answer e-3*pi/2 = 0.008983291 when the zero in the z-register is negated (-0).

The root cause of this problem is the same one that causes the incorrect rectangular-to-polar conversions with 0 or -0 in the x-register, which I and others documented fully, several months ago in this forum.

Calculation of jj requires the calculation of ln(j).

Re [ln(a+jb)] = ln (sqrt(a2+b2)) 
Im [ln(a+jb)] = atan2(a, b) [in radians] -- primary solution

The antilogarithm of the j residing in the "upper" part of the stack is taken. Since the 33S calculates the phase angle of (-0 + j1) incorrectly, the answer given for j^j is incorrect.

Norris (or anyone else), has HP addressed the polar-angle and other bugs?

-- KS

Edited: 28 Nov 2004, 12:01 a.m.


#6

"Norris (or anyone else), has HP addressed the polar-angle and other bugs?"



The best thing HP might do is to give a workaround example

To really fix the ROM?

I would not do it in the first year,

since new bugs are found every now and then

[VPN]

PS: opinions only...

#7

HP has published a 33S "User's Manual Update" that acknowledges the rectangular->polar conversion bug, the ->HMS bug, and the nCr bug, and offers workarounds.

For the rect-polar bug, the suggested workaround is to take the absolute value of any zeros in the input (x,y) data.

As far as I know, publication of the "update" is the only action that HP has taken to address 33S bugs.

I have a "substitute" rect-polar conversion routine assigned to XEQ T on my 33S; it checks for zeros and "fixes" them before doing the conversion (I originally used CLx, instead of ABS; they both seem to work). It would, of course, be possible to prepare similar "substitute" routines for complex math functions, if you needed them. Not the best possible use of scarce 33S labels, though.

Edited: 28 Nov 2004, 3:51 p.m.

#8

Hi, all

Karl posted:

"An unintuitive mathematical fact:
j^j = e-pi/2 = 0.207879576"

For an added counterintuitive "thrill", try and plot the
values of

      i, i^i, i^i^i, i^i^i^i, i^i^i^i^i, ...
in graph paper (any HP calculator will do, save perhaps some of the latest KinHPo crap) or using your graphics HP model.
As usual, the horizontal axis denotes the real part, the vertical axis denotes the imaginary part of the result, and expressions of the type a^b^c^... should be calculated right-to-left, i.e: a^b^c^d = a^(b^(c^d)).

You'll be quite surprised at the beautiful resulting graphic, and it's highly improbable that you would have foreseen in advance its 'three-pronged' shape. :-)

Best regards from V.

Edited: 29 Nov 2004, 8:01 a.m.


Possibly Related Threads...
Thread Author Replies Views Last Post
  Integration Times "Old" 33s vs "New" 33s John Smitherman 21 1,326 12-14-2005, 12:04 AM
Last Post: Karl Schneider

Forum Jump: