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?
Powers and roots of phasors on hp 33s ???


« Next Oldest  Next Newest »

▼
09012006, 02:59 PM
▼
09012006, 03:36 PM
See the complex number handling in the HP 32s, 32sii. The 33s does it the same way (in RPN). ▼
09012006, 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
09012006, 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): keystrokes: Display: 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.0000Only the following functions work with complex arguments by pressing leftshiftSTO prior to pressing the function key: e^{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. ▼
09022006, 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. ▼
09022006, 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 successorgo 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" nonI/O calculators in favor of a twotier 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. ▼
09022006, 04:11 PM
I hadn't seen it this way.
09022006, 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 HP34C has much more in common with the HP11C than with the HP15C. The recent thread starting with the title, "Memory Teaser" illustrates this. And, of course, only the HP42S offers certain functionality of the HP41C/CV/CX, but lacks the allimportant expandability and I/O that made the HP41 what it was. The HP48SX offered both, but its programming paradigm and peripheral hardware were incompatible with that of the HP41. So, the HP41 never had a genuine direct succcessor. Also, while the HP42S offers all the functionality of the HP15C, and that both were the topoftheline RPN models in their respective series, they are quite different in many ways. You are right: Nothing ever has replaced the HP15C...  KS ▼
09022006, 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 2020 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 tellfrom 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 evolvesand the nexus between "tech" and businessand how mere technical excellence is not enough by itself without timing and good business sense etc. Edited: 2 Sept 2006, 5:41 p.m.
09022006, 06:50 PM
Hi, Karl: Karl posted:
▼
09022006, 08:25 PM
Re: 15C vs. 42S:
Quote: Ummm... Like what? ▼
09022006, 10:00 PM
Hi, Thomas: Thomas posted:
I don't have the HP42S Owner's Handbook at hand right now, but unless I'm mistaken, for example:
Best regards from V. ▼
09032006, 06:14 AM
Thanks for clearing that up! I clearly need to take the time to read the entire HP15C 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 HP42S ">" (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
09032006, 03:31 AM
Hi, Valentin  Your previous response to Thomas Okken was a good summary of where the HP42S didn't quite offer every feature or function of the HP15C. 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 HP42S 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 HP42S, it can be performed fairly easily on the stack, given the HP42S' large amount of available RAM. However, on the HP15C, the residual as a microcoded function was almost essential to have, due to very limited RAM on the HP15C. 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 builtin function conserves RAM space by subtracting each element of YX from R in place. I've also known that the HP15C did certain things better than the HP42S 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 HP15C 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 morelegible display and the easy accessibility of functions on the nonalphanumeric HP15C. Best regards,  KS
Edited: 3 Sept 2006, 4:18 a.m. ▼
09032006, 12:04 PM
Hi, Karl: Karl posted:
"On the residual calculation for matrices: Although missing on the HP42S, it can be performed fairly easily on the stack, given the HP42S' large amount of available RAM.
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 12digit mantissas for your results once returned to the stack, but this means that computing RYX 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 12digit, then subtracted from R. The HP15C avoids all this by never rounding anything but the final product itself, and doing every intermediate computation to full 13digit accuracy internally. So, you see, the HP42S can't mimic this particular (and important) operation that easily.
▼
09032006, 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. ▼
09102006, 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/1806Spring2005/CourseHome/index.htm complete with recorded video lectures found at: http://ocw.mit.edu/OcwWeb/Mathematics/1806Spring2005/VideoLectures/index.htm Regards, John
09032006, 11:49 PM
Hi, Valentin 
Quote: Statements in the HP15C 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 HP15C'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. 119121 of the AFH, which uses an iteration with residual to improve the calculation of the inverse of
A = [ 33 16 72] by linear solution for Z of AZ = I. The determinant of A is exactly 6, which the HP15C calculates as 5.999999867  not nearsingular by any means. The matrix is also not illconditioned, 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 builtin function on the HP15C. 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 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 HP42S have had a builtin "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 12digit arguments, the results are more accurate to begin with. Best regards,  KS
Edited: 4 Sept 2006, 1:11 a.m. ▼
09042006, 09:56 AM
Hi, Karl:
Karl posted:
"However, I worked through the example on pp. 119121 of the AFH, which uses an iteration with residual to improve the
"Assuming that matrix multiplication is performed at extended precision (perhaps not so; I haven't found any confirmation) [...]"
"I suspect that for most "typical" applications, the additional accuracy of MATRIX 6 is either insignificant or possibly
"Still, MATRIX 6 is a valuable builtin function on the HP15C [...] 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!)
"Should the HP42S have had a builtin "residual" operation? Maybe so, but there's less justification for it
As for me, I certainly prefer the way in which the HP15C 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.
09022006, 05:17 PM
Quote: Bruno  Bill already explained that the HP33S descended directly from the HP32SII and HP32S, not the HP15C. The HP33S does indeed have hyperbolics and their inverses, as well as inverse trigonometrics, so I assume that your real implication was the lack of complexvalued support for these functions. I believe that the basis of the complexvalued functionality of the HP32S/32SII/33S was the HP41 Math Pac, which provided a set of complexvalued mathematical functions as RPN keystroke programs. The set is mathematically incomplete, but sometimes there are notunreasonable workarounds. For example, to take the 3rd power of (6  j9), one can do the following in lieu of the missing CMPLXx^{3} function:
6 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^{2}, etc... Now, to take the arcsine of (6 + j9) on an HP33S, that's a bit tougher...  KS ▼
09032006, 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 higherend 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. ▼
09052006, 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 complexnumber support for the HP15C, HP42S, and the RPLbased models. I'd say that most scientific calculators still don't have it, particularly the lowend models  whose packages may boast of "complex numbers" but perform only arithmetic and integerexponent functions using them. Regards,  KS ▼
09052006, 09:19 AM
Hi, Karl: Karl posted:
looked up in a comprehensive mathematical reference."
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 complexnumber support for the HP15C, HP42S, and the RPLbased models."
Then, another inmense effort was performed to convert the HP15C complexnumber algorithms for the HP71B, 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 HP71B 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 HP15C does, you must use formulae as featured in my article. Another, less well known instance is that in the HP71B, squaring a complex value X by using either X*X or X^2 doesn't necessarily return the exact same IEEEcompliant 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 IEEEcompliant 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 noncompliant 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 ultratuned algorithms from the HP15C (mostly) and the HP71B, 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. ▼
09052006, 03:47 PM
Hi, Valentin  Valentin posted:
Quote: I had previously downloaded the two parts to your article. Since I have an HP71 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 complexvalued inverse trigonometrics and hyperbolics three years ago when Angel Martin was developing his HP41 "Sandbox ROM". (These functions are missing from the HP41 Advantage and Math ROM's, as well as the HP32S/32SII/33S): http://www.hpmuseum.org/cgisys/cgiwrap/hpmuseum/archv014.cgi?read=48157#48157 You also had contributed substantially to this thread.
Quote: On the HP42S and RPLbased 48/49 models (but not the HP28C/S), the user may compute with complexvalued 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 HP15C. Best regards,  KS
Edited: 5 Sept 2006, 3:49 p.m. ▼
09052006, 05:56 PM
Quote: Some, but very little  on the HP42S 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 ▼
09052006, 10:27 PM
Hello, Thomas 
Quote: 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 polarform 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
▼
09062006, 05:50 AM
Re: all complex numbers in the HP42S 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 HP42S 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:
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 rectangularonly system which "fakes" polar mode by converting numbers on the fly for display. I have never seen the HP42S 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 HP42S/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 muchrequested "fractions" feature...)  Thomas ▼
09072006, 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... ;)
I propose, er, "regulated capitalism" for the format of complex numbers. Here's how it could work:
As a simpler alternative, all numbers could be stored  and all computations performed  in rectangular mode. However, each complexvalued number would retain a displaymode 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 complexnumber functionality in a calculator should be. Here's an archived post: http://www.hpmuseum.org/cgisys/cgiwrap/hpmuseum/archv014.cgi?read=63415#63415 Best,  KS
Edited: 7 Sept 2006, 1:26 a.m. ▼
09072006, 10:15 PM
Karl, Quote:plus of course the Convenient oneline 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: 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 ▼
09072006, 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.
09082006, 01:38 AM
Hi, Jeff  Thanks for the compliments...
Quote: 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 polarform 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:
It would be simplest to apply the userset display mode for all three cases, even though it might not always be what the user wants... Regards,  KS ▼
09112006, 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 specialcase polarpolar functions where needed, and automatically coercing parameters where specialcase 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 complexnumberrelated proposals are on my todo 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 ▼
09112006, 03:28 AM
Quote: 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.
09052006, 07:47 PM
Quote: Can you give us an example of this?
09032006, 05:53 PM
Karl,
9Do 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 fI or shiftCOMPLEX, respectively? ▼
09052006, 01:32 AM
Jeff  Sure, one can enter the real and imaginaryvalued 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 RPNbased calculators... I try to use an HP15C or HP42S for interactive computations with complex numbers.  KS
09022006, 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
09022006, 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 ▼
09022006, 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 