on the RPN mentioning sharp pc-1211, v.albillo, el-506w and recurring topics

[pier4r]

(12-04-2017 04:32 PM)Trond Wrote:  Well......notice how many personal opinions and points of view you give here (e.g. you find this or that confusing). We all have a tendency to think that our own opinion reflects some sort of general truth. We're not discussing some physical constant here. It is all personal opinion.

I agree. We mostly write personal opinions.

Nonetheless, I am pretty sure the world runs way more algebraic calculators than RPN and I wanted to understad why, aside from the personal ego stroke: "ha! Their brain is poor!".

Now it is likely that many people see only algebraic systems, so they take it for granted. As people used to RPN stick with it.
What would happen if one is exposed, before being biased, to both worlds?

I suppose that if one can see the entire formula one is entering, plus the ability to quickly fix it, the RPN choice would be put aside.
If the formula cannot be seen, the the risk of having to retype the formula even just to be sure that the result is the same, because one may have doubts about possible typos, may swing the choice to RPN.
Although the point about "we compute in a very similar way to RPN" is also valid.

I see it as a composition of various factors.

RPN:
- likely easier: to develop parsers for the calculator because the human does most of the work.
- possibly easier: to control if the typing went awry and one has to redo the computations done until then. (here a sort of history of what one typed won't be bad. Aside from the short one present on the 50g)
- likely easier: to match the RPN procedure with how we would proceed to compute a formula in our brain.
- likely: it forces you to think about the formula and elaborate it, instead of brainlessly type in the calc. (this may be a unwanted overhead sometimes)
- possible advantage (weak?): saves some keystrokes most of the time.

algebraic:
- likely harder: if one cannot see the formula typed up to that point, it can be very frustrating if one makes a typo or has a doubt about a typo. Type everything again, no chances to inspect the formula mid course.
- likely easier: if one can see the formula that is typing. Since we are used to the algebraic notation.
- likely easier: to fix a formula if one can edit the formula that is typing.
- likely easier: if one can recall previous computations in form of algebraic entries.

At the end it seems a problem to avoid frustration rather than something else.

I would say that the power of "ability to quickly edit a formula" that, for example, the el 506w has, is quite the big deal. Together with the ability to recall (and edit) a previous algebraic entry. Frustration minimized most of the time.

To achieve a similar solution in RPN, for the little that I know, one should proceed to write a little program/keystroke sequence and then edit it if needed.

[Gene]

(12-03-2017 08:39 PM)pier4r Wrote:  Unless one writes on paper:

5 3 + *

I find that the trend is geared towards algebraics.

Gene: :-)

Big nitpick here, but 5 3 + * would be an error on the 50g and produce an unknown value in RPN based on what was in X before typing the 5.

Yes, I intend a :-) here.

[Gene]

More serious response. :-)

1) Most of what I compute is off the cuff on the spot computation where I am gathering data and having to compute things that were not prepared in advance. I don't **know** the formula up front so I work through it by hand. To me, RPN wins here hands down. I can compute a result and if it turns out I need to compute another result and then use it on the first result, I find RPN easier to do this in than algebraic.

2) As a previous programmer in AOS (I had TI calculators from the SR-51A to the SR-52, SR-56 and TI-58C) and a programmer in lots of RPN and RPL machine environments, I find programming on a calculator (that's important here) much harder in AOS than RPN. In a structured programming environment using a procedural language, algebraic orientation is fine. Through college, I got through BASIC, fortran, COBOL, SNOBOL, and more without a stack-oriented machine. However, on a calculator, I find it terribly difficult to keep track of what the state of the machine is on an AOS style machine vs. an RPN one. I have no doubts that programming on a TI graphing model is easier than the 58C, but ...

3) As a college professor who taught business math, statistics, managerial accounting, and operations management for quite a few years, I have found most non-engineering users of calculating devices do not think through problems AT ALL. Whatever the calculator (or Excel formula) gives as an answer must be the answer. It is a black box. Period. I think RPN makes it MORE likely than AOS to see if something went wrong by providing the intermediate answers. It is an advantage (to me) that you have to think through the problem because you are more likely not to suggest an answer is $500,000 when if fact it should have been $25. I've seen enough college students do things like that in part because they don't understand what they are doing... and AOS style machines (I classify the market leading TI BAII Plus machines this way) do not help you understand very well what you are doing.

