Login

Ken Ratkevich · 09-01-2006, 02:59 PM

Is it possible to do powers and roots of phasors and/or complex numbers on the hp 33s? If so, can I get a brief tutoral?

bill platt · 09-01-2006, 03:36 PM

See the complex number handling in the HP 32s, 32sii. The 33s does it the same way (in RPN).

Gene Wright · 09-01-2006, 03:42 PM

Basic complex number use on the 33s is covered in this learning module.

It is VERY basic, but might help get you started if you need it.

http://h20331.www2.hp.com/Hpsub/downloads/33sComplex.pdf

Jeff O. · 09-01-2006, 11:53 PM

First off, complex calculations are performed with a 2 level stack. Complex Level y is formed from actual stack levels z and t to hold the real and imaginary components, respectively, of the complex stack level y value. Complex level x uses actual stack levels x and y to hold the real and imaginary components, respectively, of the complex stack level x value. All calculations require the arguments to be in rectangular form. So for example (FIX 4, RPN mode, and since you mentioned phasors, I'll use the "j" notation which I prefer):

To calculate (1 + j 2)²

keystrokes: Display:
2 0.0000
2_

ENTER 2.0000
2.0000

1 2.0000
1_

ENTER 1.0000
1.0000

0 1.0000
0_

ENTER 0.0000
0.0000

2 0.0000
2_

The above sequence loads the stack with the 2 complex numbers. Note that the real number 2, the power to which we wish to raise the complex number (1 + j 2) must be entered as a complex number, (2 + j 0). If we could see the whole stack (and the levels were labelled) it would look like this:

t: 2.0000
z: 1.0000
y: 0.0000
x: 2.0000

completing the calculation:

keystrokes: Display:
leftshift-STO 0.0000
CMPLX_

y^x 4.0000
-3.0000

The answer is (-3 + j 4)

Only the following functions work with complex arguments by pressing leftshift-STO prior to pressing the function key:

e^x

LN

y^x

1/x

SIN

COS

TAN

/ (divide)

x

-

+

If you press other keys, nothing will happen. The calculator will wait for you to press an available function or the C key. So if you want the squre root of a complex number, you must raise it to the (0.5 + j 0) power.

Edited: 2 Sept 2006, 12:00 a.m.

Bruno Férard · 09-02-2006, 07:38 AM

I haven't had much use of it, but if the 33S is supposed to be a replacement for the 15C, why the hell have they done half the job and forgotten hyperbolic function (with their inverse functions), and also the inverse of the SIN/COS/TAN.

That's not a big deal to implement from the libraries of the 15C... and ROM space is no longer an issue nowadays.

bill platt · 09-02-2006, 03:34 PM

33s is not and never was intended to be a 15c replacement.

Nothing has ever replace the 15c, and never did:-)

Seriously though, the eveolution is :

34c-->15c--->42s--->(no successor--go to 48)

65->67-->41c(v,x,y)--->48(s,sx,g,gx)

and,

33c-->11c-->32s-->32sii--->33s

Although the 42s is compatible with (non synthetic) 41c progranning, the 42s has no I/O for reading in programs and is therefore not legitimately in the "line" to the 48 series and beyond.

Basically, HP trimmed out the "top" non-I/O calculators in favor of a two-tier marketing approach for science/engineering applications. (This disregards the brief but interesting foray into algebraic pocket scientific calculators such as the 27s,22s,21s,20s)

Edited: 2 Sept 2006, 3:37 p.m.

Bruno Férard · 09-02-2006, 04:11 PM

I hadn't seen it this way.
Thanks for your clarification.

Karl Schneider · 09-02-2006, 04:48 PM

Bill --

Good points about the "lineage" of the calculator models. In terms of product positioning, the successions are as you indicated.

In terms of specific functionality and ROM code, successions could be shown somewhat differently. For example, the HP-34C has much more in common with the HP-11C than with the HP-15C. The recent thread starting with the title, "Memory Teaser" illustrates this.

And, of course, only the HP-42S offers certain functionality of the HP-41C/CV/CX, but lacks the all-important expandability and I/O that made the HP-41 what it was. The HP-48SX offered both, but its programming paradigm and peripheral hardware were incompatible with that of the HP-41.

So, the HP-41 never had a genuine direct succcessor. Also, while the HP-42S offers all the functionality of the HP-15C, and that both were the top-of-the-line RPN models in their respective series, they are quite different in many ways. You are right: Nothing ever has replaced the HP-15C...

-- KS

