|Re: [HP-Prime xCAS] BUG: Bases and others =(|
Message #10 Posted by Tim Wessman on 11 Sept 2013, 9:39 a.m.,
in response to message #9 by Bernd Grubert
I thought I'd addressed this in the first response, but I can see how it might not be as explicit as I'd hoped. Let me explain further.
On the 48 series, you have no concept of a "dms" number. There is no special encoding of any kind for a dms angular value. It is completely up to the user to interpret the digits and use special commands as needed. Thus if you do 10.1234 + 10.1234 with the idea of adding two angular values, you will not get back 20.2508 but instead 20.2468. A special HMS+ would be needed to do what is desired here.
The degree symbol being used is *not* a unit declaration. Rather, it is a way to enter DMS values in a convenient fashion.
In Prime, if you type 90°12'34" in both locations, internally it is converted to the equivalent decimal value of 90.209444444. In the home screen, this number is flagged indicating "I am actually a DMS value" and so it is displayed to the user as 90°12'34" in the history. Since it is flagged, the user can just press + and internally it calls the HMS+ equivalence.
In the CAS though, when you type 90°12'34" and press enter, you are returned 90.209444444 in the history. It is the equivalent of doing HMS->(90.1234) on the 48 series.
The graphic at in the first post is not correct as it has been constructed peicemeal in a graphic editing program. The CAS screen never shows sin(90°) as is pictured. Rather, it would show sin(90.) indicating that the 90 is a real number value. What has actually been typed is "sin(hms->(90))" and it is perfectly correct to interpret the number as it has been evaluated. Every prior hp calculator would have returned the same result.
There are two ways to think about this. Either we could have completely disabled the ability to enter DMS in the CAS (and dealt with the accompanying complaint of "why doesn't it just convert it to a decimal angular value for convenience?"), or have it allow the input but convert the DMS form into a decimal numerical value (the current behavior). Long term, the CAS could be potentially be improved to get a similar dms object type implemented and that would be the ideal case.
It was decided to implement #2 above since there are definite advantages to allowing input like that. The assumption was that users using DMS are going to be the more advanced users who need less hand holding. Thus choice #2 was deemed the lesser of two non ideal behaviors.
Edited: 11 Sept 2013, 9:40 a.m.