HP Forums

Hi

I'm in the process of designing a (non-programmable) RPN calculator, and I am after some opinions on what people would like to have in their "ideal" RPN calculator.
My practical experience with RPN is fairly limited, so I don't know all the permutations of all the HP models and their pro's and con's etc so I'm trying to figure it all out and what seems good and what's not (in my opinion).

Right now I have a 4 level stack with T operating as a constant, STO, RCL, DROP, ROLL UP/DOWN, SWAP etc similar to what is described on the (very useful) RPN pages on the museum site.

But there are things like should I have X^Y or Y^X, how to implement base-N modes, is LAST X useful, that kind of stuff.

Would you prefer just one memory using STO/RCL, or multiple constant memories called something like M1, M2, M3?

Are memory operations like M+ and M- useful? and should it operate on STO/RCL register or be seperate?

Would a deep stack be better than the basic 4 level type? if so how deep and why?

I will have a two line display, how do you think that display should best be utilised?

At the moment I have the Yreg on the upper line and Xreg on the lower. Should I waste display space showing "X:" and "Y:" at the front, or is that distracting and redundant?

Should the display simply "switch" to displaying Z: and T: or should it "slide" up and down?, or not have that feature at all?

BTW, I'm not looking at emulating any particular HP model, just simply make a good RPN calculator with as many useful features as possible that follows familiar and "accepted" practice.

Any input is appreciated.

Thanks
Dave.

Just copy the features of an HP model you like. The HP engineering teams spent LOTS of time on this question for every model ever built. Why waste time doing work that has already been done to perfection?

Besides, trying to reach a consensus here on such a feature set is akin to herding cats :)

Quote:

---

Just copy the features of an HP model you like. The HP engineering teams spent LOTS of time on this question for every model ever built. Why waste time doing work that has already been done to perfection?

Besides, trying to reach a consensus here on such a feature set is akin to herding cats :)

---

Yeah, but it's often fun to watch the cats get herded! ;-)

I guess my goal is to simply pick the best bits from various models, and that's really the sorts of suggestions I'm after. I don't really want nor expect a consensus, just some ideas so I can pick what I think are the best bits and what fits well with my design.

Thanks.
Dave.

You might get consensus on some things. For instance, I'll bet there's a broad consensus that Y^x is better than X^y, if only for familiarity's sake. HP had the latter function on the first scientific hand-held calculator, the HP-35, but abandoned it in favor of the former in all subsequent calculators. The keystroke for 2⁵ would be 5 ENTER 2 X^y for the HP-35 way of doing things, and 2 ENTER 5 Y^x for the "normal" way. That way just seems more natural to me, with the digit order as keyed similar to the expression on paper.

People here will no doubt be delighted to share their opinions on this topic with you, but there's nothing like experience to help develop your own opinions about what the ideal RPN calculator should be. Most of the machines we discuss here are available in software for Windows and/or Linux, and most of those programs are free. There are also free and for fee RPN calculator programs for Palm and Windows PDAs. Many of them are simulations of HP calculators, but some are original creations, expressing the author's opinions of the ideal RPN machine. I have used NeoCal and MathUPro. I mention them because they both represent different takes on the RPN approach than what you might find on an HP machine. NeoCal is a non-programmable, but customizable software calculator that began life on the Palm. It's very nice looking and usable in my opinion. MathUPro represents an attempt to realize the ideal RPN programmable calculator. The author seems to be an HP fan, to judge from the feature set. He's implemented an unlimited stack, but allows you to put it into a 4 stack simulation mode. It's got very geeky programming feature set, with a unique programming mode that takes some getting used to, but fits the PDA form factor well. In short, it is much geekier and complicated than NeoCal, and represents a good counterpoint to the former's approach.

And don't neglect the RPL models. They represent HP's own answer to the question of what should come after RPN and keystroke programming. They are anathema to some RPN enthusiasts, but I think they are complicated and quirky in a very cool and interesting way. They are important to understand RPN in its full context in any case.

Best of luck with your project!

