HP-15C: Library of complex-number utilities



#8

HP-15C fans --

Here is a compact library of seven complex-number utility functions for the HP-15C. It provides the "missing" basic operations for manipulating complex numbers in rectangular format, available under the CMPLX menu of the HP-28, as well as with other RPL-based models. (ABS, R->C, R->P, and P->R are already provided by the HP-15C. ARG can be performed by R->P followed by "Im" from this library.)

Background: http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv017.cgi?read=124707#124707

There was not enough room on the Voyager-series keyboard and backplate for HP to provide these operations natively as microcoded functions on the HP-15C. However, HP astutely specified that CLx and CHS in complex mode would operate only on the real-valued part of a number, ignoring the corresponding value in the parallel imaginary stack. While this can be a "gotcha" for the unwitting user, it enabled standard operations to be performed on complex numbers with only a few instructions.

This 30-line library utilizes labels 0 through 6, one for each function. Each instruction is one byte, so the total library needs four registers plus two bytes. It is designed as a permanent-residence program for users who frequently manipulate complex numbers. (If labels .0 through .6 were used, nine additional bytes would be needed, due to two-byte instructions.)

The labels are selected mnemonically:

  • Functions "0" (clear) and "1" (negate) serve in effect to multiply a complex number by 0 and -1 respectively without disturbing the stack, except that "clear" disables stack push.
  • Function "2" (conjugate) is a subset of negation.
  • Function "3" (signum -- a unit-magnitude number that preserves the sign of each component) is unrelated to the others, but fills the empty slot.
  • Functions "4" (C->R decomposition; inverse of "f I"), "5" (extract real value), and "6" (extract imaginary value) are interrelated and combined.

-- Compactness is achieved by using labels as entry points to utilize common overlapping instructions.

-- Each function except "3" uses no extra stack levels. (Function "3" usually pushes the stack one level).

-- No function uses any memory register or flag.

-- Function "4" uses a GSB call to save a few instructions; this will cause an error condition only if it is called within a routine that already has seven pending subroutine calls.

-- Answers will be mathematically correct using real-valued or complex-valued inputs. However, each function will set complex mode, except for Function "3" with a real-valued input.


FUNCTIONS:

   0          1		   2	       3         4	     5		 6
"Clear" "Neg" "Conj" "Signum" "C->R" "Re" "Im"
CLx CHS Re<->Im x=0? ENTER Re<->Im CLx
Re<->Im Re<->Im CHS RTN Re<->Im CLx Re<->Im
CLx CHS Re<->Im ENTER CLx Re<->Im
Re<->Im ABS Re<->Im
/ x<>y
CLx
Re<->Im

LISTING:

001-  42,21, 0    LBL 0	    "Clear" 
002- 43 35 CLx
003- 42 30 Re<->Im
004- 43 35 CLx
005- 43 32 RTN
006- 42,21, 1 LBL 1 "Neg"
007- 16 CHS
008- 42,21, 2 LBL 2 "Conj"
009- 42 30 Re<->Im
010- 16 CHS
011- 42 30 Re<->Im
012- 43 32 RTN
013- 42,21, 3 LBL 3 "Signum"
014- 43 20 x=0?
015- 43 32 RTN
016- 36 ENTER
017- 43 16 ABS
018- 10 /
019- 43 32 RTN
020- 42,21, 4 LBL 4 "C->R"
021- 36 ENTER
022- 32 5 GSB 5
023- 34 x<->y
024- 22 6 GTO 6
025- 42,21, 5 LBL 5 "Re"
026- 42 30 Re<->Im
027- 42,21, 6 LBL 6 "Im"
028- 43 35 CLx
029- 42 30 Re<->Im
030- 43 32 RTN


Edited: 16 May 2008, 2:23 a.m. after one or more responses were posted


#9

Hi, Karl:

    Thanks for your effort on behalf of HP-15C fans, much appreciated.

    May I suggest that you amend the SIGN function adding two extra steps, so that it reads like this:

        013-  42,21, 3    LBL 3     "Sign"
    014- 43 20 X=0? check for zero <<<<<<<<<<<<<<<
    015- 43 32 RTN if zero, return zero <<<<<<<<<
    016- 36 ENTER
    017- 43 16 ABS
    018- 10 /
    019- 43 32 RTN

    the idea being, of course, to avoid the error (Error 0) you'd surely get if using the routine with a zero input. These two steps detect this case and return zero as the SIGN value.

Best regards from V.

#10

Hi, Valentin --

Yes, that's precisely the tidy solution I had in mind for addressing signum for an input of zero (after I'd ceased work on the routine for the evening).

I'd considered refining the routines so that they would not activate complex mode when provided real-valued inputs without complex mode set, but it just wasn't worth it -- a two-byte "F? 8" at practically every label and extra instructions, which would defeat the purpose of compactness. My initial suspicions were unfounded: the complex-mode answers will be correct, even when given inputs with complex mode not set.

