The Museum of HP Calculators

HP Forum Archive 06

[ Return to Index | Top of Index ]

ACO has gone: a new chalenge?
Message #1 Posted by Vieira, Luiz C (Brazil) on 4 Nov 2001, 8:37 p.m.

Well, well, well...

ACO (Advanced Calculators O...? I don't remember; would anybody please?) is gone, but I still believe RPN calculators will prevail, even if offered by another brand. I am aware of lowering quality, lack in support and other possible consequences, but as Hewlett-Packard itself will no longer support us with their calcs, welcome you who takes the place. If anyone will.

I hope we have some good news from Jean-Ayves Avenard and Gerald Squelart's new post offices, as we are told about it. Hope is a feeling that is still allowed, isn't it?

Good luck to us all.

(I hope you in USA and Europe do not waste the chance buying spare calcs; they are somewhat expensive and rare in this part of the planet)

      
Re: ACO has gone: a new chalenge?
Message #2 Posted by iqbal on 5 Nov 2001, 5:05 a.m.,
in response to message #1 by Vieira, Luiz C (Brazil)

ACO - Australian Calculator Operations.

      
Re: ACO has gone: a new chalenge?
Message #3 Posted by Marx Pio on 5 Nov 2001, 4:07 p.m.,
in response to message #1 by Vieira, Luiz C (Brazil)

Luiz,

IMHO, the RPN are just for few

I went to a shopping in order to check out some prices of HP's and I saw a man "fighting" with a HP12C trying to make a simple sum in RPN, neither the seller nor the man could do nothing, I feel like a genius watching them but kept my mouth closed ...wanna know what he did? He bought a CASIO for his son

Cheers.

Marx Pio

            
Re: ACO has gone: a new chalenge?
Message #4 Posted by Vieira, Luiz C. (Brazil) on 5 Nov 2001, 5:44 p.m.,
in response to message #3 by Marx Pio

I know, I know... but it happened now-a-days, didn´t it?

Once upon a time, people used to think that RPN was a chalenge. Now it´s kind of upheaval. No one wants to take a time to work on it.

Please, help! I cannot understand. Is it just a matter of choice? Is RPN so hard to understand that people do not care about it anymore? Have I been wrong all this time about?

I don´t really understand why did RPN is being plugged out this easy.

                  
RPN: a new (old) challenge?
Message #5 Posted by Cameron on 6 Nov 2001, 8:49 a.m.,
in response to message #4 by Vieira, Luiz C. (Brazil)

I'm sure this particular flame war has been fought before. But since I'm a newbie (here) I'll pour some kerosene on the floor. I'm sure someone else will have the matches.

Since we're taught infix notation in primary school, algebraic calculators have a more user-friendly interface. As with most man-machine interfaces, the best results are often symbiotic in nature. However this is at odds with the instant-gratification world we've built for ourselves. It should not be surprising that the Casio won the day.

On a different tack, we're a bunch of people who like to rise to an intellectual challenge. And we all get a smug sense of satisfaction from having mastered the arcana of RPN. However, my Mum can pick up an algebraic four-banger and check her grocery bill without reading a manual--or even thinking about the *process*. The tool is genuinely transparent (Mum's 70 with no background in mathematics, science or engineering. i.e. she's typical of most people who might use a calculator once in a while).

I believe that the only reason HP opted for RPN is that by doing so they were able to keep the interpreters in the 70's and 80's calculators simple. By offloading that work to the human wet-ware, they could squeeze more serious computational stuff into the calculator. Once processors and memory hit some capacity/price point, it all became irrelevant. However, by that time, two generations of professionals had learned to think postfix, so the RPN machines endured.

RPN is still extremely popular in some quarters. That PDF you read last week and the document you'll print tomorrow still use RPN to shuffle the dots around. I wonder how much subtle influence HP had on the inception of Postscript (and other postfix machine languages).

Cameron

                        
Re: RPN: a new (old) challenge?
Message #6 Posted by Vieira, Luiz C. (Brazil) on 6 Nov 2001, 9:56 a.m.,
in response to message #5 by Cameron

Cameron wrote:

"I'm sure this particular flame war has been fought before. But since I'm a newbie (here) I'll pour some kerosene on the floor. I'm sure someone else will have the matches."

Welcome you all who intend keeping this flame alive but for a war.

"Since we're taught infix notation in primary school, algebraic calculators have a more user-friendly interface. (...)"

Yes, oh yes. My knowledge in Math (as in many like me) began like this, too. And I would not be able to understand math if it (my knowledge) was not grown that way. Unless I am one of Lukasiewicz´ pupils. If we take the most common example that HewPack itself have been using since its first RPN models, the algebraic system is a notation and does not express the real operations involved when achieving a result. When one writes down the numbers on paper the first operand, (ENTER) the second and then deciding which operation to perform, RPN gets closer to the actual job. Now to Cameron (and others this situation): as a man of software, do you reason better in a LIFO stack structure or in a linear algebraic noted structure?

"On a different tack, we're a bunch of people who like to rise to an intellectual challenge.(...)" Maybe that´s the real point I myself did not figure out in a previous post about HewPack cult (http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/forum.cgi?read=11749). Good challenges are those that lead us to improvement, new solutions, even new challenges with practical application. If RPN is no longer available, challenges will be worthless, as new solutions will have no practical application. (would you allow me, please, with much respect, to send a big kiss and a hug to Mum? Mine is 68 yo...)

"I believe that the only reason HP opted for RPN is that by doing so they were able to keep the interpreters in the 70's and 80's calculators simple." Shorter O.S., yes. "Once processors and memory hit some capacity/price point, it all became irrelevant." I don't get to the point in here. I would agree this is more commercial than technological. Please, correct me if I am wrong: processors tend to be more powerful as technology allows to. But even the topmost (commercially) available do not offer high-level programmability, only low-level machine code. Just take RISC as example. And technology allows them having internal high-level interpreters. Why not? maybe the big question is: which high-level structure should we use that would satisfy all (at least most) programmers? Builders for OS development in many platforms exist and they can be updated anytime. Customizing a low-level resource is easier than a high-level one. And I believe understanding RPN as a new, unknown tool is somewhat easier than understanding algebraic notation as new, unknown tool. I needed some classes in basic school with a teacher for algebraic notation, but using RPN took me some hours reading the owner's manual by myself.

"(...) That PDF you read last week and the document you'll print tomorrow still use RPN to shuffle the dots around. I wonder how much subtle influence HP had on the inception of Postscript (and other postfix machine languages)" See? That I wasn't known about. I believe much will be written, much will happen. And, for this specific matter, I am not sure "time will tell". It seems it's already told, and many (as I) are not ready to hear. Or accept. (sob!)

Thanks, Cameron. Good words.

                        
Re: RPN: a new (old) challenge?
Message #7 Posted by Ex-PPC member on 6 Nov 2001, 11:03 a.m.,
in response to message #5 by Cameron

There's also the fact that to evaluate a typical algebraic-notation expression (say: 5*(3+2)/(8-7)), all interpreters and compilers I know have to convert it internally to a form of RPN, because that's the only way the expression can be evaluated, i.e: whether you like it or not, the only way you can have 5 times 4 is to have the 5 inside the processor (5), then the 4 (4), then your processor or software performs the multiplication (*). There's no way you can have the 5 (5), then have the processor or software perform the multiplication (*), then make available the 4 to it (4).

I once wrote a BASIC interpreter. To compute algrebraic expressions, I had to resort to parsing the expression, putting the operands and operations in a stack (to cater for different priorities and parentheses), then evaluated the different simple subexpressions RPN-like.

An even better example of this being the actual case, even industrially, can be found in the Sharp PC-1211 (a contemporary of the hP-41C in the 80's) User Manual. That was a neat, smart handheld machine programmable in BASIC, and on page nn they would explain you how a large, complex algebraic expression was evaluated by the BASIC interpreter in that machine: they used two stacks, one for numbers, the other for parentheses and operations, and both would be emptied in RPN-fashion.

I do not know for sure, but I think that it's quite probable that the TI algebraic machines did calculations internally likewise.

When used not by compilers or internal software but by persons, RPN has the important advantage that it lets you see all intermediate results at all stages of the calculation. The typical algebraic machine will let you see just the final result, so you'll have no chance to detect if something was wrong in mid-process.

The only exception to that was the HP-71B Calc Mode, which would show you all intermediate results when computing any algebraic expression, in real time, and would let you go backwards a step at a time, recovering, say, 5*4 from a backstep of 20, for you to try another number or operation instead.

                              
Re: RPN: a new (old) challenge?
Message #8 Posted by Cameron on 6 Nov 2001, 5:03 p.m.,
in response to message #7 by Ex-PPC member

There's also the fact that to evaluate a typical algebraic-notation expression (say: 5*(3+2)/(8-7)), all interpreters and compilers I know have to convert it internally to a form of RPN

That was my poorly-expressed point about the simpler interpreter. HP offloaded the fiddly bits to the end user and as a side-effect created a less intuitive but more powerful calculating paradigm.

Cameron

                                    
Re: RPN: a new (old) challenge?
Message #9 Posted by Fred Lusk (CA) on 6 Nov 2001, 10:35 p.m.,
in response to message #8 by Cameron

Cameron....

I disagree that RPN is LESS intuitive. I learned to speak calculator in 1973, when I was 14. I had simultaneous availability of my geometry teacher's 5-banger algebraic and my dad's brand new HP-35. I picked up RPN much faster and made less mistakes. Why? Because it works like math is actually done....whether by hand, on a slide rule, or looking up logs and trigs in a book of tables. It's much easlier for the mind to deal with a 4-register stack (of which only X and Y are really important) than keep track of multiple parenthesis, even with an equation editor. I deal with the closing parenthesis hassle all the time with Excel and Mathcad. The real beauty of RPN, which I just alluded to, it that you really only work with one or two numbers at a time....no more. Consequently, I salute the genius who headed the HP-42S design team, and gave me a two-line display.

                                          
Re: RPN: a new (old) challenge?
Message #10 Posted by Cameron on 7 Nov 2001, 8:27 a.m.,
in response to message #9 by Fred Lusk (CA)

Fred, I'm not actually arguing the contrary case--I'm merely speculating why some/many/most people seem to prefer algebraics these days. I myself didn't see an HP calculator until I was out working in the IT biz. When I did finally encounter one, I grasped its principles almost immediately and, as they say, couldn't get the money out of my pocket fast enough.

Your analysis (and that of other contributors to this thread) is spot on. However, the fact remains that the popularity of RPN has dwindled through the 90's to the point where David's site has more information than the manufacturer's and HP have all but ceased production of RPN machines.

I've made the point before that within a 6 metre radius of my desk there are three 40-something guys with HPs (self included). The other 6 in our "group", all in their late 20's/early 30's, regard them as quaint museum pieces and invariably eschew them for the windows calculator applet. To be fair, we're not particle physicists or structural engineers--just a typical IT shop. However the age division of the "haves" and "havenots" seems to be consistent with the decline in enthusiasm for RPN.

All this leaves me wondering, "Why is that?"

Cameron

                                                
Re: RPN: a new (old) challenge?
Message #11 Posted by Fred Lusk (CA) on 11 Nov 2001, 12:51 a.m.,
in response to message #10 by Cameron

Cameron....

Could it be that everyone younger than us is just plain stupid!!!

Actually, those of us who grew up on RPN and watched, even participated, in the evolution of the scientific calculator seem to have a far greater appreciation for RPN's true worth, and the value of a well-built HP.

I started with the now primitive HP-35, then moved to an HP-55, an HP-34C, an HP-41CV & -41CX, and finally an HP-42S (oh....I also have an HP-48G+, but I find it less productive as an on-the-fly number cruncher than I do the 41 or 42). I know what it's like to have only one data storage register, or only 49 unmerged key strokes (can anyone say "tight code"). These machines WERE my computers through high school, college, and today in my career. Of course, I use a PC today, and now I use it much more than my calculators. But the computer, for all its power, still pales in comparison to the elegence and usability of the RPN scientific calculator from Hewlett-Packard.

I'm all in favor of progress, but I firmly believe that there is still a market for a well-built RPN scientific calculator. I would be willing to pay several hundred dollars for a machine that follows the HP-41CX/-42S line. I don't need a graphing calculator or symbolic math. I need every feature in the -41CX plus evey feature in the -42S, plus units, plus 128k ram. And I want my old keystroke programming back.

HP do you here me??? Sorry for the rant, but my astonomy club's star party was rained out tonight and there's nothing good on TV.

Fred

                        
Algebraic calculators are NOT always easy to use
Message #12 Posted by Gene on 6 Nov 2001, 11:17 a.m.,
in response to message #5 by Cameron

Try picking up a run of the mill algebraic and solve

1 + 2 x 3 = ?

You'll probably get a 9, which is incorrect. So if your Mom has to mix +/- with multiplication and division, beware!

Even HP did this stupid thing with the HP-10B. It's a horrible abdication of the primary rules of hierarchy that we are all taught in middle school.

Just because it is a business calculator is NO excuse. Shame on the designers.

                              
Re: Algebraic calculators are NOT always easy to use
Message #13 Posted by Matt Kernal on 7 Nov 2001, 9:19 p.m.,
in response to message #12 by Gene

Yes, it is a shame. All of HP's algebraic (and those set to algebraic mode) financial calculators ignore precedence. Granted, I have not tested the 10BII yet.

Jean-Yves Avenard pointed out in a thread at comp.sys.hp48 (search for: "[49] Is this right? Order of Operations Question") that it is an industry standard for financial calcs to operate on the premise of "the priority are from left to right". Yet, algebraic scientifics' do follow order-of-operation rules.

Matt

                                    
At least the TI BAII Plus calculator allows a choice...
Message #14 Posted by Gene on 8 Nov 2001, 10:40 a.m.,
in response to message #13 by Matt Kernal

The TI BAII Plus is a very good budget business calculator. For about $30, you get

All the normal business functions (TVM, cash flow, statistics, etc.).

Scientific functions too (Trigs, logs)

But...you also get a choice between using Chain (aka HP business calculator logic) or AOS - allowing 1 + 2 x 3 to equal 9 as it should.

Sadly, it appears our university will be moving next year to the BAII Plus as the recommended calculator.

Sadly, too, I think I agree with them. Gene

                                          
Re: At least the TI BAII Plus calculator allows a choice...
Message #15 Posted by Ron Ross on 8 Nov 2001, 11:17 a.m.,
in response to message #14 by Gene

Gene, All other Ti, Casio and Sharp business calculators use no precidence for their business calculators. It is an industry standard that a business calculator does not use precidence (for some moronic reason no doubt). That is why I do not really care for any Hp business calc if it cannot be switched into an RPN Mode (ie the 19Bii, has scientific functions but no precidence for normal algebraic input, but luckily the solver does use precidence, I believe).

                                                
Quite True, Ross
Message #16 Posted by Gene on 9 Nov 2001, 9:44 a.m.,
in response to message #15 by Ron Ross

You're correct.

That's one of the good reasons to prefer the BAII Plus, despite the horrible keys, etc.

Having a hierarchy really cuts down on parentheses.

Of course, RPN cuts down on them too. :-) Gene

                                          
No way!
Message #17 Posted by Cameron on 9 Nov 2001, 7:11 p.m.,
in response to message #14 by Gene

Every C programmer knows 1 + 2 * 3 == 7 ;-)

