▼
Posts: 30
Threads: 5
Joined: Jul 2010
While waiting for the rebirth of this somuchspokenof gadget, I’m reading the Owner’s Handbook (in Swedish 1983) and playing with the details. My question was, is it worth so much fuzz? In my opinion I must say it is almost perfect. A little bit slow perhaps. But yes, it is still competitive after 30 years!
But I found something odd when working in complex mode. Why does it force you to use radians in trig and log? If it *must* use radians, why not automatically switch the trigannunciator to RAD? Or even better, allow all trigonometric modes when working in complex mode (as when calculating P <> R conversions in complex mode).
If you enter complex mode by accident (key f I) and you are using degrees, you will get wrong results. Every noncomplex calculation should give the same result in Cmode as in normal mode.
One final detail: It would be nice if the fCLEARREG key also made a CF8 (exit complex mode) (fCLEAR“REG/C”).
Still, I love my 15C. Still, waiting…
/Tommy
▼
Posts: 1,665
Threads: 142
Joined: Jan 2009
Only trig, not log, require input in radians. This is because radians are the true primary unit for trig functions, and the conversion to degrees or grads is just a convenience that has been implemented as the default in most calculators. I used to program computers in Fortran, and the trig units were radians. Some primitive calculators such as the Sinclair Scientific require radians as the trig units with no provision to change the mode to degrees.
▼
Posts: 2,247
Threads: 200
Joined: Jun 2005
Recently I began to find software packages that define trig function sind(), cosd(), and tand() to take angles in degrees. The same packages also offer sin(), cos(), and tan() to take angles in radians. I think it's nice touch to have the degreeflavor of trig functions.
Of course you can always define the sind(), cosd(), and tand(), asind(), acosd(), and atand() in your favorite programming tools if they only support radian versions of the trig and inverse trig functions.
Namir
Edited: 6 Aug 2011, 11:12 a.m.
Posts: 735
Threads: 34
Joined: May 2007
Quote:
Only trig, not log, require input in radians.
The output of log is in radians.
Kind regards
Thomas
Posts: 735
Threads: 34
Joined: May 2007
Quote:
Why does it force you to use radians in trig and log?
What's the expected result of say:
ln(1)?
Do you really want to make that dependant on the trigonometric mode?
This would result in a different value for
(1)^{i} when using the following formula:
z^{w} = e^{ln(z) w}
In RADmode:
ln(1) = i Pi, thus (1)^{i} = e^{i Pi i}
= e^{ Pi}
In DEGmode:
ln(1) = i 180, thus (1)^{i} = e^{i 180 i}
= e^{180}
In complexmode the trigonometric functions are coupled to the exponential function by means of Euler's formula:
e^{i x} = cos x + i sin x
Therefore you can not redefine the trigonometric functions depending on a mode without violating fundamental laws of mathematics.
Quote:
If it *must* use radians, why not automatically switch the trigannunciator to RAD?
Because then you couldn't enter a complex number in polar mode with the angle in degrees. And that's something convenient.
IMHO it's perfect as it is implemented. It's the same in the HP42s or HP48.
Kind regards
Thomas
Edited: 6 Aug 2011, 1:48 p.m.
▼
Posts: 30
Threads: 5
Joined: Jul 2010
Quote:
Do you really want to make that dependant on the trigonometric mode?
No, that is the same as with SQRT(1). All perfect in normal mode
But in Cmode I would say Yes.
In normal mode the polar conversion functions uses the x and yregisters. But in Cmode the polar conversion functions uses the Re x and Im x registers. That means that the user must know what he is doing.
And in Cmode the HP15C quietly changes mode to RAD. I do not like when a program quietly changes anything.
My first thought was that it was impossible to handle degrees in Cmode. That it violated something fundamental.
But when I realized that it accepted values in degrees in the Im x register when using the P<>R functions but not when using e, I was starting to think. (Page 134 in Owners handbook)
Suppose You want to solve the following problem: What is the angle, in degrees, corresponding to the value of i?
Solution A using >P, Cmode and degree–mode:
0 ENTER 1 fI f(i) g>P Result: 1 and f(i) shows 90 degrees (as expected)
Solution B using Eulers formula, Cmode and degreemode:
0 ENTER 1 fI f(i) g>LN Result: 0 and f(i) shows 1,57 degrees (NOT expected) (Angle in RAD)
In my opinion, this is inconsistent.
Further more, if the user by accident enters the Cmode and makes a simple 45 ENTER TAN (in degreemode) he will be really confused. In my opinion, that is an erroneous behavior.
If this user doesn’t find page 121 in Owners manual “Deactivating Complex Mode” , he is in big problems.
Best regards
/Tommy
▼
Posts: 735
Threads: 34
Joined: May 2007
I asked:
Quote:
Do you really want to make that dependant on the trigonometric mode?
Your answer was:
Quote:
No
But then you state:
Quote:
Cmode and degreemode: 0 ENTER 1 fI f(i) g>LN Result: 0 and f(i) shows 1,57 degrees (NOT expected) (Angle in RAD)
Which I interpret as: yes, I want ln to behave differently depending on the anglemode. But then you will get wrong results as the example in my previous post shows.
Quote:
In my opinion, this is inconsistent.
I'd rather say your answer to that question is.
It seems I failed to explain to you, why you can't make a calculator behave the way you expect it and at the same time make it consistent with mathematics. On the other hand I understand your frustration beeing caught in Cmode and not finding out how to deactivate it. It's just your proposed solution doesn't work.
Cheers
Thomas
Posts: 1,253
Threads: 117
Joined: Nov 2005
I'm probably getting too highlevel here but to me this dilemma is not representative of what a complex number represents when used as argument of a function  in RECTangular form.
For instance, what's the meaning of "angular mode" when calculating SIN(1+i)? Certainly not angles, or radians, or GRADs either, just a complex value with real and imaginary parts.
So to me the angular mode is a value conversion for real magnitudes, not applicable to the complex plane.
Things get blurry of course when you enter realonly arguments in complex mode (or using complex functions, like in the 41Z). In this case the assumption is that they are just real parts, thus must be RAD. Also P<>R tend to make things a little confusing, as that surely depends on the selected angular mode.
The angular mode only comes to the picture when you want to display the number(s) in POLAR form, and then the calculator must adhere to the selected mode of course.
So for instance the 41Z has a POLAR mode. If you enter a complex argument in this form it'll look at the angular mode to interpret the proper "units" of the angle, and then proceed accordingly. This is done by the function "^IM/AG" in the input stage, and function ZAVIEW in the output step.
All other inputs are assumed to be in rectangular form, and thus independent from the angular mode settings.
Cheers,
ÁM
▼
Posts: 735
Threads: 34
Joined: May 2007
Quote:
For instance, what's the meaning of "angular mode" when calculating SIN(1+i)? Certainly not angles, or radians, or GRADs either, just a complex value with real and imaginary parts.
As far as I understood Thommy, he's not so much concerned about something like SIN(1+i). His scenario goes more like: my calculator is accidentially in complexmode and I want to calculate something like sin(60), but that darn little beast doesn't behave as I expected and instead ignores DEGmode.
So what's this DEGmode and why can't we have it in complexmode? In DEGmode the entry to the three triangular functions sin, cos and tan are scaled to radians before entering the actual function. On the other hand the result of the inverse trigonometric functions is scaled back from radians to degrees after leaving it.
Does this DEGmode has any influence on the exponential function in realmode? Of corse, no! But in complexmode exp, cos and sin are coupled through Euler's equation.
In fact all the other transcedental functions can be expressed using only exp(z) and its inverse ln(z). So we only have to consider these two. If anything goes wrong with them the others will be affected as well.
So what's happening when we calculate z^{w} by using exp(z) and ln(z)? First we'd calculate ln(z). The imaginary part of this expression is an angle so in fact this could be transformed to degrees as Thommy suggested. But you would never do that with the real part. However, scaling only the imaginary yaxis introduces an asymmetry. Nothing goes wrong as long as w is a real number. But when you allow the exponent to be a complex number the two axes are rotated. In the case of w = i both axes are exchanged. Before we apply the exponential function we must transform the angle back to radians. So we will scale the imaginary axis back again. But alas, what we thought was the imaginary axis is in fact the real axis but rotated due to the multiplication by i.
Instead of scaling up and down the same axis we end up magnifying the imaginary axis and shrinking the real axis which of course is not the same as what we get when we'd refrain from scaling alltogether. Thus we can't have angular modes with the complex version of the exponential and logarithmic functions. Since they depend on these the same is true for the trigomometric functions as well.
Best regards
Thomas
Edited: 8 Aug 2011, 5:18 p.m.
▼
Posts: 30
Threads: 5
Joined: Jul 2010
Quote:
Thus we can't have angular modes with the complex version of the exponential and logarithmic functions. Since they depend on these the same is true for the trigomometric functions as well.
I fully agree. So, back to my original post:
Quote:
If it *must* use radians, why not automatically switch the trigannunciator to RAD?
Of course you must sacrifice the ability to use degrees when P <> R in Cmode. The price is either exiting Cmode or convert the answer using g >DEG. What would you gain? You would gain a calculator even closer to perfect, which was my main concern.
Best regards
/Tommy
▼
Posts: 1,253
Threads: 117
Joined: Nov 2005
I concur with you: if it takes RAD as defacto mode it should indicate it so setting RAD on.
Alternatively a clearer complex mode, or a complex prefix (like in the 41Z) will eliminate any doubts, yet I can imagine how tight things must be in the 15C firmware, so space probably was at a premium to sacifice it in those usability enhncements.
Cheers,
ÁM
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
The 34S indicates RAD when the complex prefix is pressed BTW :)
 Pauli