bill platt · 09-02-2006, 05:39 PM

Hi Karl,

Yes.

11c came out before the 15c and so I guess that there was always the intention to replace the 34c with a model of equal or greater power but the initial release was the lower end model. As I think you or someone else has pointed out, it is dangerouse to release a lower model after a higher one, if the prices are not appreciably different (e.g.10c)

I will have to go back to that memory teaser and see the specifics!

The transition to the 48 series and abandonment of the 41 paradigm is interesting. It is clear in 20-20 hindsight that within HP, nothing was clear in 1986. What to do? Here they had at the time a popular hi end 41cx, and a popular 15c, and a future that at that time they surely saw was going to include graphing, and they had a product development fully underway (pioneer) etc. I would think that there would be some interesting stories to tell--from the managers at that time. Too bad we can't see a book come out about it. It would shed some light on how technology evolves--and the nexus between "tech" and business--and how mere technical excellence is not enough by itself without timing and good business sense etc.

Edited: 2 Sept 2006, 5:41 p.m.

Valentin Albillo · 09-02-2006, 06:50 PM

Hi, Karl:

Karl posted:

Almost

Best regards from V.

Thomas Okken · 09-02-2006, 08:25 PM

Re: 15C vs. 42S:

Quote:
Nope. Almost all the functionality of the HP-15C, and then some. But some things were lacking nevertheless.

Ummm... Like what?

Valentin Albillo · 09-02-2006, 10:00 PM

Hi, Thomas:

Thomas posted:

"Like what?"

I don't have the HP42S Owner's Handbook at hand right now, but unless I'm mistaken, for example:

You cannot easily enter four complex numbers at once on the 42S stack
in the obvious way, because your first need to enter the real and complex parts separately into the X and Y stack registers, then combine both into a single complex number in the X register. This means losing T's content. On the other hand, the HP-15C allows you to enter a whole complex number into the X register without disturbing the rest of the stack at all.
The HP-15C allows you to work separately on the real and complex parts of a complex number in X without affecting the other component at all and without requiring splitting the complex value previously.
The HP-15C works with matrix descriptors, which clearly identify the precise matrix being dealt with when recalling a matrix to the stack.
In the HP42S, nothing identifies the matrices by name, just their dimensions, which, when manually doing matrix operations directly on the stack is much more confusing, and you may easily lose track of which matrix is in which stack register, most specially if several or all of them do have the exact same dimensions.
"User" STO and RCL with matrices, specially when used in a program, is much more powerful and convenient than the way the HP42 does it. A single STO instruction, say, will store the value into its proper location in the matrix, will automatically advance both row/column pointers to the next element, and will perform a do-if-true conditional operation to allow for either additional looping or termination if the last element was accessed. All of this taking a single program step.
I think there are a number of matrix operations that the HP-15C features but that are missing in the HP42S implementation, such as computation of the Residual (very useful to do iterative refinement in the solution of a system of linear equations, among other advanced uses), or the conditional test behaviour of both norm operatiors (Row & Frobenius) when used in a program, or the use of matrix descriptors in the I (indirect addressing) register, to name a few. All of them are powerful operations which can be put to good practical uses, as I've shown at times in some of my challenges and other postings.

Best regards from V.

Thomas Okken · 09-03-2006, 06:14 AM

Thanks for clearing that up! I clearly need to take the time to read the entire HP-15C manual from cover to cover one of these days -- there appears to be some functionality there that is not obvious by merely looking at the keyboard.

BTW, it sounds like the "User" STO operation (storing a matrix element) is similar to the HP-42S "->" (right arrow) function: it stores an element, advances the row/column index, and sets flags 76 and 77 to indicate if the index has passed the end of a row or the end of the matrix.

I get the feeling that the 15C's fans appreciate its advantages for interactive use; from a programmer's viewpoint, on the other hand, the fact that the 42S does not use matrix descriptors is not an issue, and I feel that 42S programs are easier to read, despite (or maybe because of) the fact that some operations may require more instructions than on the 15C... The design of the two is so different that grafting the advantages of the 15C onto the 42S (or vice versa) could never be achieved without creating a monster. :-)

- Thomas

Karl Schneider · 09-03-2006, 03:31 AM

Hi, Valentin --

Your previous response to Thomas Okken was a good summary of where the HP-42S didn't quite offer every feature or function of the HP-15C. Because I was meaning "functionality" in a more general sense, "having all the functionality" seemed like a reasonably safe statement to make.

