Thanks for the tip on the HP32 calculator!

I don't think it's confusing once you've learned it, and it has the added benefit of stack manipulation. You don't have to save interim results in memory, you can easily transpose results when needed, and certain operations seem more meaningful and logical. I've had quite a few HP calculators and TI's, I always liked the HP's.

Reply to
ATP
Loading thread data ...

Yep - I seem to find that the XY key seems to get a good deal of work on my calculators.

Jim

================================================== please reply to: JRR(zero) at yktvmv (dot) vnet (dot) ibm (dot) com ==================================================

Reply to
jim rozen

The advantage of using RPN is that you follow the same sequence of entering numbers as you would do it by hand. For instance to multiply the numbers

1234 and 5678 with pencil on paper you would first write down the first number. On the next line underneath you write the second number. Now you multiply (or add or subtract whatever) the two numbers. With RPN you do the same thing: First you key in the first number. To tell the calculator that the first number is complete you press enter and then key in the second number. Next you tell the calculator what you want to be done: If multiplication then press the x button, for addition you press the + key etc. Generally if you know how to solve the problem with pencil on paper you follow the same sequence on the RPN calculator. Persons presented with an lengthy and complicated equation and not knowing how to go about calculating the result on paper do prefer the AE calculators. Somehow they get an answer and belief that it is correct. However if you know how to calculate that by hand, then using an RPN calculator comes naturally and not only that, you 'know' that the calculation is correct. One guy who had left his RPN calculator at home and had borrowed an AE calculator said to me: " I repeated that calculation three times and I am still not confident that the answer is correct. Can I please borrow your RPN calculator to get the right answer" HTH
Reply to
John

Bob doesn't understand RPN or push / pop a stack commands of computers. RPN emulated the stack features and is a powerful tool for many advanced mathematic routines.

Mart> Greg sez:

Reply to
Martin H. Eastburn
[ ... ]

It depends on what you mean by "early". The 9200 and 9200B desktop machines (which is where I got my start programming HP calculators) were three levels of stack -- with real *core* memory, and a mag card reader/writer. All three levels of stack were visible at once on the tiny crt display. Since it had core memory, you could turn it off, and when you turned it back on, your program was still there, ready to run.

It also had a clamshell printer which fit on top of the case like a toupee, and it printed on an electro-sensitive paper (conductive aluminum foil, and it wrote by blasting through with electrostatic discharges that to the black background on the paper. As your printout extended, you were unfurling an antenna to broadcast your calculations to the world. :-)

So -- when I got my HP-45, I was already comfortable with RPN, and also with a slipstick.

Enjoy, DoN.

Reply to
DoN. Nichols

Wonder if the switches could be fixed with 'mo strips' - the thin silver filled cells in a sheet of rubber...

Martin

Reply to
Martin H. Eastburn

Well, when Jan Lukasiewicz invented polish notation in 1920, it wasn't to save memory. When Charles Hamblin adapted it for calculation by changing the operators from prefix to postfix, it was to save keystrokes, allow you to start anywhere in an equation, see each intermediate result, and have a reasonable confidence that you'd wind up with the correct final result.

As John noted, RPN works exactly the way you'd do the calculations with pencil and paper, so it is a natural and familiar way to work for people who are comfortable with doing hand calculation.

Gary

Reply to
Gary Coffman

Handheld, of course. I picked up one of those (the 9200B) at a stationery shop in Downey CA back in the early eighties for song ($40), with JPL stickers all over it. CRT display. Gold-plated PCBs. VERY nice, and it still worked. Unfortunately it disappeared last time we moved to a new house. Very sad, it was a beautiful example of American engineering. It cost about $4000.00 in '68 according to an old (hardcover) HP catalog I had. Back when HP was a real instrument company.

I never saw that.

The HP-35 and 45 were just a bit before my time- I knew of them, but couldn't afford (or justify) them.

Best regards, Spehro Pefhany

Reply to
Spehro Pefhany

Bob,

Some years ago, the algebraic entry calculator my daughter used at school became faulty and she required another one ASAP. She suggested she used my HP25 (yeah, it was that long ago :-) ). I told her about the RPN operation and showed her how to operate it. We got her other calculator repaired or replaced, but I couldn't get my RPN HP25 back from her. She thought the RPN operation was a lot easier than messing about with brackets on AE. If you knew my daughter you would most definitely recognise a 'non-math type' :-)

At the moment, my HP32 is broken (my fault - got damaged in my pocket) and I'm waiting on the HP33 to arrive on the UK shores :-) I'm suffering with an AE calculator in the interim :-)

Jim.

Reply to
Jim Guthrie

Agilent still makes some pretty nice stuff. They're the spin-off of HP's instrument division. I suspect that babe fiorina is going to run that business straight into the ground, and then eject at the last minute with her parachute.

Jim

================================================== please reply to: JRR(zero) at yktvmv (dot) vnet (dot) ibm (dot) com ==================================================

Reply to
jim rozen