Regards,
Howard

you can't go wrong by copying the function set of the 45-21-31, ie the 35 with polar/rectangular. a 4 level stack is more useful for what most people do; you can load it. memory is negotiable. if it's non-programmable but has a 4 level stack then one or two registers will be enough but if your chip allows 10.......

Thanks Howard.
I've downloaded "Free42" by Thomas Okken which looks like a very nice 42S emulator. Anyone know if it's a 100% accurate emulator?, it certainly looks and sounds like it.

Actually, the more I play with it the more I am liking the 42S. It's got a two line display just like mine will have, I like how the complex mode works (don't know if mine will have complex mode though), and I like the numbered STO registers.

Anyone have any issues with the 42S?, the interface, things that could have be been done better or more intuitively etc, or a feature other models have that this one lacks?

What are people's opinions on the "X:" and "Y:" register labels being constantly displayed? Are they perhaps a bit redundant for the more experience user?

Thanks
Dave.

Free42 is a great program that justly deserves the praise showered on it by its users. It is a reimplementation of the 42S, not a simulator. That is, it doesn't simulate the original hardware and use the original calculator ROMs unlike EMU42 or many of the other PC based calculator programs like Nonpareil, EMU48, V41, EMU41 or EMU71. that means Free42 can sometimes behave differently from the original machine, by design or otherwise. But Thomas Okken works assiduously to minimize those differences, and with the help of users on this forum and elsewhere, has achieved very close compatibility. The recent thread titled "HP42S Mini-Challenge: Optimizing !" will give you an idea of how close. This was a programming challenge by Valentin Albillo that involved the 42S. Participants used real calculators, EMU42, a ROM based simulator, and Free42 on PCs and Palm devices to respond to the challenge. Nowhere do you see issues related to compatibility of Free42 in that thread.

A lot of folks, myself included, think that in many ways the 42S represented the highest level the classic programmable RPN calculator ever reached. It has it's drawbacks, lack of I/O and expandability among them, but the user interface and feature set are very nifty. I also believe that the 42S shouldn't be the last word on the subject. That is, 20 years of Moore's Law and progress in Computer Science and user interface design could have produced interesting developments beyond what the 42S offered. The RPL models are what HP actually went to, but they represent a revolutionary break with keystroke programmable machines like the 42S. It's interesting to speculate what a more evolutionary approach might have produced.

Regarding the labeling of the stack registers, my opinion is that it depends on whether or not you change which registers are displayed. If it's always X and Y in the display, then there is no need to label them. But if you scroll the stack display, then you will have to use labels to avoid confusion.

Regards,
Howard

I think it would be nice if the calculator understood that Alpha values with no seperators meant multiplication, as 2PiFRC=1 is understood mathmatically as the product. I would double or triple the 26 letter memory storage by some added coding like A A, and A. could access added memory space. I suggest that statistical data could be stored in pairs BEFORE curve fitting analysis so that trials could made for the best fits. I would omit trivial conversions like cm-ins and f to C degrees. You might allow the user to store his most used constants with symbols instead of a rom. I would dispense with fractions.

Quote:

---

Hi

I'm in the process of designing a (non-programmable) RPN calculator, [...]

Any input is appreciated.

Thanks
Dave.

---

Software emulation or real hardware?

Ren

dona nobis pacem

I agree that the HP engineers have done a great job at figuring out the ideal set of RPN functions to include in a calculator. But after using RPN since 1972 I find two functions missing on most of their older calculators: MOD and OVER. MOD is simply remainder as in: 7 ENTER 3 MOD --> 1 and OVER is the stack manipulation function the copies Y into X pushing the old value of Y into Z, and the old value of X into Y. For example: A ENTER B OVER --> A B A.

-Katie

I had prepared a response off-line, and when I went to post found that Howard had posted a reply that was essentially identical to mine. (I'll spare Howard the insult of saying he and I must think alike.) The only things I might add would be my oft-repeated desire for a slightly enhanced way to enter, display, and manipulate complex numbers, and a five line display showing X, Y, Z, T and Last X. I also usually suggest a user settable variable stack height from say 3 to 10 levels. However, without programmability, a fixed four level stack is probably fine.

Of course, OVER is simply a RCL Y on the HP41.

Doesn't help us on our 12c machines, though.

A program I find useful is an x to t function, in RPN it is enter, enter, enter RTN. I use it to fill the stack with a constant or clear stack by first c;earing X.

Quote:

---

Software emulation or real hardware?

Ren

---

Real hardware.
This is not just another software calc for platform X.

Dave.

Quote:

---

Of course, OVER is simply a RCL Y on the HP41.

---

Which also has a MOD function. Ditto for the 42S since it is 41C compatible.

You could argue that RCL Y is less ergonomic than an OVER key would be. It's really three keystrokes: RCL . Y (where the last key is the multiplication key on the 41, also labeled "Y", and a soft key on the 42.) But I think Katie must be referring to the majority of the rest of the RPN calculators that HP produced which lack those register ops.

Regards,
Howard

Quote:

---

My practical experience with RPN is fairly limited.

---

Before you get too far along your requirements verification 'V' please read Chapter 2.5 of John A. Ball's book on RPN algorithms- all of the permutations of 4-level stack operation that are available with +,-,CLX, X<>Y and ROLLUP/DOWN and ENTER. I know there are some improvements to be made, such as the OVER command in RPL. But I feel strongly that any stack operation that requires an operand input is an annoyance on a non-programmable calculator- especially one with only a 2 line display.

I am looking for a paper I saw a year or so ago on this forum relating to the problems of modern calculators, or the comparison with slide rules.. something of the sort. I printed it, read it, and put it somewhere for safekeeping. You know what that means: I can't find it now that I need it. Does anyone have the link to that paper? Append to that link the following two books for recommended reading:

1. Algorithms for RPN calulators John A. Ball
All parts.. especially 2.5 and the monadic/dyadic/Bifid functors discussion is central to your quest

2. HP 48 insights William C. Wickes
Sec. 1.1 on the history of RPN and 3rd gen calculators like the 28/48 series. and Sec 2.0 RPN Principals

Quote:

---

I'm in the process of designing a (non-programmable) RPN calculator, and I am after some opinions on what people would like to have in their "ideal" RPN calculator.

Any input is appreciated.

---

Hello, Dave --

If input ye ask, input ye shall receive ...

Quote:

---

Right now I have a 4 level stack with T operating as a constant, STO, RCL, DROP, ROLL UP/DOWN, SWAP etc

---

DROP is stack operation for only RPL's (e.g., HP-48) dynamic-depth stacks. It is unneeded for RPN's fixed-depth stack. SWAP is the RPL term for x<>y.

Classic RPN gets by just fine with the elegant simplicity of "x<>y" and "roll down". "Roll up" is a convenient nicety, useful mainly for programming. The HP-41/42S models add direct access to stack elements and a VIEW command.

Quote:

---

should I have X^Y or Y^X, how to implement base-N modes, is LAST X useful

---

x^y was offered only on the HP-35, perhaps because it lacked a 10^x function and common logarithms:

x [ENTER] 10 x^y = 10^x

y^x, however, is more natural and consistent with subtraction and division.

Most scientific RPN and AOS models starting with the Pioneer series (in 1988) offered integer arithmetic in base-2, base-8, and base-16, while base-10 remained floating-point with conventional BCD math.

LASTx is very useful for error recovery and as a convenient "stack-extender." RPN models lack RPL's UNDO function.

Quote:

---

Would you prefer just one memory using STO/RCL, or multiple constant memories called something like M1, M2, M3? Are memory operations like M+ and M- useful? and should it operate on STO/RCL register or be seperate?

---

If more than one memory is offered, M1, M2, M3 with M+ and M- will make for a busy keyboard. Most models have storage-register arithmetic functions, such as STO+3 and RCL/2, giving extended functionlaity without additional functions on the keyboard.

Quote:

---

Would a deep stack be better than the basic 4 level type? if so how deep and why?

---

A user-settable fixed stack up to 9 or 19 elements deep (e.g., [STKD] 9 or [STKD] .9), with default of 4, would be useful.

Quote:

---

I will have a two line display, how do you think that display should best be utilised?

At the moment I have the Yreg on the upper line and Xreg on the lower. Should I waste display space showing "X:" and "Y:" at the front, or is that distracting and redundant?

Should the display simply "switch" to displaying Z: and T: or should it "slide" up and down?, or not have that feature at all?

---

The "X:" and "Y:" indicators on the HP-42S were present because the temporary menu-line display in the bottom row necessitated the identification of what was displayed above. Space for the indicators was made available by its fine-grain LCD display.

Up/down scroll arrows would make possible viewing of the stack without modifying it, but is hardly needed with a short stack, roll down, and the VIEW command. The down scroll arrow, however, is used for single-step execution on the HP-32/42 models.

I generally prefer a larger, easier-to-read one-line display on non-graphing models, although the two-line display has some advantages.

-- KS

Edited: 12 May 2007, 2:12 p.m.

Quote:

---

I think it would be nice if the calculator understood that Alpha values with no seperators meant multiplication, as 2PiFRC=1 is understood mathmatically as the product.

---

In your example, how would the calculator know whether to interpret that as 2*Pi*FRC or 2*Pi*F*RC or 2*Pi*FR*C or 2*Pi*F*R*C?

After seeing a pair of threads in these fora recently (and being sure there are numerous others), I think the single most important feature is a well-documented, strictly followed set of computation rules. We don't seem to mind odd results from odd calculations if they're expected based on the published specs.

Along with the above, I think high precision is a must. How many sig figs can you squeeze out of your hardware at reasonable speed? Perhaps a user-selectable single/double precision setting.

And it would be especially cool and interesting if along with a SHOW type of function to see all the precision available, the calculator could report the number of digits that should be accurate after a chain calculation. I know nothing about implementing this sort of thing, so I have no idea whether it would be practical.

Drop me a line, we have much to discuss.

This Message was deleted. This empty message preserves the threading when a post with followup(s) is deleted. If all followups have been removed, the original poster may delete this post again to make this placeholder disappear.

Hi, Alex --

Quote:

---

Along with the above, I think high precision is a must. How many sig figs can you squeeze out of your hardware at reasonable speed? Perhaps a user-selectable single/double precision setting.

---

Double-precision calculations are generally not meaningful without double-precision variables. There are exceptions, of course -- namely, to reduce roundoff error in a calculation that is susceptible to it. However, the three "guard digits" of internal extended precision built into HP and other brands of calculators will generally suffice.

The IEEE has established formal definitions for 32-bit (single precision) and 64-bit (double-precision) floating-point binary representations. 80-bit extended-double-precision words are also commonly used with floating-point math in PC software (and exclusively in the HP-30S) to reduce roundoff errors. However, I believe that to add a double-precision type of variable to a handheld calculator would cause undesired complexity and reduced computational speed, both of which are issues of concern: Calculators use low-power and inexpensive microprocessors, usually performing BCD mathematics.

I rather like the approach taken for all HP's based on the Saturn microprocessor, which is to accept input of 12 significant digits, and then use algorithms designed to return answers correct to all 12 significant digits.

Earlier HP's, modern low-end calculators, and even some later high-end TI's don't perform to that standard. Calculators of the first two groups offer only 10 digits. In at least one respect, both the 10-digit models and the 12-digit TI-82 from 1993 (a "high-end" TI model) don't always fully utilize available significant digits for a result.

Try sin(3.141592653 radians) or sin(3.14159265358 radians), as appropriate: You'll typically get an answer with only two significant digits:
5.9E-10 or 9.8E-12 respectively, which may very well be the three internal "guard digits", rounded. However, the string of leading zeroes and the lack of overlap between the input and output make a full-precision result possible. Saturn-based HP's (and their descendants) give 9.79323846264E-12.

-- KS

Edited: 12 May 2007, 1:58 p.m.

The only way OpenRPN can truly die is if I give up on it. My personal life has kept me occupied for the past 6+ months and I at last have time to spend on it again.

I will always welcome constructive criticism... It's much better to have your critics inside the tent pissing out than outside the tent pissing in.

-Hugh

More like yet another anonymous coward.

An anonymous cowardly character assassin too.

Quote:

---

Drop me a line, we have much to discuss.

---

Your email address bounced.

Dave.

While I would prefer to do neither inside or outside, I do wish to continue pointing out that the only proven thing OpenRPN has produced so far are CAD drawings (nice ones) and different forms of specs.

I believe OpenRPN is in the same position as JYA's abortive attempt to produce the Quonos. Too much capital required, etc, for it to become a reality.

Too many people are too quick to place their hopes into a basket that has no real bottom.

That said, it also reflects upon HP's failure to produce a good, quality, RPN calculator. I'm not stupid enough not to see why people want to believe in projects like OpenRPN.

At present, however, I believe they are like the true believers in UFOs, because the amount of evidence offered as proof is about the same.

Gene

P.S. I'll be glad to eat lots of crow when presented with a working, relatively inexpensive protype. Really, I'll eat crow and offer public mea culpas. I'll prepare a picture of myself with a caption that says "I should have believed but I believe now". I just think the odds of that happening are so low as to not worry about it.

Try out this one

Quote:

---

I've downloaded "Free42" by Thomas Okken which looks like a very nice 42S emulator. Anyone know if it's a 100% accurate emulator?

---

That's what it aims to be. There are differences: the HP-42S uses a decimal representation with a 12-digit mantissa and an exponent range of -499..+499, while Free42 Binary uses IEEE-754 double precision binary floating point, and Free42 Decimal uses a base-10000 representation that is effectively equivalent to 25 digits with an exponent range of -10000..+9999.


Also, the SOLVE and INTEG commands use different algorithms than HP's implementations (HP's algorithms were never published; some technical highlights were explained in HP Journal at various times, but never the kind of detail that would allow one to replicate their algorithms fully).