I was already aware of several of the shortcomings of the HP-42S that you mentioned. The issue of entering a new complex number onto the stack that already has X, Y and Z occupied is definitely a pitfall. Four years ago, I posted a "challenge" in the Forum asking if anyone knew a way around it, without using storage registers. No one responded.

On the residual calculation for matrices: Although missing on the HP-42S, it can be performed fairly easily on the stack, given the HP-42S' large amount of available RAM. However, on the HP-15C, the residual as a microcoded function was almost essential to have, due to very limited RAM on the HP-15C. If the user were to calculate the residual (R - YX) manually, space for a fourth matrix would have to be reserved for the result of YX. The built-in function conserves RAM space by subtracting each element of YX from R in place.

I've also known that the HP-15C did certain things better than the HP-42S for a given aspect of functionality. (I posted those thoughts a year or two ago, but didn't bookmark the post for ready reference.) The HP-15C matrix descriptors that include a unique identifier in addition to dimensions is very important in linear algebra, because only matrix addition is commutative. I also prefer the more-legible display and the easy accessibility of functions on the non-alphanumeric HP-15C.

Best regards,

-- KS

Edited: 3 Sept 2006, 4:18 a.m.

Valentin Albillo · 09-03-2006, 12:04 PM

Hi, Karl:

Karl posted:

"On the residual calculation for matrices: Although missing on the HP-42S, it can be performed fairly easily on the stack, given the HP-42S' large amount of available RAM.
However, on the HP-15C, the residual as a microcoded function was almost essential to have, due to very limited RAM on the HP-15C. If the user were to calculate the residual
(R - YX) manually, space for a fourth matrix would have to be reserved for the result of YX. The built-in function conserves RAM space by subtracting each element of YX from
R in place."

memory

precision

Doint the same operations on the stack will not give the correct result, because this instruction is typically used to compute residuals, i.e., the result matrix has very small elements throughout.

In the HP42S you've got 12-digit mantissas for your results once returned to the stack, but this means that computing R-YX using a number of discrete stack operations will only get you 12 digits at most, and as you're subtracting very nearly equal numbers (as it's a residual computation), you're bound to lose significant digits no matter what, after the result of YX is computed and rounded to 12-digit, then subtracted from R. The HP-15C avoids all this by never rounding anything but the final product itself, and doing every intermediate computation to full 13-digit accuracy internally.

So, you see, the HP42S can't mimic this particular (and important) operation that easily.

Best regards from V.

bill platt · 09-03-2006, 12:30 PM

Sometimes I wish I had taken on more matrix algebra in my youth. Then again maybe it is better to leave it up to the experts ;-)

There are interesting points about the precision.

In fact they are important in an even larger sense with respect to numerical methods in general and the limitations and pitfalls of teh numerical approach. Apparently these problems come to a head in an especially strong way in matrix work, as you have pointed out, due to the significant digints involved etc.

Edited: 3 Sept 2006, 12:32 p.m.

John Smitherman · 09-10-2006, 06:53 PM

Hi Bill. If you still are interesting in getting more exposure to linear algebra take a look at the information at the MIT Open Courseware web page:

http://ocw.mit.edu/OcwWeb/Mathematics/18-06Spring-2005/CourseHome/index.htm

complete with recorded video lectures found at:

http://ocw.mit.edu/OcwWeb/Mathematics/18-06Spring-2005/VideoLectures/index.htm

Regards,

John

bill platt · 09-11-2006, 01:10 PM

Hey, thanks John!

Karl Schneider · 09-03-2006, 11:49 PM

Hi, Valentin --

Quote:
It's not so much a memory issue as a precision issue. In the HP-15C, the whole R-YX computation is carried out in a single, microcoded instruction, internally using extended precision with 13-digit mantissas. Unless this computation is done at that precision and no less, the result would be useless.
Doing the same operations on the stack will not give the correct result, because this instruction is typically used to compute residuals, i.e., the result matrix has very small elements throughout.

Statements in the HP-15C Owner's Handbook and Advanced Functions Handbook are consistent with what you stated:

OH, p. 159: "Using MATRIX 6 rather than * and - gives a result with improved accuracy, particularly if the residual is small compared with the matrices being subtracted."

AFH, p. 104: "In order for F + Z to be a better approximation to X than is Z, the residual R = B - AZ must be calculated to extended precision. The HP-15C's MATRIX 6 does this. (NOTE: X is the actual solution to AX = B; Z is the estimated solution; and F is the estimated error of Z from X.)

