Confused about expressions in Prime RPN stack

[Orome]

This may be a pretty basic question, but it has me stumped.

I'm confused about Prime's handing of expressions on the RPN stack. When I enter an expression by, for example, keying in

['☐'][3][x2]

and then subsequently select it on the stack and hit [ENTER], I get not the expression I entered, but 3^2, stripped (apparently) of the surrounding '..', so that if I try to do anything with it I get a syntax error. This confuses me because it's possible to put things on the RPN stack that the Prime then treats as syntax errors when picked off the stack. What am I missing?

(I'd have expected something like the 48, where putting an expression in '..' in the stack, selecting it and hitting [ENTER], or otherwise picking it, gives back the '..' expression. To do that on the Prime, I need to first key in ['☐'] to "put back" the '..' and then [ENTER].)

[mchris]

In RPN mode, everything you do is related to the stack, so I can not figure out what exactly you want to do with an algebraic expression in command line. Let's assume that you want to find a root of an expression with FNROOT, first you enter 'your_expression' to the stack, then you enter the variable ex: 'X', and then enter FNROOT(2), for there are 2 variables on the stack for the function FNROOT to pick. I can't imagine in what situation 'your_expression' would be of any use in command line in RPN mode.

[Orome]

(04-26-2020 06:21 PM)mchris Wrote:  I can not figure out what exactly you want to do with an algebraic expression in command line....I can't imagine in what situation 'your_expression' would be of any use in command line in RPN mode.

It's precisely of whatever use it was when it was being entered in the first place. (I can edit such an expression, for example.)

On 48s I can put it on the stack and then get it back and continue with whatever I was doing. On a Prime I can't get it back. So maybe one way of thinking abut the question is: why are the Prime semantics for picking different?

[rprosperi]

(04-26-2020 06:27 PM)Orome Wrote:  

(04-26-2020 06:21 PM)mchris Wrote:  I can not figure out what exactly you want to do with an algebraic expression in command line....I can't imagine in what situation 'your_expression' would be of any use in command line in RPN mode.

It's precisely of whatever use it was when it was being entered in the first place. (I can edit such an expression, for example.)

On 48s I can put it on the stack and then get it back and continue with whatever I was doing. On a Prime I can't get it back. So maybe one way of thinking abut the question is: why are the Prime semantics for picking different?

The Prime supports RPN, but nothing of RPL, except some extensions for types. So it behaves more like a 35S than a 48S.

[Orome]

(04-26-2020 07:50 PM)rprosperi Wrote:  

(04-26-2020 06:27 PM)Orome Wrote:  On a Prime I can't get it back. So maybe one way of thinking abut the question is: why are the Prime semantics for picking different?

The Prime supports RPN, but nothing of RPL, except some extensions for types. So it behaves more like a 35S than a 48S.

Yes, but the 35s doesn't let me create a formatted expression, which is how this issue arises.

The question is why I can use the Prime's "template" to create an algebraic — actually I guess "textbook" — expression which I can put on the stack and evaluate (and even perform operations on in the same way as I can on an RPL model; e.g. I can follow the creation of the expression with [2][+] and get the expected textbook formatted expression as a result); but if I pick it and press [ENTER], I get something that's considered invalid and can do nothing further with.

[Tim Wessman]

The "copy" command being used probably needs to have a check for "is it in RPN and is the edit line not active and is the item selected an expression".

Just "stick in ' ' " does not solve anything really as it messes up other cases.

[Orome]

(05-03-2020 08:10 AM)Tim Wessman Wrote:  The "copy" command being used probably needs to have a check for "is it in RPN and is the edit line not active and is the item selected an expression".

Just "stick in ' ' " does not solve anything really as it messes up other cases.

It feels like the inclusion of the RPN stack was an afterthought and wasn't fully tested (or documented for that matter).

[Steve Simpkin]

(05-03-2020 04:30 PM)Orome Wrote:  

(05-03-2020 08:10 AM)Tim Wessman Wrote:  The "copy" command being used probably needs to have a check for "is it in RPN and is the edit line not active and is the item selected an expression".

Just "stick in ' ' " does not solve anything really as it messes up other cases.

It feels like the inclusion of the RPN stack was an afterthought and wasn't fully tested (or documented for that matter).

I suspect it was more like a limited-function entry mode option that was a relatively low priority for the project. It think it was added (along with the double-wide Enter key) more as a favor to the hard core RPN old timers (like me) who frequent this forum. We should really thank the tiny but devoted team that developed the HP Prime for getting it added at all. I'm sure the bean counters and executives at HP would not have allowed 1 cent to be spent towards adding RPN mode if they had any say in this level of detail. It was certainly not an important feature for the educational market for which this product was developed for.

[pinkman]

Like the others I think you’ll have to force yourself to think Prime, not 48.
But of course you can use the RPN mode with its limitations, especially hitting the [' '] key before copying an algebraic object from the stack.
If the 48 had this constraint you would never have posted any complaint!

Examples:
2: 5*X
1: X
CAS.diff(2) [Enter]
The result is 5 as expected.

2: 5*X
1: F1
[Sto]
The F1 is now 5*X (or whatever expression the 2nd level of the stack holds).

It works very well, but it cannot be compared to RPL or classic RPN behavior. It only has the reverse polish logic in common, nothing more.

Regards.

[Orome]

(05-03-2020 06:48 PM)pinkman Wrote:  Like the others I think you’ll have to force yourself to think Prime, not 48.

I think you didn't read the question.

[pinkman]

(05-03-2020 06:50 PM)Orome Wrote:  

(05-03-2020 06:48 PM)pinkman Wrote:  Like the others I think you’ll have to force yourself to think Prime, not 48.

I think you didn't read the question.

Be sure I did. But maybe I did not understand it!

[edit]
I might have been blinded by these words from you: “ I'd have expected something like the 48”

[Orome]

(05-03-2020 07:32 PM)pinkman Wrote:  I might have been blinded by these words from you: “ I'd have expected something like the 48”

The reason for expecting that is simply that it's the natural (i.e. not buggy) behavior, not because I expect a 48: if I can put something on the stack, it should be preserved when I pick it from the stack (that's effectively how things have worked since the 35, and is basic RPN logic), and it puzzle's me the that's not what happens.

But I think we have the answer above: RPN isn't really part of the Prime's design, so it wasn't fully addressed in the final product (e.g. the equation template either should have been disabled in RPN mode, or picking an equation should have — well — picked the equation; also the documentation describes a lot of things that don't work in RPN, without clearly saying that they don't work there).

[pinkman]

I agree. I just don’t know if the reason is exact, but the consequences are the same: RPN on Prime is not perfect. It exists and it is already a good point, but my one and only User key is dedicated to quickly switch between RPN and Textbook.