HP Prime Questions

[Clayton Workman]

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

[Paul Dale]

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

[Clayton Workman]

Thanks. I was just thinking about this and wondered if that was going on.

[Paul Dale]

It is only a suspicion on my part but it does fit the symptoms well. I don't have a prime.

- Pauli

[CompSystems]

request to hp

0: pretty print for ( R, <_ )

http://en.wikipedia.org/wiki/Prettyprint

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

http://en.wikipedia.org/wiki/Phasor

http://en.wikipedia.org/wiki/Angle_notation

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

[Clayton Workman]

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

[Tim Wessman]

> 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

[CompSystems]

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.

[Clayton Workman]

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.)

[Tim Wessman]

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.

[CompSystems]

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

[Tim Wessman]

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

[Han]

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.

[CompSystems]

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?

[CompSystems]

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;

[CompSystems]

[]=> 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;

[CompSystems]

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;

[Tim Wessman]

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.

[CompSystems]

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

[Han]

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.

[CompSystems]

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.

[CompSystems]

more info on polar_coordinates & randPoly

http://www.adictoshp.org/topic/457-uso-del-comando-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&#8737;53.1301023542)+(5&#8737;36.8698976458); => (9.89949493661&#8737;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&#8737;53.1301023542)+(5&#8737;36.8698976458); => (7,7) // ~OK :(

polar_coordinates( (5&#8737;53.1301023542)+(5&#8737;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&#8737;53.1301023542)+(5&#8737;36.8698976458); => (9.89949493661&#8737;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&#8737;53.1301023542)+(5&#8737;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&#8737;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.

[CompSystems]

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

[Clayton Workman]

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