more question regarding complex operations using complex number on wp34s

[wildpig]

Question 1

(2+2i)^4 on the wp34s gives (-64-3.7x10-37i), not (-64+0i)..

Interesting..... wassup with that?

Question 2

If i enter "2 (enter) 2 (enter) 4 (cpx) y^x " what is the operation i am doing (as can someone write it out what this is as it would looks like "on paper" ? thanks

Edited: 2 Sept 2012, 5:29 a.m.

[Paul Dale]

2 ENTER 2 ENTER 0 ENTER 4 CPX y^x is what you want here.

- Pauli

[Walter B]

When/if you perform a complex two-number function, both numbers must be complex. Thus it's called a complex two-number function. RTFM p. 28.

Alternative: 2 ENTER 2 CPX x^2 CPX x^2 executes two complex one-number functions, where (surprise!) only one number has to be complex.

Edited: 2 Sept 2012, 6:02 a.m.

[wildpig]

Ya, after playing around with wp34s even before you answer, that was what i was expecting... But

2+2i)^(4+0i) on the wp34s still gives (-64-3.7x10-37i), not (-64+0i)..

Some strange algorthm bug?

[Walter B]

No, some plain thinking bug ;-)

2 ENTER 2 ENTER 0 ENTER 4 CPX y^x returns -64 + O(10^-37) *i

Edit:The term O(10^-37) is due to the way such operations are actually computed. If you know you just need an integer exponentiation, you're better off with the alternative I mentioned above.

Edited: 2 Sept 2012, 6:29 a.m. after one or more responses were posted

[wildpig]

Quote:

---

No, some plain thinking bug ;-)

2 ENTER 2 ENTER 0 ENTER 4 CPX y^x returns -64 + O(10^-37) *i

---

hmm that is wierd. Just want to ask because i would like to know more about what kind of algorthm it uses. I mean i guess 10^-37 is practically 0 but i still wonder how it comes up with that?

[Gilles Carpentier]

I dont know but :

HP39gII -> -64+2.....E-13*i

HP50G -> (-64.,0.) (Approx mode and -64 in exact mode)

Edited: 2 Sept 2012, 7:03 a.m.

[Damir]

Try HP39gII emulator in DEG mode.

Damir

Edited: 2 Sept 2012, 8:32 a.m. after one or more responses were posted

[Gilles Carpentier]

In DEG,

- with 39gII i get -64

- 50G DEG (-64.,0.)

[Walter B]

Oiiik wildpig,

It's not as weird as you think - please see my remarks above. BTW:

Quote:

---

But

2+2i)^(4+0i) on the wp34s still gives (-64-3.7x10-37i), not (-64+0i).

---

... even today the algorithm of the WP 34S will take (2+2i)^(4+0i) and return -64 - 4 * 10^(-37) * i. Some exactitude in spelling words and equations helps a lot, not only in math. In old Europe, people used to say "Before learning a foreign language, learn your own." I'm not so sure, however, about the applicability of this saying to the USA and their forests especially ;-)

[Dieter]

Question 1:

The 34s internally uses 39-digit precision. Due to the usual roundoff errors all results may differ from the true value somewhere in their 30th...39th digit. In most cases this remains unvisible since the result is rounded to 16 resp. 34 digits. However, close to zero the remaining error may be exposed.

In a way this is similar to calculating sin(pi). Since pi cannot be exact, the result is off by O(10^-16) resp. O(10^-34). So if the true result is zero, this is what you see. All this happens to any calculator with finite precision. At least if it does not apply "cosmetic rounding".

In your case actually something very similar happens. The complex power z1^z2 is evaluated as e^(z2 * ln(z1)). In this case this leads to

  e^(4 * ((ln 8)/2  +  pi/4 i)

where the term 4*pi/4 (or even pi itself) cannot be given with infinite precision so that its sine will never become exactly zero.

Question 2:

Complex operations assume that both (!) operands are complex. If this was not the case, how shall the 34s interpret your input (2, 2, 4)? Do you mean (2i+2)^4 or 2^(2i+4)?

The correct entry is

   2 ENTER 2

ENTER

   0 ENTER 4

[CPX] [f][y^x]

i.e. (2i+2)^(0i+4)

For low integer (non-complex) exponents using x^2 or x^3 is the better way. This also avoids roundoff errors like the one you posted:

   2 ENTER 2

[CPX] [g][x^2]      => 8i + 0

[CPX] [g][x^2]      => 0i - 64

This returns exactly -64.

Dieter

Edited: 2 Sept 2012, 7:42 a.m.

[wildpig]

Interesting to know... Because on 42S, you do get -64+0i. And 42s is not a symbolic calc.

[Dieter]

My 35s returns this as well (-64 i0). This may be the result of some intentional internal rounding, or - more probably - HPs algorithm for these calculators uses a different approach for (real) integer exponents.

Dieter

Edited: 2 Sept 2012, 8:11 a.m.

[Dieter]

I tried a few examples of complex powers on the 34s, and indeed there are cases where the error becomes substantial. Which can be expected since as the exponent grows, so does the error if the real resp. imaginary part should be exactly zero.

For instance try (2 + 2i)^80. The 34s returns 1,329 E36 + 0,341i. The imaginary part should be zero. Then try (2 + 2i)^82. This returns -2,375 + 1,063 E37. Here the real part should be zero. All this seems to be caused by the limited precision of pi and thus the trig functions near pi, so that the error seems to grow proportionally with the (real) exponent.

A first idea for a quick and easy workaround might be this: simply round the real resp. imaginary part to zero if their ratio is beyond something like 1 : 10^36.

Here is a quick and dirty routine for the 34s:

001 LBL'CPW'

002 CPX y^x

003 CPX ENTER

004 /

005 ABS

006 CF 01

007 x>1?

008 SF 01

009 FS? 01

010 1/x

011 SDL 036

012 IP

013 x!=0?

014 SKIP 004

015 FC? 01

016 STO Z

017 FS?C 01

018 STO Y

019 DROP

020 RTN

2 [ENTER] 2 [ENTER] 0 [ENTER] 4  XEQ"CPW"  =>  -64 + 0i

 

2 [ENTER] 2 [ENTER] 0 [ENTER] 80 XEQ"CPW"  =>  1,329 E36 + 0i

 

2 [ENTER] 2 [ENTER] 0 [ENTER] 82 XEQ"CPW"  =>  0 + 1,603 E37

 

2 [ENTER] 2 [ENTER] 0 [ENTER] 98 XEQ"CPW"  =>  0 + 1,784 E44

 

Maybe someone else (Pauli?) has a better idea? At least for larger exponents the error does not seem to be negligible, so something should be done here.

Dieter

Edited: 2 Sept 2012, 9:01 a.m.

[Walter B]

IMHO a test for integer exponents would be a better solution. If true and the exponent is even, then it can be substituted by a limited number of subsequent complex x^2's. If it is odd instead, one x^3 must join the team. Quick and mathematically correct :-)

[Dieter]

As far as I can see the problem is not caused by integer exponents. It's a general issue for every complex number z raised to the k-th power where

  Im(z) : Re(z)  =  tan(pi/k)

Usually the problem is obscured by the fact that the tangent is an irrational number that cannot be respresented exactly as the quotient of two integers (or at least two n-digit numbers) anyway.

The only exception I see is k = 4, so that Im(z) = Re(z). Here the imaginary part numerically becomes non-zero not because of the slightly inexact representation of z (the tangent is exactly 1 here), but because of the limited precision of Pi.

Dieter

Edited: 2 Sept 2012, 12:33 p.m.

[Mark Scheuern]

The 15C also produces -64 + 0i.

[wildpig]

35s also return 0i

I guess complex number operation testing really put a calc numerical algorthm to work ;)

Edited: 2 Sept 2012, 9:43 a.m.

[wildpig]

on the same thought, e^(i*pi), so far on all the hp calc I got none given me the correct answer with -1 i0 yet. all of them given coefficent of i to E-15 or something like that. Is there a way to get the almighty 50G to give the correct symbolic answer? TI nspire does symbolically give the correct answer to this

Edited: 2 Sept 2012, 10:09 a.m.

[Dieter]

No. If the calculator returned exactly -1 (i.e. with zero imaginary part) the result was plain wrong. Simply because you cannot enter e^(i*pi). The best you can do on a 12-digit machine is e^(i*3,14159265359). And that constant is not pi.

The correct 12-digit result is -1 - 2,06761537357E-13*i. The imaginary part is sin(3,14159265359). As opposed to sin(pi) which is exactly zero.

So the only way to get exactly -1 is a symbolic evaluation that "knows" that pi is not 3,14159265...something but simply ...pi with a sine of 0.

Dieter

Edited: 2 Sept 2012, 10:37 a.m.

[wildpig]

Quote:

---

No. If the calculator returned exactly -1 (i.e. with zero imaginary part) the result was plain wrong. Simply because you cannot enter e^(i*pi). The best you can do on a 12-digit machine is e^(i*3,14159265359). And that constant is not pi.

The correct 12-digit result is -1 - 2,06761537357E-13*i. The imaginary part is sin(3,14159265359). As opposed to sin(pi) which is exactly zero.

So the only way to get exactly -1 is a symbolic evaluation that "knows" that pi is not 3,14159265...something but simply ...pi with a sine of 0.

Dieter

---

I tried to enter (0,pi) but 50g wont let me ;( why is that?

[John Mosand]

What it boils down to, is that no irrational number can be entered exactly. Symbolically, yes - numerically, no.

[Walter B]

Quote:

---

... no irrational number can be entered exactly. Symbolically, yes - numerically, no.

---

Holds even for many rational numbers, e.g. 2/3.