Complex exponential connundrum


All calculators (at least for a very long time) accept angular settings for trigonometric functions. Internally, all the calculations happen by converting deg/grads to radians before the calculation begins. If you get right down it though, nothing but radians is a valid input for a trigonometric function.

However, if you try to calculate Euler's forumula - no matter the user specified setting - they force the input to be interpreted as radians no matter what the user has specified.

Thus doing e^(pi/2*i) in radian mode != e^(90*i) in degree mode.

Therefore, doing e^(x*i)-(cos(x)+i*sin(x)) will not equal 0 in nearly all calculators if you are in degrees mode. The e^<complex> is forced to be interpreted as radians, while the cos/sin are in the user specified settings and give an incorrect result.

This seems quite wrong to me. If you allow specifying angular settings for trigonometric functions, you need to respect it throughout when they are used internally and not force a setting for a certain calculation like that.

Thoughts? Any examples where internally converting the e^ value when input is complex to radians *exactly* like sin/cos/tan do when in deg mode would break something?


Edited: 29 Aug 2012, 6:13 p.m.


I too struggled with this one before deciding to follow the crowd and do complex operations in radians -- the 34S even lights the radians annunicator when you press CPX.

One extra thought: hyperbolic functions and angular mode. I'm not aware of any calculator that does an angular mode conversion here. Given their relationship to the standard trigonometric functions, they probably should or stumble into the same kind of issues.

- Pauli


Yes, I agree that forcing RAD is a safekeeping measure that warns the user to avoid making mistakes derived from not understanding the conceptual nature of complex variable.

On the 41Z I chose not to do it though, I was somewhat irritated by having to switch it back and forth when using POLAR coordinates.



The 15C does exactly that: While in complex mode (SF 8, indicator 'C' is lit) all angles are measured in radians.


While it is true that the angular mode is ignored for trigonometric functions and their inverses it's still taken into account when using the functions to transform from rectangular to polar coordinates and vice versa.

To compute e.g. 5ei 30deg * 2ei 15deg = 10ei 45deg, you'd have to transform first your entries to rectangular coordinates and then the result back to polar coordinates after the multiplication:

5 ENTER 30 I               5.0000   | 30.0000
->R 4.3301 | 2.5000
2 ENTER 15 I 2.0000 | 15.0000
->R 1.9319 | 0.5176
* 7.0711 | 7.0711
->P 10.0000 | 45.0000

Compare this to the HP-42S in POLAR and DEG mode, where this transformation can be omitted:

5 ENTER 30 COMPLEX         5.0000 <)30.0000
2 ENTER 15 COMPLEX 2.0000 <)15.0000
* 10.0000 <)45.0000

Just out of curiosity: how does the WP-34s handle this? I think it would confuse me when the calculator displays the RAD annunciator just because I want to multiply two complex numbers.


The polar/rectangular conversions obey the current angle mode setting.

The RAD indicator after pressing CPX is almost unnoticeable. It certainly isn't annoying or confusing.

- Pauli


Well since you're asking about the 34S I guess I can also add the 41Z keystrokes:

DEG is assumed - and won't get changed at all

POLAR, to set Polar Mode

5, ^IM/AG, 30, R/S

2, ^IM/AG, 15, R/S


the result is (integer BTW) 10 <)45.


Edited: 31 Aug 2012, 10:00 a.m.


If I understand you correctly you'd like to have a mode that changes the actual exponential function so that the imaginary value get's scaled.
For the HP-42S an implementation of this function would be the following program:

00 { 13 Byte Prgm }
01 LBL "EXP"
03 ->RAD
05 E^X
06 END

We get into problems with the following identity as soon as we use complex values for z and w:

exp(z)w = exp(z * w)

You can easily check with the following example:

  • z = 90i
  • w = i


Result: 0.2709 i0.0000


Result: 8.1940E-40 i0.0000

IMHO this function exp just doesn't make much sense.



Edited: 29 Aug 2012, 7:33 p.m.


You have to operate in radians when dealing with Exp[i y]=Cos[y]+i Sin[y]. Take, for instance, the classical "proof" of Euler's identity that relies on the combination of the Taylor expansions of Cos and Sin. In order that those expansions converge to their true values you have to operate in radians i.e. power expand in a radian-variable, degrees won't do.

In fact, they usually define Exp[z]=Exp[x]*(Cos[y]+i Sin[y]), in radians, and skip any "proof". (See Marsden-Hoffman, Churchill, or Ahlfors... You have to be extra-careful with these things.)

(edited spelling)

Edited: 29 Aug 2012, 11:33 p.m. after one or more responses were posted


I apologize if I seem too persistent, yet let me elaborate a bit more.

What you want is an exp function that, when in Deg mode and only for x Real, inputs Exp[i x], but prints Exp[i x*Pi/180] (i.e. Exp[i x_deg] -> Exp [i x_deg*Pi_rad/180_deg]). That would make some sense, although it would be quite awkward.

Notice that in such case, the argument is purely imaginary, you have a complex phase, and your variable can be viewed as an angle.

In general, when you are working in rectangular coordinates, the arguments of complex functions won't be angles, but complex numbers. If you can express your function as a combination of circular functions, what they expect are the real and/or imaginary parts of such numbers. These ones aren't angles, but numbers, hence radians.

(If the idea is while working in polar coordinates to keep the angle mode while performing complex exponentiation -and hide the conversions in the background-... well, the TI-86 does that smoothly.)

(edited spelling... again! it's a flu thing, sorry)

Edited: 29 Aug 2012, 11:59 p.m.


In general, when you are working in rectangular coordinates, the arguments of complex functions won't be angles, but complex numbers. If you can express your function as a combination of circular functions, what they expect are the real and/or imaginary parts of such numbers. These ones aren't angles, but numbers, hence radians

Perfectly stated. The dilemma isn´t such, because there isn´t such a think as "angles" when the arguments are in rectangular form. Users must know what thay´re doing, IMHO a calculator shouldn´t (and likely cannot) make "intelligent" decisions for them if they input wrong entries as a consequence of their incomplete understanding of the theory.

And keeping the angular mode for Polar coordinates is also implemented in the 41Z. The important thinkg to bear in mind is that the POLAR-RECT mode is independent from the ANGULAR mode, and that the latter must be respected by the former.



Its very clear that e^(i*theta)=cos(theta)+i*sin(theta). That's fine and it is the explanation why the result is different according with the angular mode. But if one considers now the e function as a serie, which is the underlying justification for the above equality, then the result is not to change with the angular mode as long as Pi is defined as 3.14159..... The philosophical point is to decide if Pi is a constant with it's usual value or if Pi is the angular measure of half a circle and in that case Pi shall be 180° when degrees are selected.

My suggestion would be (obviously...) to keep Pi being independent of the angular mode and to force a radians mode (with a flag being clearly displayed) when using trigonometry for computing complex exponential while restoring the angular mode afterwhile. I checked on a HP 35s (which is not the best reference....) and the behavior is the same: independent of the angular mode.

Regards to all


My inclination is to say e^x is always e^x, but sin x depends on angle mode. So e^x - e^Re x(cos Im x +i sin Im x) does not have to equal zero, unless you're in radian mode.

Ah, but what about people who write waves as e^i(wt - kx)? They might want the argument to change to be the same as the angle unit.

It occurs to me that this is not necessary. e is a special number, such that de^x / dx = e^x, and e^(pi i) = -1. However, it is not the only exponential function. You could have 2^x for example.

So why not define an exponential constant d = e^(pi/180) to use when you want to use a "degree" exponential function? This seems to me to be the best solution.


Thus doing e^(pi/2*i) in radian mode != e^(90*i) in degree mode.

Right. And clearly e^(pi/2*i) in radian mode should be (e*pi/180)^(90*i) in degrees mode....

This is absurd, but why? Because the angle mode works only when you are directly specifying an angle. The argument of exp() isn't an angle, so it's not affected by the angle mode. If the argument of exp() happens to be k*i then you get a mathematical identity that behaves like it's an angle, but that's purely a coincidence. I'm sure there are other formulas that behave the same way.

Keep it simple. The angle mode affects the argument of the trig functions and the result of their inverses.


The exp functions was not programmed with the angle measurement of the argument in mind, interesting. (At least in the past?)

For the record, the 39gii returns:

e^(pi / 2 * i) returns -5.633380706868E-12 + i in radians mode

e^(90*i) returns -5.340707511E-13 + i in degrees mode.


Really? First result could be better (IMHO the algorithm should be clever), second result is plain wrong...

Implementing correctly complex functions is non trivial, the numerics are tricky and you need some working experience in the field.

(some food for thought)

(edited: P.S. I realized HP consulted with Prof. W. Kahan. Section 3 of HP-15C Advanced Functions Handbook is particularly relevant.)

Edited: 30 Aug 2012, 8:32 p.m.


In what way could the first result be better?

I've not checked the numeric accuracy here, but the given answer seems reasonable. Unless this calculation is being carried out symbolically, pi/2 is being rounded to a finite number of digits, it would thus be expected that the real part of the result would be small but non-zero. I'd be concerned if the answer were silently adjusted to have a real part of zero.

- Pauli


In my opinion (IMO) at least k*Pi/2 : k Integer, calculations should be handled symbolically in an education-oriented device. IMO it's easy to implement, and IMO the benefits exceed the slight inconsistency... ;)

(edited: BTW, I know that usually complex accuracy is less than real accuracy because of memory management, and that one should consider modulus accuracy instead etc, but I find quite hard to believe that Cos[Pi/2] renders other thing than zero on that calculator.)

Edited: 30 Aug 2012, 9:22 p.m.


Evaluate pi/2 as a real number. To 12 significant digits this is: 1.5707963267900000000000000000000000000000000000000000000. This is not exactly pi/2 any more. The calculator is doing the correct thing giving a non-zero answer based on the input provided.

I'd much prefer a calculator that does exactly what it is told to the best of its abilities than one that does hidden secret stuff behind the scenes. The former I can trust, the latter I can't. Plenty of calculators do magic things with their invisible guard digits and rounding -- this is bad plain and simple. If you want a calculator you can't trust, get one of these and at least you'll know you can't trust it.

- Pauli

PS: complex accuracy has nothing to do with memory management :-)


I understand your suspicion, but I have no problems with a calculator that performs some symbolic operations before computing. Maybe I'm too used to Mathematica, where you have no clue about what's going on behind the scenes (by design)... But it is a useful tool, and it's been reasonably tested, so why not?

If I needed absolute reliability, I wouldn't use canned software or calculators. After quite a bit of handwriting I'd probably FORTRAN it myself :).

(I was being too sloppy... If you don't have native complex types, as you usually need twice the real precision, you need extended reals. If you don't have them, well... it's a Memory thing, isn't it? :))


e^(90*i) returns -5.340707511E-13 + i in degrees mode.

What's the result of the following calculations?

  • e^(1E-6 + 90*i)
  • e^(1 + 90*i)

Thanks in advance!



What's the result of the following calculations?
  • e^(1E-6 + 90*i)
  • e^(1 + 90*i)

1.: -0,448074064203 + 0,893997557598*i

2.: -1,21799036854 + 2,43013488537*i.



Hi Tim

Any examples where internally converting the e^ value when input is complex to radians *exactly* like sin/cos/tan do when in deg mode would break something?

The function ex is continuous. This is broken with this implementation.

e^(90*i) returns -5.340707511E-13 + i in degrees mode.

e^(1E-6 + 90*i) = -0,448074064203 + 0,893997557598*i

These two values should be close to each other.

Kind regards and thanks to Walter for providing the result of the calculations.


Edited: 31 Aug 2012, 9:05 a.m.


Thomas, watch it! I took your problems as they were written by you - but now it looks you may have meant them like this:

0. e^(      i*pi/2) =  6,19231321692e-16 + 1*i  
1. e^(1e-6 +i*pi/2) = 6,19231940923e-16 + 1,000001*i
2. e^(1 +i*pi/2) = 1,68324524937e-15 + 2,71828182846*i
These results are obviously quite different!

Edited: 31 Aug 2012, 10:28 a.m.


Hi Walter

I guess the results of 0. and 1. are rather close. Maybe I didn't make my point clear enough:

Let's compare the two functions sin(x) and ei*x just for real x. Both are continuous, so small changes of input will result in small changes of output.

Now look at what happens when we want to provide an angular mode e.g. DEG: instead of using the original input it is transformed and this transformation is linear. So the combination is still continuous.

But there's an important difference between the two functions: i*x is a complex number. So when calculating ei*x the complex implementation of the exponential function is used. Now you have to ask yourself what should be done with the real part of a complex number if it's not 0 as right now?

Certainly we don't want to transform it the same way as we did with the "angle" x in i*x. Because that would lead to a completely nonsensical result for a pure real value: the result would depend on the angular mode! Therefore only the imaginary part is stretched or compressed.

My understanding of the current implementation is that in case of pure imaginary values the angular mode is taken into account while for an ordinary value (i.e. with real value distinct from zero) it is not. That's what I tried to verify with the examples 0. and 1.. But this distinction in the behavior of the function makes it discontinuous:

Since both input values are very close we'd expect both results are close as well. But they are not.


  • If you make the exponential function dependent on the angular mode as in the HP-42S program "EXP" above, you break a fundamental law of this function: exp(z)w = exp(z * w)
  • If you make it dependent on the angular mode only on the imaginary axis (current implementation in 39gii), it's not continuous anymore.

In both cases something is broken.

Could I make my views clear, or did I only contributed to further confusion?

Kind regards



Yes, the fixation in keeping somehow the angle thing because the exponentiation of an imaginary number is a rotation leads to an inconsistent behaviour in the implementation of complex functions, as some of us have already pointed out several times.

Just another example, when you want to compute, say Cos[1+i], how can you think of (1+i) as an angle? Is there such a thing as "complex degree numbers"? Of course not.


If we are talking 39gII, the result are as follows (provided didn't type a digit wrong):

e^(90i) -> -5.340707511E-13+i

e^(1E-6+90i) -> -5.10338587206E-12+1.000001*i

Both in degrees and radians the function is continuous. They are essentially identical while plotting except for the horizontal scale being either -180 to 180 or -pi to pi.


Edited: 31 Aug 2012, 11:30 a.m. after one or more responses were posted



e^(1E-6+90i) -> -5.10338587206E-12+1.0000001*i

Are you sure about the number of zeros in the imaginary part?


Yeah, should only be 5. Corrected.


Edited: 31 Aug 2012, 11:30 a.m.


Hi Tim

Both in degrees and radians the function is continuous.

At least that's not a problem! I'm sorry, but I was misled by the result that Walter provided.

But the other problem still remains. I assume that you agree that these two values should be the same in whatever angular mode:

(e^(90i))^i = e^(90i*i)

But I guess they are not when using the 39gII in DEG mode.

Best regards


PS: Using the emulator I get 1+0*i for (e^(90i))^i. Is that a known issue or am I doing something wrong?


Probably a very old version...

In degrees:

(e^(90*i))^i -> 8.19401262374E-40+2.03958396423E-66*i

e^(90*i*i) -> 8.19401262374E-40

And for reference, this behavior on the new calc regarding DEG/RAD was a surprise to me as well when I found it ~2-3 weeks back. :-)


Edited: 31 Aug 2012, 2:14 p.m.


Hi Walter

It appears that Tim disagrees with that result. By any chance was the calculator in RAD mode while calculating e^(1E-6 + 90*i) = -0,448074064203 + 0,893997557598*i?

Because that would be the expected result then. However I was assuming it was in DEG mode as that was what Eddie W. Shore stated:

(...) in degrees mode





With my limited abilities in clairvoyance I cannot know what you were "assuming". Please see above.

Possibly Related Threads...
Thread Author Replies Views Last Post
  HP Prime: complex numbers in CAS. Alberto Candel 1 840 12-06-2013, 02:36 PM
Last Post: parisse
  [HP Prime] Plots containing complex numbers bug? Chris Pem10 7 1,688 12-05-2013, 07:40 AM
Last Post: cyrille de Brébisson
  Complex Number Entry on Prime Jeff O. 19 2,744 11-16-2013, 12:34 PM
Last Post: Jeff O.
  HP Prime complex results Javier Goizueta 0 528 10-06-2013, 12:59 PM
Last Post: Javier Goizueta
  HP Prime Solving Nonlinear System of Equations for Complex Results Helge Gabert 11 2,129 09-30-2013, 03:44 AM
Last Post: From Hong Kong
  [HP-Prime xcas] operations with complex numbers + BUGs + Request CompSystems 9 1,654 09-08-2013, 10:40 PM
Last Post: CompSystems
  Elliptic integrals of 1st and 2nd kind calculated by complex agm Gjermund Skailand 3 760 06-29-2013, 03:39 PM
Last Post: Gjermund Skailand
  HP-11C and complex numbers Antlab 5 1,164 06-28-2013, 08:59 AM
Last Post: Antlab
  71B Complex User Defined Functions in Calc Mode? Michael Burr 0 460 03-18-2013, 09:38 PM
Last Post: Michael Burr
  HP 34S complex # problem Richard Berler 2 583 02-17-2013, 11:01 PM
Last Post: Richard Berler

Forum Jump: