▼
Posts: 1,278
Threads: 44
Joined: Jul 2007
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?
TW
Edited: 29 Aug 2012, 6:13 p.m.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 1,253
Threads: 117
Joined: Nov 2005
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.
Cheers,
ÁM
Posts: 3,283
Threads: 104
Joined: Jul 2005
The 15C does exactly that: While in complex mode (SF 8, indicator 'C' is lit) all angles are measured in radians.
▼
Posts: 735
Threads: 34
Joined: May 2007
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. 5e^{i 30deg} * 2e^{i 15deg} = 10e^{i 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 HP42S 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 WP34s handle this? I think it would confuse me when the calculator displays the RAD annunciator just because I want to multiply two complex numbers.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
Posts: 1,253
Threads: 117
Joined: Nov 2005
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
Z*
the result is (integer BTW) 10 <)45.
Cheers,
ÁM
Edited: 31 Aug 2012, 10:00 a.m.
Posts: 735
Threads: 34
Joined: May 2007
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 HP42S an implementation of this function would be the following program:
00 { 13 Byte Prgm }
01 LBL "EXP"
02 COMPLEX
03 >RAD
04 COMPLEX
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:
0 ENTER 90 COMPLEX
XEQ EXP
0 ENTER 1 COMPLEX
Y^X
Result: 0.2709 i0.0000
0 ENTER 90 COMPLEX
0 ENTER 1 COMPLEX
*
XEQ EXP
Result: 8.1940E40 i0.0000
IMHO this function exp just doesn't make much sense.
Cheers
Thomas
Edited: 29 Aug 2012, 7:33 p.m.
Posts: 79
Threads: 3
Joined: Jun 2010
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 radianvariable, 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 MarsdenHoffman, Churchill, or Ahlfors... You have to be extracareful with these things.)
(edited spelling)
Edited: 29 Aug 2012, 11:33 p.m. after one or more responses were posted
▼
Posts: 79
Threads: 3
Joined: Jun 2010
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 TI86 does that smoothly.)
(edited spelling... again! it's a flu thing, sorry)
Edited: 29 Aug 2012, 11:59 p.m.
▼
Posts: 1,253
Threads: 117
Joined: Nov 2005
Quote:
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 POLARRECT mode is independent from the ANGULAR mode, and that the latter must be respected by the former.
Cheers,
ÁM
Posts: 59
Threads: 5
Joined: Jul 2011
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
▼
Posts: 306
Threads: 3
Joined: Sep 2009
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.
Posts: 528
Threads: 40
Joined: Dec 2008
Quote:
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.
▼
Posts: 764
Threads: 118
Joined: Aug 2007
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.633380706868E12 + i in radians mode
e^(90*i) returns 5.340707511E13 + i in degrees mode.
▼
Posts: 79
Threads: 3
Joined: Jun 2010
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 HP15C Advanced Functions Handbook is particularly relevant.)
Edited: 30 Aug 2012, 8:32 p.m.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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 nonzero. I'd be concerned if the answer were silently adjusted to have a real part of zero.
 Pauli
▼
Posts: 79
Threads: 3
Joined: Jun 2010
In my opinion (IMO) at least k*Pi/2 : k Integer, calculations should be handled symbolically in an educationoriented 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.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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 nonzero 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 :)
▼
Posts: 79
Threads: 3
Joined: Jun 2010
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? :))
Posts: 735
Threads: 34
Joined: May 2007
Quote:
e^(90*i) returns 5.340707511E13 + i in degrees mode.
What's the result of the following calculations?
 e^(1E6 + 90*i)
 e^(1 + 90*i)
Thanks in advance!
Thomas
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Quote:
What's the result of the following calculations?
 e^(1E6 + 90*i)
 e^(1 + 90*i)
1.: 0,448074064203 + 0,893997557598*i
2.: 1,21799036854 + 2,43013488537*i.
FWIW
▼
Posts: 735
Threads: 34
Joined: May 2007
Hi Tim
Quote:
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 e^{x} is continuous. This is broken with this implementation.
Quote:
e^(90*i) returns 5.340707511E13 + i in degrees mode.
Quote:
e^(1E6 + 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.
Thomas
Edited: 31 Aug 2012, 9:05 a.m.
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
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,19231321692e16 + 1*i
1. e^(1e6 +i*pi/2) = 6,19231940923e16 + 1,000001*i
2. e^(1 +i*pi/2) = 1,68324524937e15 + 2,71828182846*i
These results are obviously quite different!
Edited: 31 Aug 2012, 10:28 a.m.
▼
Posts: 735
Threads: 34
Joined: May 2007
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 e^{i*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 e^{i*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.
Conclusion:
 If you make the exponential function dependent on the angular mode as in the HP42S 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
Thomas
▼
Posts: 79
Threads: 3
Joined: Jun 2010
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.
Posts: 1,278
Threads: 44
Joined: Jul 2007
If we are talking 39gII, the result are as follows (provided didn't type a digit wrong):
e^(90i) > 5.340707511E13+i
e^(1E6+90i) > 5.10338587206E12+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.
TW
Edited: 31 Aug 2012, 11:30 a.m. after one or more responses were posted
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Tim,
Quote:
e^(1E6+90i) > 5.10338587206E12+1.0000001*i
Are you sure about the number of zeros in the imaginary part?
▼
Posts: 1,278
Threads: 44
Joined: Jul 2007
Yeah, should only be 5. Corrected.
TW
Edited: 31 Aug 2012, 11:30 a.m.
Posts: 735
Threads: 34
Joined: May 2007
Hi Tim
Quote:
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
Thomas
PS: Using the emulator I get 1+0*i for (e^(90i))^i. Is that a known issue or am I doing something wrong?
▼
Posts: 1,278
Threads: 44
Joined: Jul 2007
Probably a very old version...
In degrees:
(e^(90*i))^i > 8.19401262374E40+2.03958396423E66*i
e^(90*i*i) > 8.19401262374E40
And for reference, this behavior on the new calc regarding DEG/RAD was a surprise to me as well when I found it ~23 weeks back. :)
TW
Edited: 31 Aug 2012, 2:14 p.m.
Posts: 735
Threads: 34
Joined: May 2007
Hi Walter
It appears that Tim disagrees with that result. By any chance was the calculator in RAD mode while calculating e^(1E6 + 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:
Quote:
(...) in degrees mode
Cheers
Thomas
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Thomas,
With my limited abilities in clairvoyance I cannot know what you were "assuming". Please see above.