My 2 cents. I am fluent in AOS and higher level languages, but find them impractical on anything lower level than the HP Prime except for cut and dried problems.

We now return you to your regularly scheduled program. :-)

[peacecalc]

Hello friends,

nice thread, but maybe the only reasons, why HP implemented RPN in his calcs are:

1) HP calcs are not like other calcs...
2) The user can save some keystrokes...

and all other reasons seems to be consequences or hindsight reasons, which weren't intended. The HP calc-user community is small and exclusiv. Nothing more, but nothing less either.

[franz.b]

you made me think of an important detail: seeing partial results helps a lot in understanding what you are doing and prevents gross errors, as has already been said.

It is true that most calculators are algebraic, but most people look for a family environment and do not try the pros and cons of the alternatives, so the builders are not interested in proposing something different without courage. Android vs. WindowsPhone vs iOS teach: those who have a system hardly leave it, whatever the advantages or disadvantages.

[pier4r]

(12-04-2017 06:50 PM)Gene Wrote:  More serious response. :-)

1) Most of what I compute is off the cuff on the spot computation where I am gathering data and having to compute things that were not prepared in advance. I don't **know** the formula up front so I work through it by hand. To me, RPN wins here hands down. I can compute a result and if it turns out I need to compute another result and then use it on the first result, I find RPN easier to do this in than algebraic.

Yes I can see also that for explorations RPN is faster. Because it is like trial and errors and errors in algebraic are costly.

Quote:2) As a previous programmer in AOS (I had TI calculators from the SR-51A to the SR-52, SR-56 and TI-58C) and a programmer in lots of RPN and RPL machine environments, I find programming on a calculator (that's important here) much harder in AOS than RPN. In a structured programming environment using a procedural language, algebraic orientation is fine. Through college, I got through BASIC, fortran, COBOL, SNOBOL, and more without a stack-oriented machine. However, on a calculator, I find it terribly difficult to keep track of what the state of the machine is on an AOS style machine vs. an RPN one. I have no doubts that programming on a TI graphing model is easier than the 58C, but ...

Well in my mind I had only calculators that compute formulas or functions. I did not consider programs (aside from small ones). Indeed I picked the el 506w as example that is not programmable. Still one can define formulas to reuse later that are like a little program (if one uses and fills the variables).


RPN is concise for a calculator keyboard, algebraic would need more effort (given my experiences with a casio fx 7400 and the ti89).

For the nitpick: true! My bad.

[toml_12953]

(12-04-2017 06:02 PM)Maximilian Hohmann Wrote:  

(12-04-2017 04:32 PM)Trond Wrote:  We're not discussing some physical constant here. It is all personal opinion.

Personally I am bilingual in that respect but see RPN a bit like Latin which I had to study at school. A very logical language and the basis for many modern languages, but otherwise pretty much defunct.

I don't know about defunct. Was it ever funct in the first place? Compilers still use it to parse and compute expressions so even if end users don't see it, it's being used every day in hundreds of millions of machines.

[DavidM]

(12-04-2017 06:50 PM)Gene Wrote:  1) Most of what I compute is off the cuff on the spot computation where I am gathering data and having to compute things that were not prepared in advance. I don't **know** the formula up front so I work through it by hand. To me, RPN wins here hands down. I can compute a result and if it turns out I need to compute another result and then use it on the first result, I find RPN easier to do this in than algebraic.