However, I worked through the example on pp. 119-121 of the AFH, which uses an iteration with residual to improve the calculation of the inverse of

A = [ 33  16  72]

    [-24 -10 -57]

    [ -8  -4 -17]

by linear solution for Z of AZ = I.

The determinant of A is exactly 6, which the HP-15C calculates as 5.999999867 -- not near-singular by any means. The matrix is also not ill-conditioned, with a condition number of about 5364.

Using and modifying the program on page 120 of the AFH, I found that calculating the residual R = B - AZ using MATRIX 6 and by manual methods made not one iota of identifiable difference in the calculated residual or in the adjusted solution.

Assuming that matrix multiplication is performed at extended precision (perhaps not so; I haven't found any confirmation), the only computational difference between MATRIX 6 and manual methods would be that the subtraction B - AZ would be computed using 13 significant digits by MATRIX 6, and with 10 significant digits manually. Either way, B has only 10 digits, and the resulting residual R is rounded to 10 significant digits.

I suspect that for most "typical" applications, the additional accuracy of MATRIX 6 is either insignificant or possibly unwarranted. Difficult matrices may be quite another matter...

Still, MATRIX 6 is a valuable built-in function on the HP-15C. In addition to the added computational robustness where necessary, it's more convenient and usable. The manual alternative to obtaining R = B - AC would have been

RCL MATRIX B

STO MATRIX D

RCL MATRIX D

RCL MATRIX A

RCL MATRIX C

RESULT D

*

-

which requires the user to place three matrix descriptors on the stack in the correct order, and also to specify a suitable unique RESULT matrix that takes extra space. (If A, B, and C were each 4x4, all 64 free registers would be required!)

Should the HP-42S have had a built-in "residual" operation? Maybe so, but there's less justification for it -- plenty of space to load input matrices, no RESULT matrix to get wrong, and the extra accuracy might not be usually necessary. Furthermore, with 12-digit arguments, the results are more accurate to begin with.

Best regards,

-- KS

Edited: 4 Sept 2006, 1:11 a.m.

Valentin Albillo · 09-04-2006, 09:56 AM

Hi, Karl:

Karl posted:

"Statements in the HP-15C Owner's Handbook and Advanced Functions Handbook are consistent with what you stated:"

Indeed. The valuable document "Mathematics written in sand" by Mr. Kahan also addresses this particular subject.

"However, I worked through the example on pp. 119-121 of the AFH, which uses an iteration with residual to improve the
calculation of the inverse of [...] I found that calculating the residual R = B - AZ using MATRIX 6 and by manual methods made not one iota of identifiable difference in the calculated residual or in the adjusted solution."

Most likely your test matrix is too small or too little 'problematic' to make any noticeable difference in your case.

"Assuming that matrix multiplication is performed at extended precision (perhaps not so; I haven't found any confirmation) [...]"

As far as I know, it is. Some paragraphs in the above Kahan's document seem to support this.

"I suspect that for most "typical" applications, the additional accuracy of MATRIX 6 is either insignificant or possibly
unwarranted. Difficult matrices may be quite another matter..."

I would say as much, but changing "applications" for "matrices".

"Still, MATRIX 6 is a valuable built-in function on the HP-15C [...] The manual alternative to obtaining R = B - AC would have been [...] which requires the user to place three matrix descriptors on the stack in the correct order, and also to specify a suitable unique RESULT matrix that takes extra space. (If A, B, and C were each 4x4, all 64 free registers would be required!)

Indeed.

"Should the HP-42S have had a built-in "residual" operation? Maybe so, but there's less justification for it

As for me, I certainly prefer the way in which the HP-15C handles numbers and matrices for manual (not program) computations. Matrix descriptors are both elegant and very useful in that case. As for an automatic parallel complex stack which exactly mimics the way the regular stack works, well, enough said.

Best regards from V.

Karl Schneider · 09-02-2006, 05:17 PM

Quote:
but if the 33S is supposed to be a replacement for the 15C, why the h*** have they done half the job and forgotten hyperbolic function (with their inverse functions), and also the inverse of the SIN/COS/TAN.

Bruno --

Bill already explained that the HP-33S descended directly from the HP-32SII and HP-32S, not the HP-15C.

The HP-33S does indeed have hyperbolics and their inverses, as well as inverse trigonometrics, so I assume that your real implication was the lack of complex-valued support for these functions.

I believe that the basis of the complex-valued functionality of the HP-32S/32SII/33S was the HP-41 Math Pac, which provided a set of complex-valued mathematical functions as RPN keystroke programs. The set is mathematically incomplete, but sometimes there are not-unreasonable workarounds.

For example, to take the 3rd power of (6 - j9), one can do the following in lieu of the missing CMPLXx³ function:

6

ENTER

9

+/-

x<>y

3

ENTER

0

x<>y

CMPLXy^x

CMPLXy^x was straightforward to implement, because CMPLXe^x, CMPLXLN, and CMPLX* are present.

CMPLXLOG (base 10) and CMPLX10^x are missing, but CMPLXLN and CMPLXe^x can be used with a simple transformation.

CMPLX* can fill in for the missing CMPLXx², etc...

Now, to take the arcsine of (6 + j9) on an HP-33S, that's a bit tougher...

-- KS

Bruno Férard · 09-03-2006, 07:42 AM

Karl, for the complex arcsin/arccos/arctan, I have found the formulas in the Abramowitz & Stegun page 85 (formulas 4.4.37)

They are not that difficult, and can be programmed in the gigantic 32kb RAM of the 33S.

The point is that you seldom need complex arcsin/arccos, but the day when you need it you find out that your calculator cannot help you, and you need to interrupt your work to dig in the library or ... just pick up you HP28S/48/xx higher-end calculator is your have one.

By the way, I suppose standard computer software (e.g. Excel) will help you in this case, because it's restricted to real parameters.

Actually what I expect from the 33s is to be a reliable calculator intended for number crunching and versatile scientific usage in a small volume. I realize that the 15C was closer to my expectations than the 33S. But I can no loger afford it ($400 is no worth it IMHO).

Edited: 3 Sept 2006, 4:32 p.m.

Karl Schneider · 09-05-2006, 01:42 AM

Bruno --

Thank you for the posting the formulae in your response. Many readers probably have never seen them. They can be derived from algebra and Euler's Identity or looked up in a comprehensive mathematical reference.

It just goes to show how much effort went into programming complete complex-number support for the HP-15C, HP-42S, and the RPL-based models. I'd say that most scientific calculators still don't have it, particularly the low-end models -- whose packages may boast of "complex numbers" but perform only arithmetic and integer-exponent functions using them.

Regards,

-- KS

Valentin Albillo · 09-05-2006, 09:19 AM

Hi, Karl:

Karl posted:

"Thank you for the posting the formulae in your response. Many readers probably have never seen them. They can be derived from algebra and Euler's Identity or
looked up in a comprehensive mathematical reference."

"HP-71B Math ROM Baker's Dozen (Vol. 1)"

my web site

As long as your target machine has basic arithmetic, square root, and natural logarithm defined for complex arguments, you can program all six inverse trigonometric functions in very few lines that way.

"It just goes to show how much effort went into programming complete complex-number support for the HP-15C, HP-42S, and the RPL-based models."

Then, another inmense effort was performed to convert the HP-15C complex-number algorithms for the HP-71B, because compliance with the then still under development IEEE standard, with its Infinities, NaNs, gradually denormalized overflows & underflows, etc, etc, made the implementation of complex handling meeting the IEEE requirements an incredibly complicated affair.

Matter of fact, the HP-71B implementation is actually a bit incomplete, as some compromises had to be made because of time and space limitations. For instance, the Math ROM does not include the inverse trigonometric functions (circular or hyperbolic) defined for complex arguments as the HP-15C does, you must use formulae as featured in my article.

Another, less well known instance is that in the HP-71B, squaring a complex value X by using either X*X or X^2 doesn't necessarily return the exact same IEEE-compliant value in all cases. You must always use X*X to ensure that.

Similarly, you can't use (0, 1)*X to compute i*x , it won't always produce the correct IEEE-compliant value for all X values.

These are minor inconveniences, however, and if you don't care about IEEE compliancy you might forget about them as well. The problem was for the implementors, who were doing their utmost to achieve full IEEE compliancy but ultimately had to leave some minor non-compliant bits here and there ... Talk about nowadays KinHPo "efforts" ...

As for the effort to implement them complex functions in subsequent models (42S, 48, 49), very little was spent, actually. They just inherited the ultra-tuned algorithms from the HP-15C (mostly) and the HP-71B, recoding them if necessary for the specific underlying operating system and architecture. But the algorithms themselves are essentially the same, you don't unnecessarily deal with perfection lest you'll risk ruining it.

Best regards from V.

Karl Schneider · 09-05-2006, 03:47 PM

Hi, Valentin --

Valentin posted:

Quote:
You can also find very simple formulae for the inverse trigonometric functions (both circular and hyperbolic) defined for complex arguments in terms of the standard logarithmic function in my article "HP-71B Math ROM Baker's Dozen (Vol. 1)", freely available on-line as a PDF document at my web site.
As long as your target machine has basic arithmetic, square root, and natural logarithm defined for complex arguments, you can program all six inverse trigonometric functions in very few lines that way.

I had previously downloaded the two parts to your article. Since I have an HP-71 with Math ROM (and manual), I'll be able to explore the 13 topics.

While the basic equations are fairly straightforward, some programming must be incorporated into validation and possible reduction of input arguments, as well as exception handling. I investigated the issue of complex-valued inverse trigonometrics and hyperbolics three years ago when Angel Martin was developing his HP-41 "Sandbox ROM". (These functions are missing from the HP-41 Advantage and Math ROM's, as well as the HP-32S/32SII/33S):

http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv014.cgi?read=48157#48157

You also had contributed substantially to this thread.

Quote:
As for the effort to implement them complex functions in subsequent models (42S, 48, 49), very little was spent, actually. They just inherited the ultra-tuned algorithms from the HP-15C (mostly) and the HP-71B...

On the HP-42S and RPL-based 48/49 models (but not the HP-28C/S), the user may compute with complex-valued arguments in polar form as well as rectangular, which certainly added some new code to the ROM.

Certainly, though, the "heavy lifting" had already been done for the HP-15C.

Best regards,

-- KS

Edited: 5 Sept 2006, 3:49 p.m.

Thomas Okken · 09-05-2006, 05:56 PM

Quote:
On the HP-42S and RPL-based 48/49 models (but not the HP-28C/S), the user may compute with complex-valued arguments in polar form as well as rectangular, which certainly added some new code to the ROM.

Some, but very little -- on the HP-42S at least, the only differences in Polar mode are the behavior of the COMPLEX command, and the way complex numbers are displayed. Internally, the calculator always works with complex numbers in their rectangular form.

- Thomas

Karl Schneider · 09-05-2006, 10:27 PM

Hello, Thomas --

Quote:
... On the HP-42S at least, the only differences in Polar mode are the behavior of the COMPLEX command, and the way complex numbers are displayed. Internally, the calculator always works with complex numbers in their rectangular form.

This surprises me somewhat. Multiplication, division, power, and roots are certainly more straightforward to calculate for operands in polar form. Calculation of LN and LOG will also be streamlined if a polar-form argument is not first converted to rectangular form. There may be other functions where unnecessary conversions can be avoided if the polar form of an input argument is taken into account.

As the developer of Free42, could you please elaborate?

Best regards,

-- KS

Thomas Okken · 09-06-2006, 05:50 AM

Re: all complex numbers in the HP-42S are stored in rectangular, regardless of rectangular/polar mode: I don't remember exactly where I read about this; I think it must be mentioned in the HP-42S manual somewhere.

From an implementation viewpoint, it certainly makes sense. If you support having complex variables in polar form, you'd have two options, both unattractive:

When the mode is switched from Polar to Rectangular or back, convert all complex numbers in the calculator to the corresponding format. If you are working with large complex matrices, this could be slow, and you also suffer round-off error and possible range errors from the conversion. Also, all complex-number operations must be implemented in rectangular *and* polar versions.
Support storing numbers in rectangular and polar form simultaneously. The internal representation of a number depends on the mode the calculator was in when the number was entered. This approach avoids the issues of converting all complex numbers at once (option 1), but now you have to support displaying a complex number in a different format than it is stored, and when it comes to implementing complex functions, you now have four different combinations of complex parameters to worry about.

I agree that performing certain operations is easier, more efficient, and/or more accurate in polar form, but implementing such a system requires *much* more code than a rectangular-only system which "fakes" polar mode by converting numbers on the fly for display.

I have never seen the HP-42S ROM source code, but if you take a look at the Free42 source code, you'll see that the math routines take up a huge chunk of it, and much of the complexity is due to the need to support the different object types that the HP-42S/Free42 supports already. For things like the arithmetic operations, which have to support *sixteen* possible combinations of parameter types, the code is surprisingly complex (no pun intended!)... The extra effort to support "true polar" would have an enourmous impact on code size and on yours truly's personal life. ;-)

(BTW, this is also why I'm dragging my feet with the much-requested "fractions" feature...)

- Thomas

Karl Schneider · 09-07-2006, 12:55 AM

Thomas --

Thank you for your reasoned response. I certainly recognize your experience with Free42, but also submit that there may be a "third way". After all, it's not necessarily a choice between the two "unattractive" options of communism and capitalism... ;-)

Option 1 is like communism -- force all the data to conform to a centrally-dictated format: Inefficient and unattractive.
Option 2 is like laissez-faire capitalism -- the data and operations living and functioning without proper structure and oversight: Semi-chaotic.

I propose, er, "regulated capitalism" for the format of complex numbers. Here's how it could work:

Store numbers in rectangular and polar form simultaneously. The number is represented and displayed in the form in which it was entered.
Extend the mathematics code to include two-input computations where both arguments are in polar format (where applicable.)
The user sets the desired mode of the result of a "mixed-mode" computation -- where one input argument is in polar form, and the other is in rectangular.
For mixed-mode cases, extend the code to decide, based on function and desired output format, which input argument to convert.
The result of a function in which both input arguments are in the same mode, is displayed in that mode.
The result of a function involving one real-valued input and one complex-valued input takes the mode of the complex-valued input.

As a simpler alternative, all numbers could be stored -- and all computations performed -- in rectangular mode. However, each complex-valued number would retain a display-mode bit to make possible the other aspects of the above scheme.

Certain operations are difficult or impossible to perform in polar form: {+, -, SIN, COS}. Others are simpler: {*, /, z^x with x real}.

This approach has the advantage of maintaining the format of the complex number entered by the user, which will be more meaningful and "rememberable" than a converted value. An illustrative example is AC power transfer, in which voltage and current is usually represented in polar format because they are sinusoidal phasors; impedance, admittance, and complex power are usually represented in rectangular format, becuase they are not phasors.

Also, some calculations will be more accurate without unnecessary and unproductive conversions. When conversions are necessary, well, "you do 'em now or do 'em later."

NOTE: The above is not a plea for you to do more work with Free42; it is only my concept of what good complex-number functionality in a calculator should be. Here's an archived post:

http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv014.cgi?read=63415#63415

Best,

-- KS

Edited: 7 Sept 2006, 1:26 a.m.

Jeff O. · 09-07-2006, 10:15 PM

Karl,

I was going to compose and post a response to Thomas' expressing similar sentiments. Yours is quite well stated and I agree with virtually all points. Thanks for saving me the trouble of formulating a cogent response. With the above said, I do have one or two points:-)

From the user's perspective, I don't think I care how the calculator stores the data. It does somehow seem like a consistent format would be best, that way you don't have to check the format before every calculation to determine what to do. Rectangular form seems more basic or fundamental, with no need to worry about the angular display mode setting. So I'll go with what I'll call your Option 4 -

Quote:
....all numbers could be stored -- and all computations performed -- in rectangular mode. However, each complex-valued number would retain a display-mode bit to make possible the other aspects of the above scheme.

plus of course the Convenient one-line entry in either rectangular or polar form and Full menu of mathematical operations for complex numbers items from your earlier post.

At this point I was going to go into a rant about how inelegant I find the complex number handling and display methods of the 48/49/50 models, to compare and contrast with your proposal. I decided that such a rant would probably just show how little I know about those models, i.e. I'd describe the cumbersome procedure that I see as the only way to enter a complex number in polar form, and one of the experts would point out that all you need to do is such and such. Suffice it to say, I've just never been able to get comfortable with it. On the other hand, the 15C and 42S methods seemed natural from the first time I used them, and the methods would be essentially perfect with the improvements in items 3 through 6 of your post, plus one more thing:

Quote:
No parentheses or commas in the display!

As far as pleading with Thomas to implement something like you propose with Free42, I also do not wish to do so. I want him to implement the changes (plus a couple of others - variable stack height, display of four stack levels plus last X) in a new application, lets call it Free43! Just kidding Thomas, you have done way more than your share. (But if you do happen to get a few free moments.....) Actually, I have this crazy idea that I should take Thomas’ Free42 source code, do what it takes to make it run under HPGCC on the 50g, then modify the code as needed to create Free43 to run on the 50g. All I have to do is learn C programming itself and learn the “ins and outs” of compiling programs in general and using HPGCC. I might be able to do these things (after all, I once learned rudimentary FORTRAN programming), but the brief glimpses I have taken of HPGCC and C programming look quite daunting. However, I did put C Programming for Dummies on my list of books that I want, so who knows....

Edited: 7 Sept 2006, 10:39 p.m. after one or more responses were posted

Paul Dale · 09-07-2006, 10:37 PM

These do seem like good ideas. If I code the OpenRPN complex functions, I'll be sure to include as many as I can. Of course if somebody else volunteers to code them, who knows. Complex numbers aren't something I use often.

- Pauli

Karl Schneider · 09-08-2006, 01:38 AM

Hi, Jeff --

Thanks for the compliments...

Quote:
Rectangular form seems more basic or fundamental, with no need to worry about the angular display mode setting.

It is, and you make a good point about not having to keep track of the angular setting by storing data in rectangluar form. If polar-form numbers were always stored in radians, there might be some unnecessary conversions.

There are at least three ways to produce a complex number for which my scheme would require the user to specify how it is to be displayed:

Produced by operation on real number (e.g., LN(-3), SQRT(-3))
Produced by operation on two complex numbers in different modes
Produced by assembly of two real numbers (R->C function)

It would be simplest to apply the user-set display mode for all three cases, even though it might not always be what the user wants...

Regards,

-- KS

Thomas Okken · 09-11-2006, 03:17 AM

Hi all,

Sorry for the slow reply -- I just got back from a few days in Denmark and Sweden and didn't run into any cybercafés on the way. ;-)

I think Karl made a good point that it isn't necessary to implement complex functions for *all* possible combinations of inputs; simply writing special-case polar-polar functions where needed, and automatically coercing parameters where special-case functions aren't available, is an elegant approach -- easy to implement and extend.

Rest assured that I remain interested in possibilities to improve Free42; various complex-number-related proposals are on my to-do list already.

I'll be moving to a new job and a new apartment (in fact, a new continent) soon; once I've recovered from those upheavals and settled in, I hope I'll find the time to do some work on Free42 and my other personal projects again. (Until then, bug fixes only! Stay tuned.)

- Thomas

Paul Dale · 09-11-2006, 03:28 AM

Quote:
...simply writing special-case polar-polar functions where needed, and automatically coercing parameters where special-case functions aren't available, is an elegant approach...

The OpenRPN numerics are done somewhat in this style. Binary reals, BCD reals and both integer formats all automatically widen as required. I'm planning on doing long reals similarily. Something similar is definitely possible with complex numbers and one obvious distinction is polar vs not.

- Pauli

Rodger Rosenbaum · 09-05-2006, 07:47 PM

Quote:

Similarly, you can't use (0, 1)*X to compute i*x , it won't always produce the correct IEEE-compliant value for all X values.

Can you give us an example of this?

Jeff O. · 09-03-2006, 05:53 PM

Karl,

I would have entered your example problem like this:

9

+/-

ENTER

6

ENTER

0

ENTER

3

CMPLXy^x

Do you do it your way (first key in real, then key in imaginary, then exchange) to mimic the way it's done on the 15C and 42S (first key in real, then imaginary, then f-I or shift-COMPLEX, respectively?

Karl Schneider · 09-05-2006, 01:32 AM

Jeff --

Sure, one can enter the real- and imaginary-valued components in reverse order in order to get them into their correct positions without using x<>y. I thought it was more intuitive to show them entered in conventional order.

This issue also comes up when entering (x,y)-pairs of statistical data for the RPN-based calculators...

I try to use an HP-15C or HP-42S for interactive computations with complex numbers.

-- KS

Ken Ratkevich · 09-02-2006, 08:06 AM

Thanks a million! You have hit the nail right on the head!!! After reading your detailed reply and referring back to the manual, I now understand how to deal with REAL number powers and roots of complex numbers.

I sincerely appreciate your help. This forum is GREAT! Thanks again.

Ken

Ken Ratkevich · 09-02-2006, 08:11 AM

OOPS!

I responded to the wrong response. See my response to Bruno Ferards' post.

Also, thanks Bruno for your input. I really appreciate it.

Ken

Tim Wessman · 09-02-2006, 09:51 AM

I hate to bring up the dark side here, but if I remember right it is actually easier to do complex calculations in algebraic mode. I think you can chain complex numbers together in multiple groups and they also display nicely. Give that a shot as well.

TW

Ken Ratkevich · 09-02-2006, 10:40 AM

Thanks,

I'm working on algebraic mode now. I think you're right! I'm new to both this type of math AND the hp 33s so it's taking me a little longer to digest this stuff.

Thanks again for your input,

Ken

Edited: 2 Sept 2006, 10:41 a.m.

Login
Username:
Password:	Lost Password?
	Remember me