Post Reply 
HP35s RPN Series # 3 [ENTER]
02-20-2015, 05:34 AM (This post was last modified: 02-20-2015 05:38 AM by MarkHaysHarris777.)
Post: #16
RE: HP35s RPN Series # 3 [ENTER]
(02-20-2015 02:19 AM)Sanjeev Visvanatha Wrote:  You had mentioned the "=" key earlier. Well, "=" is also in the same boat by your logic. It doesn't equal anything unless the user understands OOP and the use of parenthesis.

hi Sanjeev, sorry to be argumentative (because I enjoy dialoguing with you) but I must disagree again; and here is why... and it's important! The primary difference between the calculation methodology of classic HP RPN, and algebraic systems like TI's AOS, for instance, and others, is that RPN stacks ONLY the data. Algebraic systems necessarily stack BOTH the data AND the operators (and in fact, must stack the operators in some fashion with nested levels of parenthesis according to a complex set of 'algebraic hierarchy' or order of precedence of operations). This 'requires' necessarily and absolutely an 'equals' key. Now, for semantics, you may call the key [=], [Solve], [Resolve], [Approximate], or [GO], but hey, it necessarily must be there; equals actually and really means 'equals'. Something must tell the system to unstack the data (and the 'infix' operators) according to algebraic usage; the stack must be 'unwound' if you will. This is entirely different from the RPN methodology of [ENTER], and its semantics|baggage, whereby only the data are stacked and the user handles all of the policy of precedence and execution dynamics-- what 'postfix' calculation strategy of RPN is all about!

By the way, I do not really believe that the HP engineers in the beginning were really all fired up about Jan Łukasiewicz' PN, nor the elegance of 'postfix' methodology from some kind of intellectual pedestal (or anything like that, no one will ever convince me). That is just HP revisionist history to justify the paradigm. The real issue in 1972 was memory and speed. Why use valuable onboard memory (or complicated policy, programming) within the calculator when the user is better suited for the purpose of precedence and policy... when the calculator requires EVERY 'bit' (pun intended) of memory for the actual algorithms? Postfix methodology works well with a stack, and that's what Hewlett needed! The method may have come from Jan Łukasiewicz (at some level) but the mother-of-invention (primarily) involved the idea that logic of that era was 'slow' and memory was difficult and expensive.


Thanks for the dialogue.

Cheers,
marcus
Smile

Kind regards,
marcus
Find all posts by this user
Quote this message in a reply
Post Reply 


Messages In This Thread
RE: HP35s RPN Series # 3 [ENTER] - MarkHaysHarris777 - 02-20-2015 05:34 AM
RE: HP35s RPN Series # 3 [ENTER] - Tugdual - 02-19-2015, 08:37 AM



User(s) browsing this thread: 1 Guest(s)