[HP-Prime xCAS] BUG: Bases and others =(



Spn forum


Edited: 10 Sept 2013, 1:21 p.m. after one or more responses were posted


Integers in CAS are infinite precision integers. In home they are 64 bits and totally different objects and used in a totally different way...



Integers in CAS are infinite precision integers. In home they are 64 bits and totally different objects and used in a totally different way...

[HOME] sin(90 GRADE symbol) = 1

[CAS] sin(90 GRADE symbol) = 0.89 ???

Edited: 10 Sept 2013, 1:25 p.m.


The CAS does not have the concept of a numerical number that is a DMS object. You are actually entering 90°00'00" which cannot exist in the CAS. It is thus converted into a regular numerical value.

Numerical functions in the hp math library recognize a DMS value. The CAS has no concept of DMS which is basically a purely numerical concept. It is behaving exactly like the 50g in this regard. If you put SIN(HMS->(90)) in radian mode in the 50g the exact same thing happens. This is not a unit, but a new way in Prime to enter DMS values and allow them to work seamlessly without unneeded conversions or special commands.

Try doing 90°12'34" in both locations without the sin() and you will see better what is going on. The value is converted to a numerical value, but it no longer is an angular value that can be treated differently then any number.


Edited: 10 Sept 2013, 3:42 p.m.


Computer Algebra Systems AKA CAS does not mean that is only for symbolic computation, perfectly can work numerically and to me there is ambiguity between HOME and CAS mode, ie numerical calculation of HOME everything should be exactly the same results in the CAS

Accuracy can vary, but NO the results

ademas es un BUG por que si el catalogo en CAS MODE muestra un comando es para usarlo, de lo contrario para que esta dentro del catalogo

Edited: 10 Sept 2013, 6:36 p.m.


There are inherent differences between numerical and exact systems. No matter which piece of software is used there will always be places where something numerical gives different results and behaves differently then things symbolic. There is no such thing as "perfect" harmony between the two. It is impossible by definition.

The primary difference is for which type of calculation the system is primarily designed. Low level design decisions make a huge impact in the software and simply because it *does* work does not mean that it is optimal, the best mode of operation, or other things. Look at any mathematical package and you will find these places where the ideal behavior does not mesh nicely with the other type of calculation.

The CAS is *intended* to be a different calculation environment though and *by design* is meant to behave differently and act as a symbolic environment. The goal is not to have a single, unified environment that attempts to guess what the user wants. The 50g is that way, the nspire is that way - Prime will never be so.

I agree that there are currently too many places where there are large differences between CAS operation and numerical operation and these should, and will, be resolved. Trying to make the Prime into a nspire clone however is not the goal.

>Accuracy can vary, but NO the results

Yes, they should. sin(pi) in a numerical environment and sin(pi) in a symbolic environment should never, strictly speaking, return identical results. Do you disagree?


Edited: 10 Sept 2013, 6:48 p.m.


Accuracy can vary, but NO the results

nSolve(x^3 = 9.1,x) => 2.08775947866 // numerical command

solve (x^3 = 9.1,x) => 2.08775947867 // numerical or sym cmd

Edited: 10 Sept 2013, 7:06 p.m.


What Tim is pointing out is that sin(pi) in a numerical environment by definition *MUST* be different than sin(pi) in a symbolic environment, even though in some cases rounding them to a finite precision might yield the same results.

In a numerical environment the argument we're calling "pi" can never actually be pi, but can only be a limited-precision approximation. The sin of this approximation cannot be equal to the sin of pi.


I think Tim and you missed the point. CompSystems didn't complain about giving a numerical value. He/she meant, that when I call sin(90 [deg]) I get sin(90[rad]) as result. This seems wrong to me, too. At least, I would expect to get a syntax error.



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.


Tim Wessman:
The graphic at in the first post is not correct as it has been constructed peicemeal in a graphic editing program.

Thanks Tim, I tried this on my HP Prime Emulator and I saw it too. I am going to put a spanish reply on adictoshp.org


En el foro adictoshp respondo

Edited: 12 Sept 2013, 1:47 p.m. after one or more responses were posted


Compsystems, I keep a copy of the first image you posted before, clearly I see your modification in the HP Prime CAS history: "sin(90°)" <--- This is false. In the real CAS appears: "sin(90.)"

First image sent by compsystem:

Compsystems, yo mantengo una copia de la primera imagen que publicaste allí, claramente se ve el retoque en el historial CAS de la HP Prime: "sin(90°)" <--- Esto es falso. En el CAS aparece "sin(90.)"

Primera imagen enviada por compsystem:


En el foro adictoshp respondo

Edited: 12 Sept 2013, 1:46 p.m.


Sorry Tim, I didn't know that the graphic was modified. Now I understand, that the calculated value is correct. Wouldn't it be more consistent to convert the value inside the CAS to radian instead of just converting it to the numerical value in deg?


Do you mean convert any input given in dms form to whatever the representative value in the current angle setting is instead? (eg 90d would return pi if the calc is in radians)

Hmm... interesting idea. Definitely requires more thought as it might cause some other issues in some other way. I can see argument for both ways here. On the one, going to the angular setting might make more sense in this case. However, if the user puts it in a program does it make sense to convert a degree value automatically into radians there when there might be further commands/calculations done on it. To radians conversion seems like it would make it diverge even further then the current home behavior in a way.

It is true that having the actual image showing what the calculator is interpreting displayed in the history makes a big difference there. Another example is the # in the CAS which shows that it is interpreting # as a function of some kind (specifically in this case, it is the equivalent of the ->ID command on the 50g).




SIN(90°) == - COS(180°) => RETURN TRUE


SIN(90°) == - COS(180°) => RETURN FALSE


Compsystems, Tim ya lo explicó.

Es el mismo caso que antes.

sin(90°) == 1,
-cos(180°) == -(-1),

sin(90°) ----> sin(90.) == 0.893996663601,
-cos(180°) ----> -cos(180.) == 0.598460069058,


Edited: 11 Sept 2013, 5:38 p.m.


He comprendido 100% la filosofía del xCAS =)

la siguientes sentencias NO son BUGs, no se que esta interpretando el CAS


sin( 90 space ° ) => "Error Syntax Error" ?

in cas MODE

sin( 90 space ° ) => SIN(90*°) ?


Please help me to encode the sentence where it says HELP0/1, as there is interpreting this line no work

// version 0.05c
convertTF( test0);

Export func1( arg0 )
Local str0, str1, tmp0, test0;
tmp0 := 2*arg0;
str0 := "sin( " + arg0 + "° )" ;
str1 := "cos( " + tmp0 + "° )" ;

Print( "Identidades con la HP-Prime" );
Print( " " );
Print( "HOME MODE:" );

Print( str0+" = "+EXPR( str0 ));
Print( str1+" = "+EXPR( str1 ));
test0 := convertTF( EXPR( str0+" == -"+str1));
Print( str0+" == -"+str1+" => "+test0 );

Print( " " );
Print( "CAS MODE:" );
Print( "/!\ El símbolo de grado ° no implica conversión a grados" );
Print( str0+"="+CAS.EXPR( str0 ) ); // help0
Print( str1+"="+CAS.EXPR( str1 ) ); // help1
test0 := convertTF( CAS.EXPR( str0+" == -"+str1 )); // help2
Print( str0+" == -"+str1+" => "+test0 );

Export convertTF(test0)
If test0 == true
test0 := "true";
test0 := "false";

Edited: 12 Sept 2013, 8:42 a.m. after one or more responses were posted


3 new BUGS when running the previous program

forgiveness in Castilian ={

EL programa anterior presenta 3 nuevos BUGs, ver captura de imagen superior

0: noten que la palabra grados el caracter "g" esta cortado // BUG CONFIRMADO

1: en CAS MODE

sin(90°) = 1 // no es 1 sino 0.89 ya se discutió eso y quedo bien entendido, pero porque da 1? puede ser que mi programa este mal codificado o que halla un problema con el comando CAS. // BUG NO CONFIRMADO esperemos que dice TIM u otro desarrollador de la HP-Prime nos respondan y aclaren esto


en el programa hago una advertencia
Print( "CAS MODE:" );
Print( "/!\ El símbolo de grado ° no implica conversión a grados" );

para que futuros usuarios no se asusten cuando vean mi imagen y observen que seno de 90 grados da 0.89 ~ 0.9

2: en la pantalla se muestra que no se evaluó SIN(90) en la primer versión del programa

Possibly Related Threads...
Thread Author Replies Views Last Post
  Sending little images to the Prime (...and Program name bug?) Erwin Ried 19 2,725 12-10-2013, 05:35 PM
Last Post: Erwin Ried
  [HP Prime] Plots containing complex numbers bug? Chris Pem10 7 1,357 12-05-2013, 07:40 AM
Last Post: cyrille de Brébisson
  [HP Prime] plotfunc() bug in CAS Chris Pem10 2 833 12-04-2013, 02:46 PM
Last Post: Chris Pem10
  HP Prime Spreadsheet Copy bug Michael de Estrada 1 689 12-03-2013, 11:34 PM
Last Post: Walter B
  HP Prime Matrix TERRIBLE bug and question uklo 19 2,226 11-25-2013, 12:10 PM
Last Post: Mic
  HP Prime graphing bug BruceH 1 579 11-19-2013, 08:14 AM
Last Post: Joe Horn
  [Prime] Shutdown timer bug? Cristian Arezzini 2 600 11-16-2013, 10:34 AM
Last Post: Cristian Arezzini
  HP Prime: Linear Solver app bug BruceH 0 409 11-15-2013, 06:36 PM
Last Post: BruceH
  Possible bug with sqrt function in the HP prime Michael de Estrada 6 943 11-15-2013, 12:49 PM
Last Post: Michael de Estrada
  [HP Prime] Calculating Prandtl Number with Units (bug found in USIMPLIFY) Timothy Roche 1 524 11-13-2013, 04:07 PM
Last Post: cyrille de Brébisson

Forum Jump: