The Museum of HP Calculators

HP Forum Archive 21

 [HP-Prime xCAS] BUG: Bases and others =(Message #1 Posted by CompSystems on 10 Sept 2013, 1:00 p.m. Hello Spn forumEdited: 10 Sept 2013, 1:21 p.m. after one or more responses were posted

 Re: [HP-Prime xCAS] BUG: Bases and others =(Message #2 Posted by Tim Wessman on 10 Sept 2013, 1:17 p.m.,in response to message #1 by CompSystems Integers in CAS are infinite precision integers. In home they are 64 bits and totally different objects and used in a totally different way... TW

 Re: [HP-Prime xCAS] BUG: Bases and others =(Message #3 Posted by CompSystems on 10 Sept 2013, 1:21 p.m.,in response to message #2 by Tim Wessman Quote: Integers in CAS are infinite precision integers. In home they are 64 bits and totally different objects and used in a totally different way... TW In RAD MODE [HOME] sin(90 GRADE symbol) = 1 [CAS] sin(90 GRADE symbol) = 0.89 ??? Edited: 10 Sept 2013, 1:25 p.m.

 Re: [HP-Prime xCAS] BUG: Bases and others =(Message #4 Posted by Tim Wessman on 10 Sept 2013, 3:40 p.m.,in response to message #3 by CompSystems 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. TW Edited: 10 Sept 2013, 3:42 p.m.

 Re: [HP-Prime xCAS] BUG: Bases and others =(Message #5 Posted by CompSystems on 10 Sept 2013, 6:27 p.m.,in response to message #4 by Tim Wessman 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.

 Re: [HP-Prime xCAS] BUG: Bases and others =(Message #6 Posted by Tim Wessman on 10 Sept 2013, 6:46 p.m.,in response to message #5 by CompSystems 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? TW Edited: 10 Sept 2013, 6:48 p.m.

 Re: [HP-Prime xCAS] BUG: Bases and others =(Message #7 Posted by CompSystems on 10 Sept 2013, 7:05 p.m.,in response to message #6 by Tim Wessman 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.

 Re: [HP-Prime xCAS] BUG: Bases and others =(Message #8 Posted by Eric Smith on 10 Sept 2013, 7:14 p.m.,in response to message #7 by CompSystems 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.

 Re: [HP-Prime xCAS] BUG: Bases and others =(Message #9 Posted by Bernd Grubert on 11 Sept 2013, 3:02 a.m.,in response to message #8 by Eric Smith 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.

 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 Hello, 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. TW Edited: 11 Sept 2013, 9:40 a.m.

 Re: [HP-Prime xCAS] BUG: Bases and others =(Message #11 Posted by deachp on 11 Sept 2013, 11:13 a.m.,in response to message #10 by Tim Wessman 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

 Re: [HP-Prime xCAS] BUG: Bases and others =(Message #12 Posted by CompSystems on 11 Sept 2013, 1:23 p.m.,in response to message #11 by deachp En el foro adictoshp respondo Edited: 12 Sept 2013, 1:47 p.m. after one or more responses were posted

 Re: [HP-Prime xCAS] BUG: Bases and others =(Message #13 Posted by deachp on 11 Sept 2013, 2:07 p.m.,in response to message #12 by CompSystems 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: Spanish: 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:

 Re: [HP-Prime xCAS] BUG: Bases and others =(Message #14 Posted by CompSystems on 11 Sept 2013, 3:27 p.m.,in response to message #13 by deachp En el foro adictoshp respondo Edited: 12 Sept 2013, 1:46 p.m.

 Re: [HP-Prime xCAS] BUG: Bases and others =(Message #15 Posted by Bernd Grubert on 11 Sept 2013, 3:38 p.m.,in response to message #10 by Tim Wessman 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?

 Re: [HP-Prime xCAS] BUG: Bases and others =(Message #16 Posted by Tim Wessman on 11 Sept 2013, 4:21 p.m.,in response to message #15 by Bernd Grubert 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). TW

 Re: [HP-Prime xCAS] BUG: Bases and others =(Message #17 Posted by CompSystems on 11 Sept 2013, 5:00 p.m.,in response to message #16 by Tim Wessman [RAD MODE AND HOME MODE] SIN(90°) == - COS(180°) => RETURN TRUE [RAD MODE AND CAS MODE ] SIN(90°) == - COS(180°) => RETURN FALSE

 Re: [HP-Prime xCAS] BUG: Bases and others =(Message #18 Posted by deachp on 11 Sept 2013, 5:37 p.m.,in response to message #17 by CompSystems Compsystems, Tim ya lo explicó. Es el mismo caso que antes. HOME: TRUE, sin(90°) == 1, -cos(180°) == -(-1), CAS: FALSE, sin(90°) ----> sin(90.) == 0.893996663601, -cos(180°) ----> -cos(180.) == 0.598460069058, Entendiste? Edited: 11 Sept 2013, 5:38 p.m.

 Re: [HP-Prime xCAS] BUG: Bases and others =(Message #19 Posted by CompSystems on 11 Sept 2013, 10:23 p.m.,in response to message #18 by deachp He comprendido 100% la filosofía del xCAS =) la siguientes sentencias NO son BUGs, no se que esta interpretando el CAS in HOME MODE 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 ) Begin 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 ); End; Export convertTF(test0) Begin If test0 == true Then test0 := "true"; Else test0 := "false"; End; End; ``` Edited: 12 Sept 2013, 8:42 a.m. after one or more responses were posted

 Re: [HP-Prime xCAS] BUG: Bases and others =(Message #20 Posted by CompSystems on 12 Sept 2013, 8:41 a.m.,in response to message #19 by CompSystems 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 NOTA: 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

Go back to the main exhibit hall