HP-15C Close to perfect



#2

While waiting for the re-birth of this so-much-spoken-of 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 trig-annunciator 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 non-complex calculation should give the same result in C-mode as in normal mode.

One final detail: It would be nice if the f-CLEAR-REG key also made a CF-8 (exit complex mode) (f-CLEAR-“REG/C”).

Still, I love my 15C. Still, waiting…

/Tommy


#3

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.


#4

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 degree-flavor 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.

#5

Quote:
Only trig, not log, require input in radians.

The output of log is in radians.

Kind regards

Thomas

#6

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:

zw = eln(z) w

In RAD-mode:
ln(-1) = i Pi, thus (-1)i = ei Pi i
= e- Pi

In DEG-mode:
ln(-1) = i 180, thus (-1)i = ei 180 i
= e-180

In complex-mode the trigonometric functions are coupled to the exponential function by means of Euler's formula:
ei 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 trig-annunciator 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 HP-42s or HP-48.

Kind regards

Thomas

Edited: 6 Aug 2011, 1:48 p.m.


#7

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 C-mode I would say Yes.

In normal mode the polar conversion functions uses the x- and y-registers. But in C-mode 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 C-mode 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 C-mode. 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, C-mode and degree–mode:
0 ENTER 1 f-I f-(i) g->P Result: 1 and f-(i) shows 90 degrees (as expected)

Solution B using Eulers formula, C-mode and degree-mode:
0 ENTER 1 f-I 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 C-mode and makes a simple 45 ENTER TAN (in degree-mode) 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


#8

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:
C-mode and degree-mode: 0 ENTER 1 f-I 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 angle-mode. 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 C-mode and not finding out how to deactivate it. It's just your proposed solution doesn't work.

Cheers

Thomas

#9

I'm probably getting too high-level 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 real-only 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


#10

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 complex-mode and I want to calculate something like sin(60), but that darn little beast doesn't behave as I expected and instead ignores DEG-mode.

So what's this DEG-mode and why can't we have it in complex-mode? In DEG-mode 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 DEG-mode has any influence on the exponential function in real-mode? Of corse, no! But in complex-mode 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 zw 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 y-axis 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.


#11

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 trig-annunciator to RAD?


Of course you must sacrifice the ability to use degrees when P <-> R in C-mode. The price is either exiting C-mode 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


#12

I concur with you: if it takes RAD as de-facto 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


#13

The 34S indicates RAD when the complex prefix is pressed BTW :-)


- Pauli


Possibly Related Threads…
Thread Author Replies Views Last Post
  [WP34S] Inverse t CDF throws "Domain Error" for probabilities close to 0.5 Les Wright 10 2,846 04-19-2012, 03:25 AM
Last Post: Paul Dale
  eBay Impertinence (well, only close to) Juergen Keller 9 2,602 01-13-2012, 02:07 PM
Last Post: JoeGeller
  Photo of my HP 15c | 15c LE DigiGal 2 1,589 10-12-2011, 12:34 PM
Last Post: DigiGal
  HP 15c LE vs HP-15C dimensions - BOTH ARE HUGE! Joerg Woerner 4 1,998 10-03-2011, 06:53 AM
Last Post: Jim Johnson
  HP 15C and 15C LE not the same dimensions? Derek 16 4,530 09-30-2011, 05:33 PM
Last Post: Derek
  Original 15C Keyboard Test Works With 15C LE!!! DigiGal 5 2,251 09-26-2011, 07:33 PM
Last Post: M. Joury
  Hits awful close to home! Dave Shaffer (Arizona) 3 1,426 08-05-2011, 11:05 PM
Last Post: mike reed
  A perfect stranger gave me a HP-41CV today. hecube 11 2,819 09-09-2010, 07:12 AM
Last Post: Norman Dziedzic
  How would a new HP 15c+ affect 15c market value? megarat 5 1,982 07-07-2010, 06:48 PM
Last Post: John Stark
  The perfect HP for the kitchen?! Mark Edmonds 6 1,842 10-29-2009, 05:52 AM
Last Post: Thomas Radtke

Forum Jump: