(trick) working with hours, minutes, seconds

[Tugdual]

Interesting reading here.
At first I had not understood that the °''" key could be used to enter values and I was using the 3rd white key (C key). It is pretty efficient! Wonder how many other things like this I didn't yet catch.

[Joe Horn]

(02-23-2014 06:28 AM)Tugdual Wrote:  Wonder how many other things like this I didn't yet catch.

The angle key (Shift Multiply) has a similar dual purpose. It can be used to type polar coordinates directly, e.g. 1 angle (pi/4), and it can be used to toggle complex numbers between polar and rectangular notation once they're on the history stack.

The Base key (Shift Subtract) types a "#" when the most recent result isn't a binary integer, or it launches the Integer Editor if there is a binary integer there.

All of these keys, including the fraction button, operate by default on the most recent result, but they will also work on any other result if you select it first.

In CAS only, [a b/c] performs either approx(Ans) or exact(Ans) depending on what's on the history stack.

Did I miss any other non-obvious keyboard behaviors?

[rprosperi]

(02-23-2014 01:43 PM)Joe Horn Wrote:  In CAS only, [a b/c] performs either approx(Ans) or exact(Ans) depending on what's on the history stack.

How does one convert a CAS symbolic result to numeric (sorta like RPL's ->NUM)?

Example: (CAS Exact setting ON) I was following another thread comparing machine accuracy, and in CAS mode did asin(acos(atan(tan(cos(sin(9)))))which gives a symbolic result (not worth typing here, presumably correct), so I then pressed [a b/c] hoping to see the numeric value but instead get an error, repeating the symbolic result and "Error: Bad Argument Value". No help from eval() either. Shift-Enter produces the same error as well.

I get that I can change the CAS Exact setting and re-enter the equation, but there must be some (obvious?) way to do this, no?

[Joe Horn]

(02-23-2014 05:36 PM)rprosperi Wrote:  How does one convert a CAS symbolic result to numeric (sorta like RPL's ->NUM)?

Example: (CAS Exact setting ON) I was following another thread comparing machine accuracy, and in CAS mode did asin(acos(atan(tan(cos(sin(9))))) which gives a symbolic result (not worth typing here, presumably correct) ...

It isn't correct, and that's the problem. It gets confused and returns a result with a mixture of degrees and radians: ASIN(SIN(9)-pi/2+90) [the exact form will depend on your simplification setting], which is the arcsine of 88 something. Gimme a B! Gimme a U! Gimme a G! Yay team!

Quote:... so I then pressed [a b/c] hoping to see the numeric value...

That's the correct thing to do, if the symbolic on level 1 can be evaluated. The one you had couldn't be evaluated, hence the error.

In your case, just drop the wrong answer and THEN press [a b/c] to approximate the original expression.

[Cristian Arezzini]

(02-23-2014 06:28 AM)Tugdual Wrote:  Wonder how many other things like this I didn't yet catch.

What about creating a new thread, sticky, with "tips'n'tricks" for the Prime - i.e. things not present (or not obvious) in the manual? Not a thread for discussions or questions, just the tricks. It could in time develop to something like the famous HP48's FAQ...

[Tugdual]

(02-24-2014 11:38 AM)Cristian Arezzini Wrote:  What about creating a new thread, sticky, with "tips'n'tricks" for the Prime - i.e. things not present (or not obvious) in the manual? Not a thread for discussions or questions, just the tricks. It could in time develop to something like the famous HP48's FAQ...

That would be a good idea but it should be "moderated".

I have another one BTW: when using the graphical version of PIECEWISE, use the comma key at the very end of the list to add new cases. Took me while to find that and this is also not consistent with matrix entries where the free slots denote new rows/columns.

[Helge Gabert]

(02-23-2014 05:36 PM)rprosperi Wrote:  

(02-23-2014 01:43 PM)Joe Horn Wrote:  In CAS only, [a b/c] performs either approx(Ans) or exact(Ans) depending on what's on the history stack.

How does one convert a CAS symbolic result to numeric (sorta like RPL's ->NUM)?

Example: (CAS Exact setting ON) I was following another thread comparing machine accuracy, and in CAS mode did asin(acos(atan(tan(cos(sin(9)))))which gives a symbolic result (not worth typing here, presumably correct), so I then pressed [a b/c] hoping to see the numeric value but instead get an error, repeating the symbolic result and "Error: Bad Argument Value". No help from eval() either. Shift-Enter produces the same error as well.

I get that I can change the CAS Exact setting and re-enter the equation, but there must be some (obvious?) way to do this, no?

What was the symbolic result you got? I get 3*pi-9, which is correct. And no problem with converting that with the a/b/c key. I have the CAS flag "exact" on as well. Maybe I'm missing something.

[Joe Horn]

(02-24-2014 04:20 PM)Helge Gabert Wrote:  What was the symbolic result you got? I get 3*pi-9, which is correct. And no problem with converting that with the a/b/c key. I have the CAS flag "exact" on as well. Maybe I'm missing something.

You're in radian mode. The original problem assumes degree mode (an input of 9 degrees, not 9 radians).

[Helge Gabert]

Aha!

Thanks - - that would explain it. Odd that radian mode is fine, and degree mode has this problem . . .

[Tugdual]

(02-24-2014 08:46 PM)Helge Gabert Wrote:  Aha!

Thanks - - that would explain it. Odd that radian mode is fine, and degree mode has this problem . . .

Did you try? I have the same problem in degree.
Also if I enter asin(sin(π)) I get zero in CAS degree mode.
Even more funny: acos(cos(π/2)) is 90 in degree

There are obviously meaningless hard coded optimizations...
Edit: I'm going to promote this as a bug.

[Helge Gabert]

Yes I tried, good catch! I usually only work in radian mode, that's why I never encountered this bug - - till now.