HP Prime Questions - Printable Version +- HP Forums (https://archived.hpcalc.org/museumforum) +-- Forum: HP Museum Forums (https://archived.hpcalc.org/museumforum/forum-1.html) +--- Forum: Old HP Forum Archives (https://archived.hpcalc.org/museumforum/forum-2.html) +--- Thread: HP Prime Questions (/thread-251233.html) HP Prime Questions - Clayton Workman - 09-25-2013 Hi all, I'm enjoying my new HP Prime, but I have a few questions that someone here might be able to answer: 1) Is there any way to "Undo" an operation in RPN mode. I can't find a reference to this in the manual. For example, If I press "2" "ENTER" "2" "ENTER", my stack has two lines with the number "2" in them. I can then do an operation such as "+" to add them and get "4" in the stack (the two rows of "2" are consumed and are not displayed anymore - as expected.) I would like to undo the operation and have my stack return to two rows of "2". PLEASE tell me this calculator has this capability since I used this quite a bit on the HP-48, 49, and 50 calcs. 2) Is there a quick way to convert complex numbers from polar form to rectangular form. For example if I type "10 angle 45" (angle is the angle symbol on the "x" key), I get "10 angle 45" in the stack. I want a quick way to convert this to a+ib. I know I can use RE() and IM() to get the real and imaginary parts, but I wondered if there was a quick way to display the result as "a+ib". I'm doing this in "Home" mode and my settings are set to show complex numbers as "a+b*i" already. 3) This is more of an oddity than I'm curious about more than anything. In "Home" mode, if I type "12 angle 65" (where angle is the symbol on the "x" key), the result in the display is "12 angle 64.9999999999". If I type "5 angle 65", the result is "12 angle 65". It's only if I use certain magnitudes do I get this weird round-off oddity. Magnitudes where I see this are 4, 12, 15, 18 (as some examples.) Sometimes the angle is rounded down to 64.9999999999 and sometimes it is rounded up to 65.0000000001. Thanks in advance! -Clayton Re: HP Prime Questions - Paul Dale - 09-25-2013 Quote:3) This is more of an oddity than I'm curious about more than anything. In "Home" mode, if I type "12 angle 65" (where angle is the symbol on the "x" key), the result in the display is "12 angle 64.9999999999". If I type "5 angle 65", the result is "12 angle 65". It's only if I use certain magnitudes do I get this weird round-off oddity. Magnitudes where I see this are 4, 12, 15, 18 (as some examples.) Sometimes the angle is rounded down to 64.9999999999 and sometimes it is rounded up to 65.0000000001. My suspicion is the complex number is stored in rectangular internally and this represents an inexact conversion. - Pauli Re: HP Prime Questions - Clayton Workman - 09-25-2013 Thanks. I was just thinking about this and wondered if that was going on. Re: HP Prime Questions - Paul Dale - 09-25-2013 It is only a suspicion on my part but it does fit the symptoms well. I don't have a prime. - Pauli Re: HP Prime Questions - CompSystems - 09-25-2013 request to hp 0: pretty print for ( R, <_ ) PD: If complex flag => (x,y) and CAS MODE ON ( x, y ) [enter] => [ x, y ] ??? ( 3, 4 ) [enter] => ( 3, 4 ) // OK Ans to [Entry Line] => 3+4*i ??? [enter] => 3+4 *(0,1) ???? /// polar_coordinates([3,4]) => [5,53.1301023542] =( sorry for my bad English without the angle prefix <_; of the previous result, is ambiguous, and will do in a program to determine if the objects in the container [] are in rectangular or polar or (phasor)? polar_coordinates([3,4]) => [5, <_53.1301023542] OK if the input is in x format should keep the same x output format ( ) => ( ) [] => [] rectangular_coordinates[ 5 <_53.1301023542 ] => [3,4] // OK rectangular_coordinates( (5 <_53.1301023542) ) => (3,4) Edited: 25 Sept 2013, 10:45 a.m. after one or more responses were posted Re: HP Prime Questions - Clayton Workman - 09-25-2013 Thanks. This also shows an example of something that does slightly annoy me about that Prime, and that's just how different the behavior is between normal "home" mode and CAS mode. I realize that you're basically switching to a CAS engine in CAS mode, but I wish there could at least be some consistency. -Clayton Re: HP Prime Questions - Tim Wessman - 09-25-2013 > 1) Is there any way to "Undo" an operation in RPN mode. There currently is not. However, you do have lastarg. [Shift] [+] in RPN will allow you to get back the arguments consumed. That should be most of the way towards what you'd like. >2) Is there a quick way to convert complex numbers Shift-Angle, either with no selection and a complex on level 1, or with a specific level selected. It is similar to how the a b/c converts between fractional representations, or the d m s shift function on the a b/c key does regular to dms toggling. >3) This is more of an oddity than I'm curious about Yes, internally it is rectangular as surmised. TW Re: HP Prime Questions - CompSystems - 09-25-2013 Hello sorry for my bad English If angle prefix (<_) is not incorporated in the second component [ a, b ] within a program there mistakes Program secuence => BUG p0:=polar_coordinates([11.2763114494, 4.10424171991])=> [12.,20.0000000001] // BUG [12., <_20.0000000001] OK p1:=polar_coordinates([12.5,21.6506350946]) => [25.,60.] // BUG p0+p1 => [37.,80.] // BUG Other Bug With polynomials Edited: 25 Sept 2013, 11:19 a.m. Re: HP Prime Questions - Clayton Workman - 09-25-2013 Thank you so much, Tim! Your suggestions answers each of my questions perfectly. (And the [Shift] [+] does exactly what I wanted to do as far as an undo function!) Thanks, Clayton Re: HP Prime Questions - Clayton Workman - 09-25-2013 Quote: If angle prefix (<_) is not incorporated in the second component [ a, b ] within a program there mistakes p0:=polar_coordinates([11.2763114494, 4.10424171991])=> [12.,20.0000000001] // BUG [12., <_20.0000000001] OK p1:=polar_coordinates([12.5,21.6506350946]) => [25.,60.] // BUG p0+p1 => [37.,80.] // BUG Ouch, this is a pretty serious bug, in my opinion. Hopefully, it can be addressed soon. (This is in CAS mode only as far as I can tell.) Re: HP Prime Questions - Tim Wessman - 09-25-2013 There is no concept of an "angular value" in the CAS. It is doing exactly what it should be doing. You are mixing concepts without understanding how the system works and expecting it to work how you feel it should. This is exactly the same issue you complained about with the degree, minute, second. There is a uni-directional conversion to simplify entry. There is no equivalent object in the CAS. Thus information about angularity cannot stay with the object. sin(90o15'15") -> sin(90.25416...) (angular infomration lost) -> sin(numerical value) 5<)45 -> (convert input to rectangular approximation, angle information is lost)-> (complex in rectangular form) Is [ 1 2 ] + [ 3 45 ] a bug to return [ 3 47 ]? No. Would it be a bug if the display was [ 1 2 ] + [ 3 <)45 ]? Yes. The calculator is showing you exactly what it is doing and operating correctly here. TW Edited: 25 Sept 2013, 11:59 a.m. Re: HP Prime Questions - Tim Wessman - 09-25-2013 What is being said is basically this - on the 50g [ 1 2 ] [ 3 45 ] + is entered and the calculator magically knows that the second value of the second vector is an angular value in degrees, but the first is not. Be cautious and the displayed graphics are generally edited and it is not always clear which is what the calculator is really showing, and which is the "desired" look. At least in this case you can look at the "real image & sequence=>bug" one and see that it definitely is not. TW Edited: 25 Sept 2013, 11:57 a.m. Re: HP Prime Questions - CompSystems - 09-25-2013 Quote: There is no concept of an "angular value" in the CAS. It is doing exactly what it should be doing. You are mixing concepts without understanding how the system works and expecting it to work how you feel it should. This is exactly the same issue you complained about with the degree, minute, second. There is a uni-directional conversion to simplify entry. There is no equivalent object in the CAS. Thus information about angularity cannot stay with the object. sin(90o15'15") -> sin(90.25416...) (angular infomration lost) -> sin(numerical value) 5<)45 -> (convert input to rectangular approximation, angle information is lost)-> (complex in rectangular form) Is [ 1 2 ] + [ 3 45 ] a bug to return [ 3 47 ]? No. Would it be a bug if the display was [ 1 2 ] + [ 3 <)45 ]? Yes. The calculator is showing you exactly what it is doing and operating correctly here. TW The same example without using the angle symbol => BUG, follow the sequence and the sum of polar coordinates is erroneous please check the example of the polynomial Re: HP Prime Questions - Han - 09-25-2013 Quote: please check the example of the polynomial The calculator should have actually produced an error when he tried to add a vector of the form [ a b c ] to another vector of the form [ x y ]. At least this is the case on the older HP calculators. You get a dimension error. However, the overloading of the addition operator leads to a result of [ a+x b+y c ]. This probably links back to the prior thread on what it means to divide with non-square matrices (vectors of vectors vs matrix). I would rather the calculator give a dimension error rather than have the + operator be overloaded to give results that could easily be misinterpreted. Re: HP Prime Questions - CompSystems - 09-25-2013 Sorry Google translator from castillian to Eng There are many contradictions from the author of xcas, he says he wants to use a single container for many objects, you simply can not, the algebra is similar to certain cases, for example when adding polynomials of different "dimensions" is a setting of zeros to left, while vectors that could make an adjustment to the right So how does the xcas to differentiate a VECTOR of a vector of coefficients, poly1 adds a prefix to conteiner [], poly1 meaning one single variable vector, /// The addition operator and others can not know if the polar_coordinates command output is truly in polar coordinates, to solve this ambiguity is necessary to place a prefix of angle, p0:=polar_coordinates([11.2763114494, 4.10424171991])=> [12., <_ 20.0000000001] p0+ ... p0- ... po/ ... etc these operators currently interpreted as Cartesian coordinate output Am I right or not? Edited: 25 Sept 2013, 1:24 p.m. Re: HP Prime Questions - CompSystems - 09-25-2013 Quote: What is being said is basically this - on the 50g [ 1 2 ] [ 3 45 ] + is entered and the calculator magically knows that the second value of the second vector is an angular value in degrees, but the first is not. without the prefix angle is Cartesian, with the angle prefix polar coordinate, there is nothing magic HP48SX/GX/49G/G+/50G [ 1, 2 ] [ 3, 45 ] + => [ 4 47 ] // OK [ 1, <_2 ] [ 3, <_45 ] + => [ 3.7 <_34 ] //OK [ 1, 2 ] [ 3, <_45 ] + => [ 2.23, <_63 ] [ 3, <_45 ] => [ 5,<_ 52 ] // OK [/quote] Quote: Be cautious and the displayed graphics are generally edited and it is not always clear which is what the calculator is really showing, and which is the "desired" look. At least in this case you can look at the "real image & sequence=>bug" one and see that it definitely is not. TW I have upload a video Re: HP Prime Questions - Tim Wessman - 09-25-2013 Make sure the calculator is in degrees mode. In the home screen, press these keys: [1][2][shift][*][2][0] [+] [2][5][shift][*][6][0] [ENTER] then [ENTER][shift][*] The result is this screen. Now switch to CAS. Type [1][2][shift][*][2][0] [+] [2][5][shift][*][6][0] [ENTER] then use the command polar_coordinates(Ans) and the result is this screen. What is the calculation bug? The only difference is that, as I have explained already, the CAS has *no* concept of a numerical value that represents an angle. Thus it cannot keep your angular complex entry as it was entered. A small helper function converts it from a polar complex to a supported complex allowing you to directly calculate. The result will always be Cartesian since that is the only form usable. TW Re: HP Prime Questions - Han - 09-25-2013 I agree that there is no bug in this particular scenario. Perhaps a note somewhere in the documentation (tongue-in-cheek) would be useful. =) But what about this issue of regular operators being overloaded in an unconventional way? I am aware that some may find these overloading features useful, but as a mathematical tool, operations should NOT be overloaded unless it is universally accepted everywhere. While one group may find them useful, another group may find it annoying (sometimes calling them bugs). I remember the discussion on whether non-square matrices should be considered "vector of vectors" vs. a matrix so that "/" can be overloaded to divide vectors of vectors in the case of non-square matrices used as arguments. Below (in this thread) is a mini-discussion on why vectors of different dimensions are allowed to be added (again due to overloading the "+" operator) so that [ a, b, c ] + [ d, e ] becomes [ a+d, b+e, c ] and not [ a, b+d, c+e ]. As a mathematician, I would think the latter would be the expected outcome, not the former. Would it be difficult to simply add in a flag / setting that toggles these overloaded features -- and have it by default disable overloading? That way, you would actually have to purposely want these overloaded features -- with the presumption that you know what you are getting into when you enable such a setting. Edited: 25 Sept 2013, 2:20 p.m. Re: HP Prime Questions - CompSystems - 09-25-2013 sequence to reproduce the BUG, you can make a program if doubt/ secuencia para reproducir el BUG paso0: // definir y asignar la 1er coordenada cartesiana carCoo0:=[11.2763114494, 4.10424171991]; // OK paso1: // convertir a polares con el comando polar_coordinates polCoo0:= polar_coordinates( Ans ); => [12.,20.0000000001] // OK paso2: // definir y asignar la 2da coordenada cartesiana carCoo1:=[12.5,21.6506350946]; // OK paso3: // convertir a polares con el comando polar_coordinates polCoo1:= polar_coordinates( Ans ); => [25.,60.] // OK paso4: // sumar los valores de conversión sumPolCoo:= polCoo0 + polCoo1; => // [37.,80.] // BUG or NOT? Re: HP Prime Questions - CompSystems - 09-25-2013 BugSumPolarCoo() ```EXPORT BugSumPolarCoo() BEGIN carCoo0:=[11.2763114494, 4.10424171991]; // step0: // convertir a polares con el comando polar_coordinates polCoo0:= polar_coordinates( carCoo0 ); // => [12.,20.0000000001] // step1: // definir y asignar la 2da coordenada cartesiana carCoo1:=[12.5,21.6506350946]; // step2: // convertir a polares con el comando polar_coordinates polCoo1:= polar_coordinates( carCoo1 ); // => [25.,60.] // step3: // sumar los valores de conversión sumPolCoo:= polCoo0 + polCoo1; // => [37.,80.] print( sumPolCoo ); // => [37.,80.] END; ``` Re: HP Prime Questions - CompSystems - 09-25-2013 []=> por {} ```EXPORT BugSumPolarCoo() BEGIN carCoo0:={11.2763114494, 4.10424171991}; // step: // convertir a polares con el comando polar_coordinates polCoo0:= polar_coordinates( carCoo0 ); // => [12.,20.0000000001] // step: // definir y asignar la 2da coordenada cartesiana carCoo1:={12.5,21.6506350946}; // step3: // convertir a polares con el comando polar_coordinates polCoo1:= polar_coordinates( carCoo1 ); // => [25.,60.] // step4: // sumar los valores de conversión sumPolCoo:= polCoo0 + polCoo1; // => // [37.,80.] print( sumPolCoo ); END; ``` Re: HP Prime Questions - CompSystems - 09-25-2013 si cambio [] => () falla también ``` EXPORT BugSumPolarCoo() BEGIN carCoo0:=(11.2763114494, 4.10424171991); // step: // convertir a polares con el comando polar_coordinates polCoo0:= polar_coordinates( carCoo0 ); // => [12.,20.0000000001] // step: // definir y asignar la 2da coordenada cartesiana carCoo1:=(12.5,21.6506350946); // step3: // convertir a polares con el comando polar_coordinates polCoo1:= polar_coordinates( carCoo1 ); // => [25.,60.] // step4: // sumar los valores de conversión sumPolCoo:= polCoo0 + polCoo1; // => // [37.,80.] print( sumPolCoo ); END; ``` Re: HP Prime Questions - CompSystems - 09-25-2013 more info on polar_coordinates & randPoly En la pagina 191 de la guia de usuario DICE polar_coordinates: Returns a vector containing the polar coordinates of a point or a complex number. polar_coordinates(sqrt(2),sqrt(2)); [ENTER] [ 2, 45 ] nada mas En ninguna otra parte habla de polar_coordinates, ni del universal tipo de dato [ ], el manual de usuario es muy muy pobre tanto en ejemplos, como en el funcionamiento de cada comando, estamos esperando el MANUAL AVANZADO DE USUARIO, sera que si esta en redacción? espero que si Espero también que TIM, o alguien me diga para que se usa este comando, es decir es solo demostrativo? para impresión o vista solo en el historial, por que claramente no se puede operar con el, es decir los operadores +,-,/ no operan sobre la salida de polar_coordinates(), ni mucho menos funcionara dentro de un programa /!\ polar_coordinates([3,4]) + polar_coordinates([4,3]); no implica suma de coordenadas polares en la HP-Prime, esto es lo que debe decir el manual, y no es suma en polares por que la salida esta en un contenedor universal que no hace referencia a un tipo de dato especifico Si usted desea sumar directamente la salida del comando polar_coordinates se lleva una sorpresa Una manera de obtener la suma de coordenadas polares es sumar en su forma cartesiana y luego convertirlo a polar Ejemplo: polar_coordinates([3,4.]+[4,3]); // => [9.89949493661,45.] // la anterior salida se interpreta visualmente como radio=9.89949493661 y angulo de 45° polar_coordinates([3,4.]); => [5.,53.1301023542] => 5 angulo de 53° polar_coordinates([4,3.]); => [5.,36.8698976458] => 5 angulo de 36° note que sumar en coordenadas polares no es equivalente a sumar elemento a elemento [ 5+5, 53+36 ] => [ 10 , 89 ] mientras que en coo cartesianas la suma es la suma de componentes [3,4]+[4,3]; => [7,7] polar_coordinates([7,7.]); // => [9.89949493661,45.] En el modo HOME hay una manera directa para sumar en coordenas polares usando el prefijo ANGLE (5∡53.1301023542)+(5∡36.8698976458); => (9.89949493661∡45) EXCELENTEMENTE OK :), preciso, como debe ser y sin ambigüedad En el modo CAS también suma coordenadas polares, pero la salida se convierte a rectangular :( y hay que volver a utilizar polar_coordinates() (5∡53.1301023542)+(5∡36.8698976458); => (7,7) // ~OK :( polar_coordinates( (5∡53.1301023542)+(5∡36.8698976458) ); => [9.89949493661,45.] Pero surge otro problema esta salida tampoco sirve porque se llevo al contenedor [ ] que no es re-utilizable por algoritmo :( LA PREGUNTA DEL MILLON, que limitación por software, porque no creo que sea por HARDWARE, la HP_PRIME En modo CAS no pueda retornar la salida en polar (5∡53.1301023542)+(5∡36.8698976458); => (9.89949493661∡45) es posible incorporar en futuras versiones esta característica o es imposible? si alguien que no conoce la HP_prime y mira la siguiente sentencia dentro de un programa polar_coordinates( (5∡53.1301023542)+(5∡36.8698976458) ); se pregunta, por que carajos tiene que convertir a polar si esta sumando en polares?? Una pregunta mas dificil Algún día, antes del fin del mundo, o antes que la competencia nos muestre una super TI_Nspire CAS+ con pantalla multitactil la HP_Prime podrá decodificar polar_coordinates([3,4]) + polar_coordinates([4,3]); como la suma de coordenadas polares? un reto para el autor del xCAS, y no quiero respuestas de ninos, no no puedo, es que yo uso un solo contenedor y tales y pascuales Por que yo si puedo crear un programa que me decodifique, es trivialsimimo y sin hacer trucos de conversion a cartesianas para luego sumar y luego volver a convertir a polar polarCoordinates([3,4]) + polarCoordinates([4,3]); Le pregunto al author del xCAS, es muy complicado incorporar el prefijo angle en el segundo parámetro del contenedor [ ], al igual como lo hace la HP48/HP50, el me dirá poder puedo, tengo que reescribir la mayor parte de mi codigo fuente y eso me lleva anios otro reto para el author del xCAS, incorporar postfijos de ° y radianes (5∡36.8698976458°) como lo hace la competencia otros me diran la TI_nspire no es competencia, pues la HP_prime calcula un factorial con cientos de números, el poder del CAS no solo se basa en el poder de mostrar n digitos, sino el poder de decodificar expresiones mas cercanas a la humana Redactando ... Edited: 25 Sept 2013, 10:45 p.m. Re: HP Prime Questions - CompSystems - 09-25-2013 Ahora el uso del comando randPoly como veo muchos comandos de la HP_prime, no se podrán utilizar directamente en conjunto con otros operadores, pues la salida universal como un tipo de dato implica que el interprete del motor de calculo, no pueda diferenciarlo, hay que hacer TRUCOS para que sea funcionales un ejemplo randPoly(2,1 .. 1)+randPoly(3,1 .. 1) => [2,2,2,1] => NO ES UN BUG, no retorna la suma de polinomios si no la suma de vectores, contradictorio pero verdad, aunque claramente la expresión me diga sumar 2 polynomios aletorios polar_coordinates([3,4]) + polar_coordinates([4,3]); => [ 10 , 90 ] NO ES UN BUG no retorna la suma entre coordenadas polares, si no la suma de vectores en coordenadas rectangulares, super contradictorio pero verdad, aunque claramente la expresión me diga sumar 2 coordenadas polares