Routine "3" utilizes two special features of built-in HP-15C functionality in complex mode: ABS will compute the pythagorean magnitude of a complex number, and the test x=0? (as well as x/=0?) test both parts of a complex number. (The other ten tests compare only the real part, because results using both parts could be different.)

Do you see any sensible size-reducing optimizations to get back to four registers? All I see is replacement of lines 002 and 003 with "GSB 6" to save one instruction.

-- KS

Edited: 15 May 2008, 6:31 a.m.


#11

Quote:
(The other ten tests compare only the real part, because results using both parts could be different.)

The wording is questionable. In the complex plane there is no "less than" or "greater than" relationship. Therefore, the tests <, >, <=, >= and the like are meaningless for complex numbers.

#12

The Owner's Handbook says, on page 132, that TEST 5 (x=y) and TEST 6 (x#y) also involve the complex stack. This is what one would expect.


#13

Roger, Marcus --

Yes, you're both right. Only tests for equality and inequality are meaningful for full complex values; working from memory, I simply forgot about those comparisons with y.

My point was the attention to detail in the functional specification for how the conditional tests work with flag 8 set. The most-sensible and useful functionality -- if not the most consistent -- was provided: "Use the full complex number if possible for a meaningful test; else, use only the real part."

Consider what HP could have done for the HP-15C:

-- No conditional-test functionality in complex mode because not all tests were defined;

-- The same functionality as for reals, blithely ignoring the imaginary parts for the equality and inequality tests;

-- Unorthodox tests, such as comparing the magnitudes of complex numbers, or requiring that both components meet the test for a result of "true".

No -- they thought it through, as they did for everything else.

The HP-42S does it differently: None of the conditional tests for zero are defined for complex-number input, but equality and inequality tests are defined for comparing two input complex numbers. Of course, the HP-42S' paradigm is different, as complex values can be placed in the stack, instead of having the imaginary-valued components in a separate stack. Complex numbers can be easily disassembled to execute the kind of test desired.

The HP-35s? "INVALID DATA" across the board for any conditional test using complex-valued input. And the user can't easily deconstruct or extract parts of a complex number...


Here's another subtle but important feature of the HP-15C: With flag 8 set, when entering a new value into the x-register immediately following ENTER (stack lift is disabled), the imaginary part of the number is changed to 0. Thus,

3 ENTER 4 I     3 ENTER 4 I 
5 ENTER
* 5
*

will each give the correct answer of 15+j20 (even though ENTER is unnecessary), and will work the same way as in real mode, as do the following:

3          3 ENTER 4  I
ENTER ENTER
* *

Each gives the respective x2 answers of 9 and -7+j24.

When stack lift is disabled as a result of CLx, the imaginary part is not changed when a new value is entered.

Plenty of potential pitfalls were adroitly avoided when the pioneering full complex-number support for this paradigm of calculator was developed. HP nailed it, and I'm sure that some systematic methodology -- used by skilled and knowledgable developers -- is significantly responsible for that.

-- KS


Edited: 16 May 2008, 2:18 a.m.


#14

Quote:
and I'm sure that some systematic methodology -- used by skilled and knowledgable developers -- is significantly responsible for that.

Yes, I agree. That's precisely the reason we have now a calculator (the HP-35S) which is averagely good for everything but fails to match the exact need of those who use complex numbers (and other "minor" points, like bugs and the rest).

-- Antonio


Possibly Related Threads...
Thread Author Replies Views Last Post
  HP Prime: complex numbers in CAS. Alberto Candel 1 407 12-06-2013, 02:36 PM
Last Post: parisse
  [HP Prime] Plots containing complex numbers bug? Chris Pem10 7 752 12-05-2013, 07:40 AM
Last Post: cyrille de Brébisson
  A fast Bernoulli Number method for the HP Prime Namir 16 1,283 11-22-2013, 04:46 PM
Last Post: Namir
  Complex Number Entry on Prime Jeff O. 19 1,528 11-16-2013, 12:34 PM
Last Post: Jeff O.
  [HP Prime] Calculating Prandtl Number with Units (bug found in USIMPLIFY) Timothy Roche 1 310 11-13-2013, 04:07 PM
Last Post: cyrille de Brébisson
  HP Prime: Converting number to Sci notation and back BruceTTT 1 304 11-12-2013, 02:11 AM
Last Post: Phil Wipf
  Library#4 Modules mass-update and New Overlays Ángel Martin 0 347 11-09-2013, 05:55 AM
Last Post: 'Angel Martin
  HP PRIME: Fixed 4 number format 0.001000 Joseph Ec 18 1,430 11-07-2013, 11:51 AM
Last Post: Geoff Quickfall
  [HP Prime] Constants Library Values Timothy Roche 24 1,827 11-02-2013, 04:17 PM
Last Post: Les Koller
  HP Prime: Number of external Variables Davi Ribeiro de Oliveira 0 251 11-01-2013, 08:10 PM
Last Post: Davi Ribeiro de Oliveira

Forum Jump: