rcorless@uwovax.uwo.ca (09/27/90)
>In article <1473@meaddata.meaddata.com>, mead!johnt@uccba.uc.edu > (John Townsend) writes: > > This reminds me of when I first got my HP-28C when I was in college. The first > thing I did with it was "acid-test" it by calculating the cube root of -27. > Every sixth-grader knows that the answer to this is simply -3, but most > calculators (including every TI I've ever seen) gag on it. I would remark that the only calculators to get this right are the HP28C and HP28S. The HP48SX gets it right, too, but only if you use '(-27)^(1/3)' or equivalent, and not -27 ENTER 3 `xth root of y` which returns the inconsistent real root -3. What, you say? That's crazy? Not at all. The very best thing (in my opinion - admittedly if you poll N people you will get N+1 different "very best things" about the 28/48 - one of my student's "very best thing" was that the 28 shut itself off after 10 minutes...) about the 28 is its ability to handle complex numbers transparently and consistently. This means consistently using the principal branch. This means for root extraction, as you say, the first one going counter clockwise around the origin, and for logs that the imaginary part be between -Pi and Pi. > [ ... stuff about complex numbers omitted ... ] > ... Turns out that the 28C returns the first of > these (going around the complex plane counterclockwise from the X axis). The > other two solutions are (-3,0) and (1.5,-2.59807621135). The 28C will cube all > of these back into -27. That sure raised by opinion of HP in a hurry! Mine, too. The fact that the HP uses the principal branch by default makes life a lot simpler when you deal with functions of a complex variable. I wish to publicly congratulate HP for doing an extremely intelligent job on this, and I know that they will have suffered flak about it ("why doesn't this dumb calculator take cube roots properly?"). I know they have taken flak about it because they have put a compromise in in the 48 - the above-mentioned xth-root-of-y button will give the real branch, if it can, satisfying both worlds. Note that Derive computes with the principal branch by default, and yet allows use of the real branch where it makes sense by an option. The uncompromising use of the principal branch, which I staunchly and wholeheartedly support, is not without its drawbacks, however, as we see below. In article <1990Sep26.190747.26768@ecn.purdue.edu> ryoder@ecn.purdue.edu (Robert W Yoder) writes >This feature caused me enormous headaches when trying to debug a root solver >sometime back. It never occured to me that a calculator might return a >complex cube root. The formulas that you see in for example Schaum's Math Handbook or Abramowitz and Stegun for finding all the roots of a cubic equation by using Cardano's formula are all based on using the real branch. Programming these in a straightforward way on the 28 can result in downright incorrect answers (I had two example cubics, one which would kill the formula in the Handbook, but works for the formula in Abramowitz and Stegun and the other which worked vice-versa). If you use Vieta's trigonometric formula, however, you get a program that is just as short and of comparable speed, and works. Some other interesting consequences of the HP's use of complex numbers: 1) Inverse functions: sin(asin(x)) = x for x suitably restricted. Naturally, since sin(y) is between -1 and 1 for real y, asin(x) is complex for x larger than 1. If you plot sin(asin(x)) on the 28 you get (as the mathematician working in the reals only expects) a segment of the curve y=x plotted, from -1 <= x <= 1. BUT this works only because of a fluke or quirk (perhaps intentionally left in?) asin(2) is complex; sin(asin(2)) = 1.99...9 + i*e where e=-8E-12. So really sin(asin(x)) ought to plot a little further along the curve y=x. But the plotter won't plot if the result is complex... so even though the imaginary part is due only to roundoff, it is enough to prevent plotting! A similar thing happens for exp(ln(x)) and other inverse function pairs. (an interesting puzzle: explain why asin(sin(x)) looks the way it is plotted on the HP). 2) The 'xth-root-of-y' won't work for certain x and y - if y is negative and x is not an odd integer it won't work and gives an error message, even though you can evaluate y^(1/x) using the ^ or y-to-the-x button. This is as it should be, because to define this consistently for non-odd-integer or nonreal x you need to choose a branch consistently, and the only respectable choice is the principal branch. As good (good? great!) as it is the use of complex on the 28/48 is not complete. The FACT function (! on the 48), numerical integration, several statistical functions (COMB, UTPN, etc) can be defined for complex numbers, and yet the 28/48 does not do so. Pity especially about the numerical integration, but we can fix that up by separating into real and imaginary parts ourselves first. I teach first year engineers, and last year we made all of them buy 28s. This year they are allowed 48s if they have the bucks. The most significant advantage gained from a pedagogical point of view was that they had no difficulty whatever with complex numbers - to the point of them being confused that there had been a problem before. I say again, well done HP. -- ======== Robert Corless, Applied Mathematics, University of Western Ontario ======== London, Ontario, Canada N6A 5B9 Bitnet: RCORLESS@UWOVAX.BITNET ca : RCORLESS@uwovax.uwo.ca