+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: HP Calculators (and very old HP Computers) (/forum-3.html)
+--- Forum: General Forum (/forum-4.html)
+--- Thread: why is RPN always reversed (not PN) (/thread-3968.html)
why is RPN always reversed (not PN) - StephenG1CMZ - 05-25-2015 06:14 AM
Can anyone explain why RPN is always reversed.
I have always thought Polish notation better - and not because of my surname.
in RPN, operands are written before operators.
Which means
"a long text with pages of legal small print" PRINT is OK
But
"A long text " ADD
Fails with a syntax error after a couple of hours of typing and translating.
(Mathematicians may use an example involving the digits of pi and a function expecting an integer instead)
Whereas in Polish notation of course the operands follow the operator (the sequence is reversed from that of RPN, or simply unreversed).
ADD "a very short text
Fails with a syntax error as soon as you hit the "
To me, that ability to detect an error before typing in a complex operand seems a clear winner.
Yet PN never seems to be used, only RPN.
What are the advantages of reversing the sequence?
RE: why is RPN always reversed (not PN) - Thomas Radtke - 05-25-2015 06:42 AM
In PN, you'd need to have a mixed stack of operators and operands, which ruled this notation out for early calculators imo.
RE: why is RPN always reversed (not PN) - Gerald H - 05-25-2015 07:11 AM
In RPN the operators operate immediately - they don't hang around testing the environment until conditions to operate are fulfilled.
RE: why is RPN always reversed (not PN) - StephenG1CMZ - 05-25-2015 07:19 AM
(05-25-2015 06:42 AM)Thomas Radtke Wrote: In PN, you'd need to have a mixed stack of operators and operands, which ruled this notation out for early calculators imo.
I must be misunderstanding something here...
To me,
1 2 + 3 *
And
* 3 + 2 1
Would both appear to need a stack capable of storing operands or oprerators in a mixed sequence - but only one might generate an error as you enter 3.14i nstead of 3 (depending on the domain of your + and * functions).
RE: why is RPN always reversed (not PN) - Les Bell - 05-25-2015 07:44 AM
(05-25-2015 07:19 AM)StephenG1CMZ Wrote: To me,
1 2 + 3 *
And
* 3 + 2 1
Would both appear to need a stack capable of storing operands or oprerators in a mixed sequence - but only one might generate an error as you enter 3.14i nstead of 3 (depending on the domain of your + and * functions).
No - as Gerald H has pointed out, the RPN version is able to execute the operators immediately and has no need to store them.
What you are really getting at is the notion of type safety and type promotion. In your example, you use the ADD or + operator, which might cause a syntax error when applied to strings. However, it might not if it really represents string concatenation and it can promote, say, a number higher on the stack to a string to allow that.
And while the prefix version might detect the syntax error as soon as it sees the opening quote of the string, it might not - in fact, probably would not - see that quote until you've entered the entire quoted string, eliminating any keystrong advantage for the prefix approach. Generally, a line won't get parsed until the entire line has been entered by pressing "Enter", whether on a calculator-like device or on a computer keyboard.
RE: why is RPN always reversed (not PN) - Didier Lachieze - 05-25-2015 09:01 AM
LISP is using a Polish Notation: 1 2 + 3 * is written in LISP as (* 3 (+ 1 2))
RE: why is RPN always reversed (not PN) - Gerald H - 05-25-2015 09:54 AM
(05-25-2015 09:01 AM)Didier Lachieze Wrote: LISP is using a Polish Notation: 1 2 + 3 * is written in LISP as (* 3 (+ 1 2))
Brackets bounce back from beyond the boundary, rebirthing before you bellow "RPN".
RE: why is RPN always reversed (not PN) - ndzied1 - 05-25-2015 10:59 AM
As a side note I was once told that LISP stands for
Lots of Irritating Silly Parenthesis
RE: why is RPN always reversed (not PN) - nlj - 05-25-2015 11:44 AM
(05-25-2015 06:14 AM)StephenG1CMZ Wrote: Can anyone explain why RPN is always reversed.
What are the advantages of reversing the sequence?
Another answer is that with a prefix notation it would be very hard to use the result of a previous calculation in a subsequent calculation.
Say you've completed some calculation 1 and the result is on Level 1 of the stack. Now you want to do calculation 2 using the result. You now need to get the operator for calculation 2 into Level 2 of the stack somehow. You can't just enter it and use SWAP because SWAP is now a prefix operator too and you would need to have entered it before you did calculation 1. (Indeed, if you are doing multiple calculations in a row you will need to have the foresight to put as many SWAPs on the stack as you will have operators in your calculations, before you begin.)
You might think of storing the result of calculation 1 in a variable and then recalling it again once you have your operator on the stack. But STO is now a prefix operator so you would need to have entered it before its arguments.
So you delete the result from calculation 1 from the stack, enter your operator for calculation 2 and then retype the result from calculation 1! But even that is problematical since DROP is now a prefix operator and would need to have been on the stack already!
So it seems that using prefix operators with a stack doesn't make sense unless you have a special set of postfix operators for working on the stack itself, like DROP and SWAP. (The subset of operators that had best be postfix will tend towards the entire set and you're back at RPN.) Otherwise you must have inhuman forethought.
Alternatively you're stuck using a lisp-like syntax (as pointed out by Gerald H), which is fine for programming or for interactive use when you can enter complete forms, but not so useful for entry element by element from a calculator keyboard.
RE: why is RPN always reversed (not PN) - StephenG1CMZ - 05-25-2015 12:04 PM
(05-25-2015 07:11 AM)Gerald H Wrote: In RPN the operators operate immediately - they don't hang around testing the environment until conditions to operate are fulfilled.
Ah! Now I see.
Thanks for the explanation everybody.
Personally I prefer the PN though.
RE: why is RPN always reversed (not PN) - StephenG1CMZ - 05-25-2015 12:23 PM
[quote='Les Bell' pid='36058' dateline='1432539866
What you are really getting at is the notion of type safety and type promotion. In your example, you use the ADD or + operator, which might cause a syntax error when applied to strings. However, it might not if it really represents string concatenation and it can promote, say, a number higher on the stack to a string to allow that.
l
[/quote]
Concatenation was actually the first example I thought of - because some languages allow + but others expect & or Concat or Str(num), so as I use a variety show of languages I would often be likely to do a lot of typing in then hit + in the wrong language.
But now I see why RPN is easier. Thanks.