You mentioned this earlier Gene. I read it, smirked, and missed the ramification. If I understand you correctly, 1 + 2 * 3 *should* evaluate to 9--which implies a strict L-R grammar. It also implies that 3 * 2 + 1 == 7 holds on the same device. If my understanding is correct, that's an ugly gotcha. Is that Ron's point about precedence in the post that follows yours? (Ron?)

Forging ahead, I grabbed my old Casio algebraic and found it evaluated to 7 with the terms arranged in both orders. From this I conclude that it uses a stack-like mechanism so that it can evaluate the subexpressions. I then asked myself why this had never occurred to me before. I can only conclude that since my Casio obeys the C/C++ order-of-evaluation rules, it's never occurred to me that some devices don't.

Testing my theory on the Casio, 4 * 5 + 1 + 2 * 3 == 2 * 3 + 1 + 4 * 5 == 27. As it should from my POV.

So, enlighten me. For how many algebraics does this not hold true.

Cameron (the calculator neophyte)

                                                
Re: No way!
Message #18 Posted by Matt Kernal on 10 Nov 2001, 10:22 a.m.,
in response to message #17 by Cameron

I might be wrong, but I'll take a shot and guess your Casio is a scientific model. I'd be surprised to hear that it's a business model, because, as we've been saying, most business calcs don't know order-of-operations (with the exception of the TI that Gene mentioned, which is selectable).