Finally, the HP-42S has a few known bugs (there is a list in the top-level README file in the Free42 source package). These bugs were not replicated in Free42.

Apart from those differences, Free42 should be 100% compatible with the HP-42S -- if it's not, then that's a bug. :-)

HTH,

- Thomas

Karl,

Thank you for helping me to clarify in my own mind what my true wish is.

I like the 50g's feature of 12-digit precision for decimals, but arbitrary precision for integers.

So that's my real "high-precision" wish - available high precision (say, 30 digits?) for integers.

-Alex

QonoS had massive overhead costs, in large part due to some poor development choices (injection molded prototypes rather than rapid prototyping for example). OpenRPN requires startup costs measured in only tens of thousands of dollars rather than millions.

The big curse of open hardware development is that one has nothing to show for their efforts until a product reaches the marketplace. The most realistic outcome for OpenRPN is convincing a company to license production of an effectively ready-to-go product.

As far as eating crow is concerned, buying two OpenRPN end products will be thanks enough. ;-)

As always, I look forward to proving the naysayers wrong.

-Hugh

Quote:

---

The big curse of open hardware development is that one has nothing to show for their efforts until a product reaches the marketplace

---

How about...

* a project plan, with realistic and measurable goals?

* a website where evidence of progress is given, not just endless forum debates over the size and placement of the ENTER key? (I'm sure an up-to-date website would attract more interest in the project, and recruit more volunteers)

* a public source code repository, much like you have at the moment? It's easy to see if the code is being worked on or not.

* hardware block diagrams, and later on schematics as the hardware evolves?

* photographs of some prototypes? Not just CAD drawings, but something that has actually been built. Heck, a $30 evaluation board with an LCD saying "hello world" is a step in the right direction.

Denial is more then a river in Egypt.

C'mon, you OpenRPN guys. These are entirely reasonable, implementable suggestions.

How can you make anything with a plan, etc?

Publish this stuff and it will show you're making progress or not. :-)

Thanks for the reply!

As a fading Electronic Tech, have you decided on the
architecture or keyboard? (You don't have to answer, as it might
cause this thread to wildly spin-off).
Good Luck!

Ren

dona nobis pacem

Gene et al,

I may have missed it as I was only skimming some of the posts...

But did DaveJ _EVER_ say he was looking to go into production?

(if he did, pass me a helping of crow)

Building an electronic gizmo for some people is akin to the driving force behind mountain climbing..."because it's there...".

Only in this case, it may be because, "it isn't there"... a home-built
RP[LN] calculator.

Again, I wish DaveJ the best of luck, it is something I'd love to do,
IF I had more time, more money, more talent, (sigh!)

Ren

dona nobis pacem

I wasn't speaking of DaveJ but OpenRPN, which Dave is not associated with (that I'm aware of).

Quote:

---

Thanks for the reply!

As a fading Electronic Tech, have you decided on the
architecture or keyboard? (You don't have to answer, as it might
cause this thread to wildly spin-off).
Good Luck!

---

I have indeed decided on both of those thing, but I'm keeping mum for the time being :-P
All will be revealed in due course though.

Dave.

Quote:

---

Gene et al,

I may have missed it as I was only skimming some of the posts...

But did DaveJ _EVER_ say he was looking to go into production?

---

I didn't mention it, but now that you mention it, production of some form is a very real possibility.

Sorry I can't give more details away, I really want to, but I know I shouldn't, not just yet anyway.

Dave.

I couldn't agree more with your comments. The early days of OpenRPN were ill-founded, but gave me a chance to understand end-user expectations. At the moment I'm facing a restart of the project... I couldn't ask for a better opportunity to decentralize management, and if nothing else, design market-ready products with a few full prototypes that can be funded from pre-orders or better yet licensed to a capable company that will accept our specifications.

I don't give a damn about making a buck from OpenRPN. Engineers and other scientific professionals deserve capable, well-made calculators at a reasonable price that aren't 15-20 years old.

The members of this community are more than capable of accomplishing such a goal. Let's just step up and make it happen.

-Hugh

Thank you. I wish you the best of luck.

Quote:

---

I couldn't agree more with your comments. The early days of OpenRPN were ill-founded, but gave me a chance to understand end-user expectations. At the moment I'm facing a restart of the project... I couldn't ask for a better opportunity to decentralize management, and if nothing else, design market-ready products with a few full prototypes that can be funded from pre-orders or better yet licensed to a capable company that will accept our specifications.

I don't give a damn about making a buck from OpenRPN. Engineers and other scientific professionals deserve capable, well-made calculators at a reasonable price that aren't 15-20 years old.

---

That last paragraph has made me curious.
Nostalgia, emotions and other wish lists aside, what is actually wrong with calculators of today?
Are they not capable?
Are they not well made? (or at least reasonably made?)
Are they not affordable?

In what ways do you and the OpenRPN community think you can do better?

Please don't get me wrong, I'm not having a go at you or the OpenRPN community, in fact I think it's great idea, and I may even contribute something myself at some stage. But as an electronics product design engineer I am interested in knowing what the issues are.

Thanks.
Dave.

Quote:

---

Are they not well made?

---

In terms of physical construction, they are definitely not as well made as traditional HP calculators (though HP had their own screw-ups from time to time, such as the press-fit construction 30-series, and the use of the NiCd battery to limit the charger voltage).

Quote:

---

Are they not capable?

---

In terms of functionality, things are less clear. If what you want is a non-scientific traditional RPN calculator, the 12C or 12c Platinum will do. But if you want a traditional RPN scientific, the only one is the 33s, which is reasonably good other than the decimals in the display (still not great even after the improvement) and the wacky keyboard.

There's clearly room for improvement. Competition would help drive that, but the chance of any real competition in RPN calculators coming about seems negligible.