Gene, you've summarized nicely in the above quote what has been nagging at me as I've been reading through this thread. The type of use you are describing matches quite closely to most of what I tend to do, as opposed to many who seem to make frequent use of formulas and symbolic manipulation of expressions. I agree with you that an RPN environment more readily facilitates this kind of calculation scenario.

I'd also add that the ability to show multiple stack entries simultaneously provides great benefit to this type of use. I've never had much need for plotting functions, but the added real estate for showing more of the stack is what I miss the most when I pick up one of my "only X displayed" units.

[David Hayden]

I read somewhere (probably here) an interesting thread where some people did real-world races between AOS and RPN calculators keying in various formulas presented in textbook format. Then RPN calculators won, but not because RPN required significantly fewer keystrokes. The biggest factor was the RPN user was able to start keying in the solution almost immediately. The AOS user had to pause for a moment to figure out how to enter the expression.

I've always found RPN a much more natural way to key in an expression. But of course it's much harder to read RPN in a program. So in that sense it's sort of a "write only" language: easy to write and hard to read.

When I was in school, the killer combination for me was my 41C and my printer. When doing school work, I used the printer so I could easily double-check my work. It really stinks to lose points on a problem set because you hit the wrong calculator key.

[Gene]

(12-04-2017 10:13 PM)David Hayden Wrote:  I read somewhere (probably here) an interesting thread where some people did real-world races between AOS and RPN calculators keying in various formulas presented in textbook format. Then RPN calculators won, but not because RPN required significantly fewer keystrokes. The biggest factor was the RPN user was able to start keying in the solution almost immediately. The AOS user had to pause for a moment to figure out how to enter the expression.

Gene: The interesting test would be a situation where the RPN user makes mistakes in a complex problem and has to backtrack or correct with LastX, etc. vs. a formula algebraic machine with a mistake where the formula was simply edited and corrected.

I do know that college studies were made in the late 1970s that indicated for AOS style machines (non-formula approach), RPN was about 10-15% fewer keystrokes per problem. That saves time only if there is not a lot of thinking about how to approach steps in a problem, of course.

[pier4r]

So recap (for my perspective)

RPN:
- likely easier: to develop parsers for the calculator because the human does most of the work.
- possibly easier: to control if the typing went awry and one has to redo the computations done until then. (here a sort of history of what one typed won't be bad. Aside from the short one present on the 50g)
- likely easier: to match the RPN procedure with how we would proceed to compute a formula in our brain.
- likely: it forces you to think about the formula and elaborate it, instead of brainlessly type in the calc. (this may be a unwanted overhead sometimes)
- possible advantage (weak?): saves some keystrokes most of the time.
- likely easier: explore formulas and computation instead of copying them from paper/textbook.

algebraic:
- likely harder: if one cannot see the formula typed up to that point, it can be very frustrating if one makes a typo or has a doubt about a typo. Type everything again, no chances to inspect the formula mid course.
- likely easier: if one can see the formula that is typing. Since we are used to the algebraic notation.
- likely easier: to fix a formula if one can edit the formula that is typing.
- likely easier: if one can recall previous computations in form of algebraic entries.



As personal experience I generated randomly a formula (assuming no semplification).

\[ \frac{57^{6}}{22 \cdot 24} - \sqrt{ 53+81 } - \frac{ 25 - 7 \cdot \sqrt{92 \cdot 82} }{4^{2} \cdot 13 \cdot 81 } \]


and then I used:
free42 (rpn)
ti 34 (algebraic with no formula editing)
sharp el 506w (algebraic with formula editing and history)

with free42 those were 30 keystrokes. Counting numbers as 1, operations as 1, change of sign as 1.
with the ti34 and the sharp I used 40 keystrokes or slightly more.

The 'worst' feeling was on the ti34, because I was always in doubt whether I typed correctly the entries or if I missed the parentheses. Quite frustrating. I typed the formula actually three times to be sure of the result. (I did not type it on other systems before)

The free42 worked in one go. I did it again and I pressed a wrong function, and there was no undo (not that I know at least). That was frustrating.

The easier one, in terms of confidence or frustration level, was the 506w with the possibility to review the formula. Although the 506w gets ugly when one has long nested parentheses like (25-7* sqrt(92*82)) or long parentheses between operators; such as numerator/denominator of the last term of the formula.

Assuming that one value in the formula has to change (for whatever reason), with the free42 and the ti34 I need to retype everything again.

With the 506w it is just "up" to recall the last formula, editing the wanted part, and that's it.

That confirms my (biased?) view, that in terms of frustration having the ability to review and edit a formula is a big deal.

[Gene]

Good summary.

If you have a formula you need to evaluate more than once, then a formula algebraic is very good.

Or a program on an RPN machine, but that adds some time to the computations.


I tend to do more ad-hoc, less repetitive types of calculations so I prefer RPN as my scratch pad.

Others may have different situations and therefore benefit differently.

Ideally? I want a machine where I can do it all as needed. Which works best for that?

[ttw]

Over the last few years after the HP45 came out, I taught lots of calculator classes, programming classes, (and lots of other stuff.) My experience is that the RPN or relatives takes about 1/2 the keystrokes of an equivalent algebraic expression. Most of my students "got" RPN quickly after I pointed out that RPN closely follows the way one evaluates an expression on with pencil and paper. (Not so much the way one writes and expression but the way one evaluates one.)

[pier4r]

(12-05-2017 11:35 PM)Gene Wrote:  Ideally? I want a machine where I can do it all as needed. Which works best for that?

Someone pointed out that the 35s has both modes.

Otherwise 48 series or 50 series ?

[franz.b]

(12-06-2017 06:49 AM)pier4r Wrote:  

(12-05-2017 11:35 PM)Gene Wrote:  Ideally? I want a machine where I can do it all as needed. Which works best for that?

Someone pointed out that the 35s has both modes.

Otherwise 48 series or 50 series ?

I was going to write the same thing

[jebem]

(12-06-2017 07:17 AM)franz.b Wrote:  

(12-06-2017 06:49 AM)pier4r Wrote:  Someone pointed out that the 35s has both modes.
Otherwise 48 series or 50 series ?

I was going to write the same thing

From my collection of machines, here are some of them able to do both input operation modes, besides the already mentioned 48/49/50 series or the 35S model:
- HP 33S
- HP 20B
- HP 30B
- HP 17BII
- HP 17BII+
- HP 19BII
- HP 12C Platinum

[pier4r]

I am really thinking to buy the 35s, but my budget should wait for the next Christmas.

Do the 35s get also firmware fixes (I mean, from production batch to production batch) or the so disdained bugs are always there, unchecked ?

Because if it gets firmware fixes, the newer the batch, the better.

[Massimo Gnerucci]

(12-06-2017 10:49 AM)pier4r Wrote:  I am really thinking to buy the 35s, but my budget should wait for the next Christmas.

Do the 35s get also firmware fixes (I mean, from production batch to production batch) or the so disdained bugs are always there, unchecked ?

AFAIK, no fixes applied.

(12-06-2017 10:49 AM)pier4r Wrote:  Because if it gets firmware fixes, the older the batch, the better.

Shouldn't it be the newer, the better?

[pier4r]

true. My brain went backwards.
Thanks for the info about the 35s.

Anyway that is a good input for a question in another thread.

[Nigel (UK)]

On the subject of RPN versus equation entry logic, I'd just like to mention the Acron RPN calculator app, available for Android and IOS. This is an RPN entry calculator that builds up a stack showing both the number in each level and the algebraic expression leading to that number. (See the link above for some screenshots.)

This combines the advantages of RPN entry (if you agree that there are any!) with the ability to view complete expressions and to correct errors in them that equation entry calculators have. I really like it.

Nigel (UK)

(no connection with the author of this program)