Matt

                                                
Re: No way!
Message #19 Posted by doug on 15 Nov 2001, 4:05 a.m.,
in response to message #17 by Cameron

My HP71B agrees. 4 * 5 + 1 + 2 * 3 = 27

and

2 * 3 + 1 + 4 * 5 = 27

or

3 * 2 + 1 + 5 * 4 = 27

doug

                                          
Re: At least the TI BAII Plus calculator allows a choice...
Message #20 Posted by doug on 15 Nov 2001, 3:58 a.m.,
in response to message #14 by Gene

Gene, I had a talk with my HP71B a number of times. I can't seem to get it to agree with 1+2*3=9. In BASIC or CALC mode it seems to believe that 1+2*3=7. doug

                                                
No! You guys misunderstand! 1+2x3 should = 7!
Message #21 Posted by Gene on 15 Nov 2001, 1:45 p.m.,
in response to message #20 by doug

Unfortunately, many/most HP business calcs (and other makes) equate it to 9.

It should be equal to 7.

The BAII Plus allows one to turn on precedence (AOS) and it works as it should.

HP's business calcs are ugly in this respect. Gene

                        
Re: RPN: a new (old) challenge?
Message #22 Posted by Ernie Malaga on 6 Nov 2001, 12:09 p.m.,
in response to message #5 by Cameron

Although I've used HP calculators since 1976 and have always preferred RPN over algebraic, I drew the line when HP introduced the 28C and its unlimited stack and RPN-for-everything mindset. About a year ago I bought a 49G, which I found excruciatingly difficult to use, and traded it for an old, reliable 41CX.

My point is that HP has taken RPN too far; saying "1 ENTER 2 +" is useful, but "IF a b >" isn't. And certainly, "25 'XYZ' STO" is downright stupid -- at least in my opinion.

RPN does represent a deviation from what we're taught since first grade. My father, who is no moron but is 80 years old, has never fully understood (let alone, liked) RPN calculators, although I've been trying to teach him the basics for the past 25 years.

Perhaps I'm cynical, but in my opinion, any tool that does the job is a useful and good tool. And that's what calculators are -- mere tools. Whether you use RPN or algebraic logic, that's entirely up to each one of you, provided you understand the mechanics and can arrive to the right answers. Me, I'll stick to the 41CX, which is the calculator I've felt the most comfortable with.

Comments, please.

                              
Re: Comments about RPN/RPL to Ernie
Message #23 Posted by Vieira, Luiz C. (Brazil) on 6 Nov 2001, 2:15 p.m.,
in response to message #22 by Ernie Malaga

Hello!

As a first impression, I must say that I had the same feeling of having to write

IF
obj
obj
relationship operator
THEN commands
ELSE commands
END
instead of (seemed easier way)
operand
operand
relationship operator
GTO nn
commands
GTO mm
LBL nn
commands
LBL mm
That sounded as more typing, more memory, more processing time, etc. Latter I paid the price: structured programming. IF THEN ELSE END, variables instead of registers, directories, menus and (48/49) RS232-like comms made me think better about it. Now I can program either RPL or RPN (also TCL/TK, C++, Assembly). I translate (or create equivalent) programs from each system to the other, even if it takes some amount of time. It´s brain activity I believe that puts my neurons up and working.

Ernie wrote:

"My father, who is no moron but is 80 years old, has never fully understood (let alone, liked) RPN calculators, although I've been trying to teach him the basics for the past 25 years." A lot of youngers tried too, and not understanding it does not mean a lack of ability. I only believe those who understand RPN/RPL can easier understand processors' inner operations. I said EASIER, meaning it can be understood anyway.

"Perhaps I'm cynical, but in my opinion, any tool that does the job is a useful and good tool. And that's what calculators are -- mere tools. Whether you use RPN or algebraic logic, that's entirely up to each one of you, provided you understand the mechanics and can arrive to the right answers.(..)" I cannot agree more! I believe you are completely right! No words against that. But we should always consider that as you, and I, and many others, some new students deserve having the chance we had of using such a remarkable math instrument that is Polish Notation and its reverse counterpart. I feel as it’s been hidden from me all those years when I was shown only algebraic notation...

Cheers.

                                    
Re: Comments about RPN/RPL to Ernie
Message #24 Posted by Ernie Malaga on 6 Nov 2001, 5:38 p.m.,
in response to message #23 by Vieira, Luiz C. (Brazil)

>That sounded as more typing, more memory, more processing >time, etc. Latter I paid the price: structured programming. IF >THEN ELSE END, variables instead of registers, directories, >menus and (48/49) RS232-like comms made me think better >about it.

Oh, that part I do like. It's the mere inversion of the operands I'm not so crazy about. It makes the program more difficult to write -- and considerably more difficult to debug. After all, you can have all the structured programming you want without losing infix notation, as Pascal, C, COBOL, RPG, PL/I, BASIC, and countless other languages have proven.

Later, -EM

                              
Re: RPN: a new (old) challenge?
Message #25 Posted by Rupert (Northern Italy, EU) on 6 Nov 2001, 5:03 p.m.,
in response to message #22 by Ernie Malaga

>My point is that HP has taken RPN too far; >saying "1 ENTER 2 +" is useful, >but "IF a b >" isn't.

The HP48 allows to write tests in algebraic form too, as well as the expressions: IF 'a>b' etc. With my HP48G+ sometimes I use the algebraic form because it's more readable. Once debugged, I translate all into RPL for the program to run faster.

>Me, I'll stick to the 41CX, which is the calculator >I've felt the most comfortable with.

It is one of the best HP calcs, along with the HP15C (I own both since the eighties).

> Comments, please.

I agree that the HP49G doesn't seem designed for serious users. Get a HP48. You'll like it. Just my 0.02 EUR. :-)

Regards.

                                    
Re: RPN: a new (old) challenge?
Message #26 Posted by Ernie Malaga on 6 Nov 2001, 5:44 p.m.,
in response to message #25 by Rupert (Northern Italy, EU)

>The HP48 allows to write tests in algebraic form too, as well as >the expressions: IF 'a>b' etc. With my HP48G+ sometimes I use >the algebraic form because it's more readable. Once debugged, I >translate all into RPL for the program to run faster.

I have a feeling that these features are not properly documented. I've had a 48GX before (I gave it away as a present), and I remember being disappointed by the lack of documentation to explain the beast. Later, when I went for a 49G, the problem was even worse.

In any case, it seems odd that a RPN-only calculator brand (HP) had to borrow algebraic logic to stay afloat, but _no_ algebraic-only calculator brand (such as TI) did the opposite.

Please don't mistake me: RPN is a nicer operating logic. But the industry always goes with what the public wants, and those wants ring loud and clear in the cash registers around the globe.

Later, -EM

                                          
Re: RPN: a new (old) challenge?
Message #27 Posted by Rupert (Northern Italy, EU) on 8 Nov 2001, 4:55 p.m.,
in response to message #26 by Ernie Malaga

>I have a feeling that these features are not properly documented. >I've had a 48GX before (I gave it away as a present), and I remember >being disappointed by the lack of documentation to explain the beast. >Later, when I went for a 49G, the problem was even worse.

That's true. The HP48 User Guide just explains how to use the built-in functions with menus and input forms. That's why the Advanced User's Reference Manual is needed, too.

Beyond that, it is almost mandatory to get the tutorials available from the HP Knowledge Base (http://cgi-bin.spaceports.com/~hpkb/), http://www.hpcalc.org, and http://www.area48.com, at least. I found very useful also to search the comp.sys.hp48 ng database for programming related topics, even the simplest.

Regards.

                              
Re: RPN: a new (old) challenge?
Message #28 Posted by Tony Duell (UK) on 6 Nov 2001, 7:14 p.m.,
in response to message #22 by Ernie Malaga

I've used (and still use) both types of machine -- 67s and 41s as 'traditional' RPN machines and 48s/49s as RPL machines. I have to say that I find RPL to be a lot more consistant and logical thant the older type. STO is a particular example. On the 41 you have things like STO 02, with the address as part of the instruction. If you want indirect addressing, then you have a different instruction STO IND 02. Now, if the stack was large enough (and 4 levels isn't really large enough) then I'd prefer it if the STO operator took the address (register number) from the top of the stack (and removed it), storing the second level of the stack into that register, and moving the stack down one level. Then things like STO 02 would become 2 STO (the STO would remove the 2 from the stack, moving everything else down 1 level). STO IND 02 would be 2 RCL STO (think about it), and so on. You cound indirect as many times as you liked, calculate addresses 'on the fly' and so on. In fact if I ever design an RPN calculator, this is one thing I would _certainly_ change.

                        
Re: RPN: a new (old) challenge?
Message #29 Posted by Tony Duell (UK) on 6 Nov 2001, 7:07 p.m.,
in response to message #5 by Cameron

I think you're equating 'user friendly' with 'easy to learn' rather than with 'easy to use'. They are not always equivalent!. Algebraic calculators seem to be typical of a lot of modern software tools. They make easy jobs trivial and difficult jobs next-to-impossible. While RPN machines take a little extra learning but they then make difficult jobs a lot easier. Now I generally use computers and calculators to solve difficult problems. Easy problems I can solve by hand. And if I am going to use a tool a lot (a physical tool or a piece of software), then I don't mind spending a few hours/days/mnths learning to use it properly. I know I'll benefit in the end. It took me an afternoon to learn RPN. And I'm darn glad I did. I've saved that time many times over. And because I've been able to see all the intermediate results, I've produced many fewer nonsensical results. I am deffinately an RPN addict....

                              
Re: RPN: a new (old) challenge?
Message #30 Posted by Luca de Alfaro on 6 Nov 2001, 9:48 p.m.,
in response to message #29 by Tony Duell (UK)

I think each of RPN/algebraic has its own advantages. I love RPN for quick calculations. After computing that the processing time is 6.43 ms, if you know that you have to do that 128 times, you simply type '128' 'x'. I find this incredibly more intuitive than 'x' '128' '=' not to mention shorter. Moreover, the stack gives you some scratchpad memory for free that is very useful.

On the negative side, when you start to write real programs, a _good_ algebraic mode is much better. Some time ago I was reading someone's code to convert a number to a fraction. The RPN was next to incomprehensible, but once written out in algebraic form, the loop was updating variables with something like (I am making this up, but it looked similar):

d1 := ip(n/d1) + d2 * frac(n) d2 := d1 n := 1 / (n - d1 * d2)

The point is that seeing it in algebraic notation actually made it comprehensible. I find reading other people's RPN programs always a bit hard, especially when arbitrary operator and operand types can be on the stack (not to mention those nifty ->OBJ -type operators of the HP48 that you never know what they do and how many arguments they leave). I essentially have to simulate the stack on paper or in my brain to figure out what is going on.

During my university time, I had a CASIO fx-4000 calculator. You could type a long expression, like

(4 + 3 * 12) / (5 + 6.5 * B - 8 * A)

where A, B are registers, and then press EXE to get the result. After that, you could press <= (back arrow), and you got the expression back. You could then go back, move on the expression with cursor keys, change (for example) the 6.5 into a 7.24, and re-evaluate the expression. I remember this was incredibly handy for computing different values of a function. For instance, I was using it to compute the polarization of transistors, and see how that would change by inserting different resistors. In RPN, there is no quick way to get that effect; you would need to write a program (and the HP 48 is so incredibly slow that editing an 'expression' takes quite a while).

Now I don't work on large expressions any more; I mostly "play with numbers" to evaluate simple hypotheses, and I love RPN. But maybe it was good that I was solving electronic circuits in algebraic notation, and that I bought a lowly CASIO rather than a better, but slower to use, HP.

Luca

                                    
Re: RPN: a new (old) challenge?
Message #31 Posted by Ernie Malaga on 7 Nov 2001, 1:33 a.m.,
in response to message #30 by Luca de Alfaro

You said:

<i>Some time ago I was reading someone's code to convert a number to a fraction. The RPN was next to incomprehensible, but once written out in algebraic form, the loop was updating variables with something like (I am making this up, but it looked similar):</i>

Yes. That happens because RPN is a good number-crunching logic, but it's not expressive. And we humans need expressions to clarify the meaning of algorithms. In short, I feel that manual calculations are easier in RPN, but programming is one helluva lot easier in any algebraic system.

-EM

                        
Re: RPN: a new (old) challenge?
Message #32 Posted by John Mosand (Norway) on 7 Nov 2001, 7:25 a.m.,
in response to message #5 by Cameron

I've been reading this thread with interest. There is one thing that puzzles me: Some have said that they learned RPN "in only a few hours" or "in an evening". I don't think that I am especially intelligent, but I can remember that when I bought my first HP many years ago, it took me only about a minute to grasp the simple idea - enter two inputs and then apply an operator, not to say the elegance in executing chained calculations. Explaining it to curious friends, they also seem to get it right away and go on intuitively from there. BTW There is a cute little paperback: ENTER, by J. Daniel Dodin. Publ. Synthetix. 146 pp. ISBN 0-9612174-2-1. Copyright 1984. An excellent introduction, plus many tips and tricks.

                              
Re: RPN: a new (old) challenge?
Message #33 Posted by Tony Duell (UK) on 7 Nov 2001, 3:49 p.m.,
in response to message #32 by John Mosand (Norway)

When I say it took me an afternoon to learn RPN, perhaps I should qualify that a little. It took me about 2 minutes to learn to do simple operations (as in 'type in the first number, ENTER, type in the second number, press the operation'). It took me an afternoon to be able to do chain calculations without thinking and without having to check things in the manual.

                                    
Re: RPN: a new (old) challenge? - learning time
Message #34 Posted by Vieira, Luiz C. (Brazil) on 7 Nov 2001, 9:10 p.m.,
in response to message #33 by Tony Duell (UK)

Hello;

I must confess!