Qx?eSÑnÛ0 |÷Wð©y?{(°ºnÅ4CÑõh?±µ?'Éuý÷;Ié0`(2yÇ;?oìíE?®???éâ÷¬éúY[ ?~.Ö{YëÝÍG{Û47µ?ö´p$/¯Î=F????zA?M=?ý v_õ}?è[`pDj?3br????§x¸Ð

Reply to
Richard Coke

Gary sez: "> As John noted, RPN works exactly the way you'd do the calculations with

I will have to agree, as I often begin calculating in the middle of a lengthy expression. Problem is, you have to record the interim results and some care is required to maintain those results. I can do it, but it is so much easier to begin at the beginning and enter things sequentially in AE. Thanks Gary, I didn't realize RPN was a product of the 20s. It would seem that for really lengthy calculations, RPN would be a labor saver.

Bob Swinney

Reply to
Robert Swinney

Martin, who presumes to know what I understand admits to having 2 sliderules - that is cool, and quite archaic, for a long time machine language writer.

ability(language not me)

Basic (the extended version )

Reply to
Robert Swinney

I suppose my comments re. RPN and pomposity caused this thread to degrade into 2 camps. I should have known that would happen. It is always easy to attack another's position when you suspect there will be many allies. In case my earlier assertion was, well, errrr, maybe a bit strong, let me state it again in terms that will appeal to the majority of posters here.

Reverse Polish Notation: Method of entering math phrases into a calculating device. The method is somewhat arcane and difficult to follow for those with ordinary mathematical proclivities. It is, however, "very efficient" for those with pre-existing mathematical training. Mastering RPN provides great feelings of satisfaction, no! pride for those that learn to use it -- errrr, make that "learn to use it well". RPN savviness yields another click on the lock of the great Math inner sanctum. In general, those that beat their breasts about how conversant they are with RPN, remind one of the very tired childhood phrase, "I know something you don't know".

Bob (I'll stick to AE, thank you very much) Swinney

Reply to
Robert Swinney

In that case, it's better that their destinies have bifurcated.

Neither HP^H^HAgilent or Tek makes stuff the way they did a generation ago, though.

Best regards, Spehro Pefhany

Reply to
Spehro Pefhany

Although oddly, I used the 'other' kind of calculators for years before trying the RPN ones. Even after all the indoctrination beforehand, I still am an RPN convert.

(translation, 'I can't figure those darn things out?')

Sorry Bob, could not resist!!

Jim

================================================== please reply to: JRR(zero) at yktvmv (dot) vnet (dot) ibm (dot) com ==================================================

Reply to
jim rozen

It is a labor saver, and you don't need to record interim results, they simply automatically get pushed on the stack as you continue to calculate, and automatically pop off the stack when you're ready to use them. That's the real power of postfix notation.

With an AE style calculator you have to be careful how you attack a problem. There are many times when you get stuck, have to store an intermediate result in memory, clear the calculator and start what is essentially a new calculation. That virtually never happens with a RPN calculator. No matter the order in which you tackle a problem, there's almost always a way to do it without storing intermediate results in memory and restarting.

Of course for simple 2+2 stuff, RPN doesn't offer any real advantages. It is when you start doing complex calculations that the labor savings, intermediate results sanity checking (IMHO the most important feature), and the ability to attack the problem in any order really starts to be of benefit. That's why RPN calculators are such a favorite with older engineers who started out with pencil and paper or slide rules. They're used to doing sanity checks as they progress with a calculation. AE style calculators don't lend themselves to that.

Of course nowadays people expect computers to hand them an answer without any thought on their part. It is just plug in the numbers and wait for the result. That's all well and good for canned solutions to known problems, but it is less satisfactory for calculating answers to new or unique problems. You're depending on the author of the software to have gotten it right. That's not always obvious. For example, the early Windows calculator gave erroneous results because it incorrectly rounded internal intermediate results. People didn't immediately catch that because the AE style offers no way to do sanity checks on intermediate results. They remain hidden from view.

Gary

Reply to
Gary Coffman

Rozen sez, glibly!

"(translation, 'I can't figure those darn things out?')"

Naw, Jim -- I liken it to climbing down a ladder with 2 rungs missing from the bottom. You have it figured OK but it is still a damned uncomfortable situation to be in. The more you climb that defective ladder, the more aggravating it becomes.

Bob (RPN is like trying to run CNC with no manual machining experience) Swinney

Reply to
Robert Swinney

[ ... ]

I wish that I had one.

[ ... ]

You may have noticed near the front on the top curve of the case were a pair of screws which were normally screwed in flush with the top. You unscrewed them a short distance, and a pair of lock levers took those and used them to clamp the printer in place.

The 35 I resisted, but when the 45 came out, I decided to bite. I never regretted it.

Enjoy, DoN.

Reply to
DoN. Nichols

And I tend to start in the middle of the formula, the deepest set of parens, and work outward as I go.

Agreed -- though it *is* possible to overflow the stack with a poorly-chosen starting point. (And even more so with Algebraic Notation.)

And one of the important sanity checks is whether an intermediate value in the denominator of a division is approaching zero too closely -- which will blow up the computation. With RPN, you can see that happen, and work around it by choosing a different sequence. With Algebraic Notation, you wind up with the thing blowing up (if you are lucky, and you still have to figure out where it happened and how to work around it. If you are unlucky, you will wind up with values which discard a lot of the possible precision, and never know that it happened.

And in really complex programs which are dependent on large amounts of input data -- such as SPICE, the circuit emulation program -- you can wind up with divide-by-zero in a *lot* of places. Luckily, the implementation of SPICE which I saw -- written to live under the BSD flavor of unix -- was set up to trap the errors, and replace the results with a maximum-positive or maximum-negative as appropriate. You really can't see where these problems will hit, since you frequently don't know how a device model is implemented, so you don't know what values of components and currents/voltages/frequencies will cause that divide-by-zero. This is made even more likely to be a problem by the fact that the program is frequently used to sweep values through the possible ranges, and crank out results for a large number of values.

Of course -- you're not going to be doing something as complex as the SPICE calculations on a pocket HP -- though I have seen a tiny implementation of a subset of SPICE for a HP-67 (one of the ones which was programmable and had a card reader/writer to save and load programs.

Enjoy, DoN.

Reply to
DoN. Nichols

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.