My first language was Fortran (at the University, to be an Engineer).

The second was a TI57's programming language.

And the third was FOSPIC (Forty-One's Set of Programmable Instruction Code; reminds Forty One's Speak, doesn't it? I would try this mnemonics when HP Key Notes asked for a name to the 41's programmable language... the contest expired at the time I thought about it).

For me, the hardest part was the bbbbb.eeeii code for ISG and DSE. I could not help myself pushing it into my neural cells... Well, at the time it worked first (about dozens of tryouts) I felt amazed! The last feature described in the basic manual. Later I tried some MRG, SKPCOL, SKPCHR (I have a Manuel d'utilisation de l'Imprimante HP82143A, et il est écrit en Francais), also a bit hard to get used to. But all effort worth the resulting knowledge.

Cheers.

                                          
Re: RPN: a new (old) challenge? - learning time
Message #35 Posted by Raymond Hellstern on 8 Nov 2001, 2:24 a.m.,
in response to message #34 by Vieira, Luiz C. (Brazil)

Hi,

as far as I know, it's called FOCAL;-)

Regards,

Raymond

                                                
Re: RPN: a new (old) challenge? - FOCAL!
Message #36 Posted by Vieira, Luiz C. (Brazil) on 8 Nov 2001, 3:55 a.m.,
in response to message #35 by Raymond Hellstern

Hello;

now that many have read my words (shame on me! I was, again, not known about), can anyone tell me what's the meaning of the mnemonics? What does FOCAL stand for? That's the first time I hear about it.

Thanks.

                                                      
Re: RPN: a new (old) challenge? - FOCAL!
Message #37 Posted by Ex-PPC member on 8 Nov 2001, 10:17 a.m.,
in response to message #36 by Vieira, Luiz C. (Brazil)

FOCAL stands for Forty One CAlculator Language.

                                                            
My submission to the "name contest for HP41"
Message #38 Posted by Andrés C. Rodríguez (Argentina) on 9 Nov 2001, 10:52 p.m.,
in response to message #37 by Ex-PPC member

It was EUREKA, because of the features that distinguish the HP41 at the time (not only its language)

.

E stands for "expandability" (peripherals)

U stands for "user mode keyboard"

R stands for "RPN"

E stands for "extendability" (after writing a program, you call it just as a built in function)

K stands for "keystroke programability", opposed to the Sharp and other BASIC models; try typing S I N ( 3 0 ) instead of pressing 3 0 [SIN]

A stands for "Alphanumeric"

.

Of course, the meaning of the two "E"s is conmutative :-)

And, BTW, about the algebraic question: While I am a stubborn and loyal "4-level RPN" fan, I may admit that the algebraic mode in some HPs (showing parenthesis until solved, or the rather innovative manners of the HP30S are not 100% unacceptable...

                                                                  
FOCAL... (name contest for HP 41 language in the '80s)
Message #39 Posted by Andrés C. Rodríguez (Argentina) on 10 Nov 2001, 9:35 a.m.,
in response to message #38 by Andrés C. Rodríguez (Argentina)

FOCAL (FOrmula CALculator), named in the style of FORTRAN (FORmula TRANslator), was a programming language in DEC (Digital Equipment Corp.) PDP-11 machines. We (students) built one of the smaller models (the DEC LSI-11 "computer kit" from Heathkit) at my university in 1978.

That particular machine had a 12 row, 40 column CRT text-only terminal, and booted its software from punched paper tape. One of the languages it supported was BASIC, but it took some 18 minutes to load, and since the CPU seemed very crash-prone (in a future installment I can tell the amazing hardware story behind those crashes), sometimes we resorted to FOCAL, a simpler interpreter, easier to load in the then 'impressive' 32 KByte memory.

FOCAL was similar to BASIC (classic BASIC, I mean), but without the appreciated GOSUB - RETURN construct. No problem for HP 25 followers then...

One rarity about FOCAL was the use of FRACTIONAL program line numbers, so if you need to insert a line between lines 1 and 2, you simply number the new line as 1.1 or something similar. An elegant solution to avoid insertion logic, or mandating numbering from 10 to 10, or a RENUMBER command. There could be almost (depending on REAL precision) infinite lines inserted between any other two lines...

I was sure the HP 41 deserved a new name for its features, not a recast of FOCAL. However, the fortune of the '80s sumbissions to the KeyNotes contest (including my EUREKA) are a complete mistery, at least for me.


[ Return to Index | Top of Index ]

Go back to the main exhibit hall