Minimal Scientific Calculator: A Modest Proposal (long!)



#30

Introduction

A recent thread here asks, "What is the most useless
function on a scientific calculator?" Many people have answered and a
spirited discussion has ensued. One argument against functions such
as x^2 and % is that it's easy to calculate the function without
needing a special key.

That got me to wondering: how few functions can we
use to build a scientific calculator. Right now I'm looking at my
11C: a beautiful machine, to be sure, but loaded with keys and
functions. The engineer in me asks, "How can I reduce its complexity?
What can I get rid of?" The 10C was a step in the right direction
but in my opinion was a failure because it did not go far enough.

Let's see how much of the extra functionality we can remove. True, we
will have to learn some new key sequences but HP users are used to
doing things a little diffenently, what with RPN and all.

Let's call this new machine the HP-11C-. (Although some other names,
like HP-11D- or HP-11F may come to mind too.) Readers of the other
thread will be happy to learn that the 11C- does not include %, x^2,
Grads, n!, or hyperbolics; thus, it should make everyone happy.

Hello, Numbers, Goodbye -, /, Trig and Logs

First, let's mention a few things we'll keep. All of the number entry
and stack manipulation keys: [0]-[9], [.], [CHS], [EEX], [ENTER],
[<-], [x<>y], [R Down], [R Up], [LST x]. Display Mode keys: [FIX],
[SCI], [ENG]. Shift keys: [f], [g]. Not to mention [ON].

Now let's get rid of some stuff. We still need to add, so [+] stays.
But with [CHS] to negate numbers we don't [-] any more; use the
sequence [CHS] [+] to subtract.

Similarly, we may eliminate [/] if we keep [1/x], which is useful in
contexts other than just straight division, in forming negative
exponents, for example.

All trig functions will be done in
radians so [DEG], [RAD], [GRD] go away. We don't need the trig
functions either: angle [ENTER] 1 [->R] gives us the
cosine in x and the sine in y. They can be divided to get the tangent.
[->P] gives the arctangent; the other inverse trig functions can be
calculated from the arctangent with the appropriate formulas. [0]
[1] [CHS] [->P] [x<>y] gives us pi, so there goes another key. With
pi still available, we don't need [->DEG] or [->RAD].

Let's hold onto [LN] and [e^x]. We can then calculate common logs and
antilogs, and arbitrary powers and roots, so we don't need [LOG],
[10^x], [y^x], [x^2] or [sqrt x]. Hyperbolic functions and their
inverses are defined in terms of exponentials and natural logs, so
they go out the window, too.

Other Functions

Memory ([STO], [RCL]): Keep.

[%], [Delta %]: Not necessary, compute using formula on back panel of
calculator.

[ABS]: Trivial to do by hand or in a program.

[CLEAR Sum], [CLEAR PRGM], [CLEAR REG]: Don't need. Get rid of them.

[CLEAR PREFIX]: Useful for correcting incorrect prefix key press.
Keep.

[CLx]: Not sure about this one. Let's get rid of it and put it back
later if it proves necessary.

[RAN #]: Too hard to duplicate. Keep.

[Py,x], [Cy,x]: Can be computed with factorials. Get rid of them.

[x!]: Get rid of it unless you need the gamma function.

[->H.MS], [->H]: Drop; easy to implement.

[FRAC], [INT]: We don't them both. Keep [INT] and compute fractional
part with Frac(x) = x - INT(x).

[USER]: Just a conveinence function. Don't need it.

[MEM]: Why bother? Get rid of it.

Statistics: [Sum+], [Sum-], [x bar], [s], [y hat, r], [L.R.]: Can all
be computed by hand. Get rid of them.

Programming Functions

We will keep all of the programming stuff with the following exceptions:

[BST]: We can just go back to the start of memory and [SST]. Drop.

[DSE], [ISG]: Can rewrite with other sequences of instructions. Get
rid of them.

Flags: We can duplicate their effect using regular memory registers.
Out they go!

Conditionals: We certainly don't need eight of them! First, get rid
of the four "compare x to 0" tests. We can just put the zero in
ourselves and use the "compare x to y" tests. Next, [x=y] and [x!=y]
are exact opposites; we only need one. Let's keep [x=y]. Finally,
[x<=y] and [x>y] are also opposites; let's keep [x>y]. This eliminates
six of the eight conditionals and leaves just two nonredundant ones.

Examples

Now let's put it all together. First some simple examples (all to 4
decimal places):

Square root of 625: 625 [LN] .5 [X] [e^x] (Answer: 25.0000)

Common log of 2: 2 [LN] 10 [LN] [1/x] [X] (Answer: 0.3010)

Common antilog of 2.775: 2.775 [ENTER] 10 [LN] [X] [e^x] (Answer: 595.6621)

2^5: 2 [LN] 5 [X] [e^x] (Answer: 32.0000)

cos 0.75: .75 [ENTER] 1 [->R] (Answer: 0.7317. [x<>y] gives sin 0.75 (0.6816))

And finally, a larger example:

Arc sin 0.6, in degrees: [LN] [LST x] [x<>y] 2 [X] [e^x] [CHS] 1 [+]
[LN] .5 [X] [e^x] [->P] [X] 180 [X] 0 [ENTER] 1 [CHS] [->P]
[X] [1/x] [X] (Answer: 36.8699)

Isn't this more satisfying than hitting just two keys, like on other
calculators? Here you have a real sense of ownership of your answer,
having worked hard for it. The HP-11C- will give you many
opportunities for this kind of satisfaction.

Conclusion

The appeal of the proposed HP-11C- is clear. Fewer built-in functions
mean less ROM and fewer keys. This translates to lower manufacturing
costs and higher reliability. Fewer keys also means that the
calculator can be made smaller without sacrificing key size or spacing,
preserving the excellent Voyager series ergonomics. And as can be
seen from the description above, the calculator provides a built-in
never-ending refresher course in math, as opposed to other calculators
which only act as a mental crutch the more you use them. This aspect
alone could make the 11C- a hit in the educational market.

Comments and suggestions are always welcome.


#31

Well, this is interesting as an academic exercise, but I wouldn't be buying any stock in the company which tried to build and sell them.

As is often the case with such brainstorming sessions, the goals of the exercise are not clear. Is it simply to think of a design that has few keys? Is it to build a calculator that is easy to use? Is it to increase the machine's reliability? Is it to reduce manufacturing costs? All of these appear to be alluded to in your discussion.

What your design clearly is not, IMO, is one which would actually sell and make money for its manufacturer. I, and I suspect a huge majority of people, would NEVER buy a calculator which didn't include a subtract key, asking me instead to hit CHS then ADD. I mean, come on... people buy these things (in large numbers) to make their lives EASIER, not more thought provoking. The missing subtract function is just the most obvious of deal killers for me. There are many, many others.

This is your thread, and you're free to state what the goal of this discussion is from your point of view, but ease of use and reliability are ones that could generate some great discussion. I don't think, for example, that reducing the number of keys by 50% ... sorry ... we don't have percents ... by a fraction of 1/2 (luckily I still have reciprocal) ... will increase the calculator's reliability all that much. Maybe I'm wrong, I don't know. What I would do is find out what the chief reasons are that caculators fail and try to do something about those. For example, I suspect human error -- leaving batteries in the machine long term -- is a chief culprit. Maybe some clever engineering can overcome that. Make the battery compartment sealed and replaceable?? I dunno... there's gotta be a cheap way. In any event that would be my approach -- profile and attack the biggies first.

For ease of use, you'd have to likewise do some usability studies. Again, people seem to like machines with less busy keyboards. Can we be clever somehow in reducing the shift keys down to only one? That would help. I like and have often thought about Luiz' point about making tiny little LCD's above the calculator keys to show what the keys do at any given time. That sounds like it might be good from a usability standpoint (but take a giant step backwards in reliability, I suspect).

I've said enough for now, I think. Maybe too much ... :-)


#32

The humour seems to have got lost in the ROM with no key to access it !

#33

Acknowledging the possibility of lcd keys, I'd like to suggest something else- which may seem odd, but has potential. more single line LCD displays above the next two rows of keys.

this gives you a 3 row soft menu effect very easily, without having to worry about the keys themselves going bad.

but looking at all these answers- I find that most solutions ahve been used in various HP calculators- just not all at the same time.

overlays- good ones like the 41 had, don't exist for the pioneers. Soft menus like you have for the 42, don't exist for the 41. (overlays aren't the ideal answer, since they are seperate and therefore losable pieces, but they are better than nothing, and I don't trust the quality of the lcd keys in a field calc.)

a display that displays 4 stack levels isn't on any machine previous to the RPL era.

the way the % key is implemented that works so well for VAT would be even better done as a program if you had a (minimum)two line display and a user configurable keyboard. This makes the need for the dedicated % key less. it also applies to many other keys.

x^2 would not be such a concern on stakc conservation if the stack was configurable.

natively supporting both keystroke and RPL programming models on the same machine would solve many problems.(such as dynamically adding to the functions usable by the keystroke programming 'language')


- personally, I like the 32Sii. I *like* the 2 shift keys. give me that keyboard layout, the functionality size of my 42S, the display of a 28, and 64K or better RAM and I'd probably keep quiet. (well, IR I/O and the ability to flash the OS would be nice)


#34

Yes, right on my thoughts with:

stack configurable,
and RPL/keystroke support,
and 32sii is mighty nice generally (E-bay seems to be proving that!)

I think IR will be uneccessary in the future--look at what is on the market right now for memory transfer at very low cost....

The business (further up the thread) about saving lines by using <shift>x^2 etc only matters when the memory is rather "hard" rather than configurable. With memory more "soft" like the 32sii (the old 10-c series was on the right track already with the automatic line allocation
) --the newer idea of having a pot of memory that can be used for anything, that makes the number of lines per se unimportant.

#35

Hi Patrick!

You Wrote:

Well, this is interesting as an academic exercise, but I wouldn't be buying any stock in the company which tried to build and sell them.

Me neither!

...the goals of the exercise are not clear. Is it simply to think of a design that has few keys? Is it to build a calculator that is easy to use? Is it to increase the machine's reliability? Is it to reduce manufacturing costs? All of these appear to be alluded to in your discussion.

The only goal was to reduce the number of functions to a bare minimum. The other benefits (fewer keys, lower cost, reliability) were just icing on the cake, not actual objectives. Clearly ease of use was not a goal!

I don't think...that reducing the number of keys...will increase the calculator's reliability all that much. .... What I would do is find out what the chief reasons are that caculators fail and try to do something about those. For example, ... leaving batteries in the machine long term -- is a chief culprit. ... Make the battery compartment sealed and replaceable??

You could be right, I don't know. But for electronic equipment in general, mechanical components like switches, keys and connectors tend to fail more often than the electronic components. Thinking back on the repair threads on this forum, keyboards, battery packs, and LCD displays come up an awful lot, followed by ICs, with LED displays perhaps last. Card readers also seem to be a trouble spot. (My recollections, not to be taken seriously.)

Your sealed battery compartment idea sounds like a good one.

For ease of use, you'd have to likewise do some usability studies. Again, people seem to like machines with less busy keyboards. Can we be clever somehow in reducing the shift keys down to only one? That would help. I like and have often thought about Luiz' point about making tiny little LCD's above the calculator keys to show what the keys do at any given time. That sounds like it might be good from a usability standpoint (but take a giant step backwards in reliability, I suspect).

I suspect my proposed calculator would get laughed out of any useability study.

Getting down to one shift key would require either reducing the number of functions or increasing the number of keys. No obvious shortcut here.

Per-key or per-row displays would be nice but would add to the cost of the machine and greatly reduce reliability. (Think of the increase in interconnections alone!) Rather large pushbuttons with built-in displays are available but are very expensive. (Maybe $50 a switch?) Unless something new comes along, I think we're stuck with one row of softkeys below the display and/or keyboard overlay sheets. Oh well.

I've said enough for now, I think. Maybe too much ... :-)

Me too. Anyway, thanks for your reply.

- Michael


#36

Hey, sorry if I missed the humour... I think I gave up half way thru... mea culpa.

When you look at reliability, I bet a lot of failures are not reported (uh... it kind of ... well ... slipped out of my ... uh ... shirt pocket as I was ... uh ... flushing the ... )

I guess my point is that human error is likely a huge problem with reliability. I realize mechanical parts are the major culprits otherwise. Bet a lot of keys fail, though, because they're trying to work through that layer of Coca-Cola that got laid down betwen them and the key sensors.

#37

Great ideas!

While you're at it, let's get rid of the "8" key.

I hardly ever use it and if I need to I can always use: 7 <enter> 1 +

Happy Friday!

- Mike


#38

Hi Mike!

Thanks for your suggestion.

I will give all the consideration it deserves. :)

- Michael

#39

In fact the calc can run only in binary mode, so all number keys we need is "0" and "1" :-))))))). Sqrt and ln are not needed as well as we can program the calc with Taylor series based algorithms...

#40

By the time you put all that thought into doing what we now consider basic calculation, why not completely eliminate the calculator?

If we instead used slide rules, we would never worry about batteries and corrosion. There would be no buttons to wear out. With today's technology, an accurate and rugged slide rule could be produced for mere pennies. I would think that the type of person who would eliminate the minus sign and common log would be all over slide rules. If you stop to think about it, slide rules are beautiful in their simplicity and reliability. With pen and paper, some nice laminated log tables, and a good slide rule or two and we'd be all set.

People would be more well educated in basic math, but by the time they got anywhere, they will have had their fill.

I'm thinking of it, and I'm trying to imagine jumping through all those hoops just to find a simple sine in degrees. (gasp) Talk about increasing your chance for erros, esp. math novices...

Anyway, I'm sure you've thought of all this and maybe the purpose of the post was just to illustrate that which features are really necessary is a matter of personal taste and knowledge base... Good thoughts!

-Jeremy


#41

Binary!

all math on ten fingers.


#42

cristof - thats not binary: fingers are "digital" :-) - d

#43

Jeremy wrote:

I'm thinking of it, and I'm trying to imagine jumping through all those hoops just to find a simple sine in degrees. (gasp) Talk about increasing your chance for erros, esp. math novices...

You find 28 keystrokes for an arcsine excessive??? Gee, way back when, men were made of sterner stuff. :)

Anyway, I'm sure you've thought of all this and maybe the purpose of the post was just to illustrate that which features are really necessary is a matter of personal taste and knowledge base... Good thoughts!

I hadn't thought of it that way but that sounds about right.

I have used slide rules and while they're fun to play with, I sure wouldn't want to give up my calculators for them.

Thanks for your reply.

- Michael

#44

Mr. Coyle put together a nice tongue-in-cheek discussion (particularly the conclusion) that made for an interesting quick read. Patrick might have missed the point, I think...

I believe that the 10C (mentioned in Coyle's post) failed commercially (1982-84 lifespan) because its functionality was stripped down too much in the interest of creating an "entry-level" model. 12C-like programming capability and lots of stuff taken out for an $80 price tag in 1982? More like a marketing gimmick -- wise salesmen would have directed customers to the 11C and 15C. ("Yeah, it's cheaper, but you don't really want it -- here's why...") In those days, I'll bet those units not bought through mail order were sold by knowledgeable clerks at electronics counters.


#45

You're right about the 10C, of course. If someone's in the market for a Cadillac, they're just not going to be interested in a stripped-down Cadillac. Likewise with HP calcs.

I like your "sell-up" theory. I think you've something there.

- Michael

#46

Thank you Michael... LOL, at the wit of it all. (Um, his title should have been a clue-- Jonathan Swift's famous essay "a Modest Proposal", about breeding babies as a potential food crop, was actually castigated and Swift reviled for his cruelty and insensitivity when it was first published. Neither Swift, nor Coyle, are suggesting what they SEEM).

The purpose of ANY tool is to make efforts EASIER. Of course you can make a tool much more complex than it needs to be. You can also turn out beautiful work with stone axes and bone awls. You nearly ALWAYS have to know what the heck you are doing, with whatever tool you choose.

The question of when the learning curve of the tool exceeds the user's willingness to learn it, and the equally relevant question of when does automation interfere with understanding of the process--- hey, SOME of this was decided long, long ago when mathematicians invented various symbolic representations of concepts which we are now expected to know and understand enough about to IMPLEMENT when necessary.

We ALL understand the concepts behind and the rules regarding addition (+) and subtraction (-) of numbers; but it has become second-nature to us primarily because we were TAUGHT this symbol-manipulation from an early age. If you have had experience with little kids, you realize that even these concepts require a bit of training for a mind to grasp. Anyone remember having to memorize their multiplication tables?

I remember at the age I was introduced to division that I mused it wasn't as "clean" as multiplication (*I don't remember how exactly I expressed that*) because if division had Remainders, so should multiplication...

And we go through schools and more and more ARBITRARY ABSTRACT SYMBOLIC EXPRESSION is thrust upon us; I'm not condemning such, but trying to make the point that concepts such as negative numbers, SINs, degrees, logs, exponents, "imaginary" numbers-- all are attempts by the mathematical community to take real-world observations or logical extensions of them, and make a "language" of symbols and syntax whereby you can easily manipulate them IF you understand what they do, or at least what you can do WITH them.

On my 15c, I note that it does imaginary numbers. I frankly have never used them, and don't know HOW to. In my rather mundane life, I have never been asked to solve a problem that required them (or I am ignorant of the need I have, and have thus missed out on a potential use of my tool).

This is the truth of ANY function on a calculator: if you don't know WHERE to use it, you won't.

Percents and such "derived" operations are no more, no less a "convenience" than automated conversions or, as Coyle has so skillfully pointed out, many other mathematical operations. The whole purpose of them is to let the user avoid the derivation process by automating it to one little keystroke. The PERFECT calculator, in fact, might just have one key: "Answer". ;-)

#47

Of course there would have to be 10 volumes of spiral bound 1" thick manuals which would add $200 to the price!

The only point I disagree on is reliability, you say it will be increased with fewer keys, but lots of keys used infrequently will wear out much more slowly...


#48

LOL. I forgot about the manuals!

You do have a point about reliability. A calculator with a very small number of keys will get "used up" quickly. But a very large number of keys with little-used functions will not slow down the wearout of the commonly-used keys like [ON], [+] and [ENTER], but do add more points of potential failure. Clearly there is a minimum to this curve where there are enough keys to spread out the wear but no more. I suspect (but with no actual evidence) that current calculators are fairly close to this point already.

Maybe the way to improve reliability is to add redundant keys for the ones most prone to early wearout. How about 3 [ON], 2 [ENTER], 2 [+], etc.? Not much point though since most calculators now are throwaways.

- Michael

#49

this idea has merit.

recently i asked myself a similar question. given a fixed number of keys (eg 36) some of which are allowed to be shift keys. what is the best function layout that leads to the minimal number of keypresses on average for scientific functions.

thus a function hidden away in a submenu or on multiple shifts cannot have an alternative shorter computation. so the idea of using chs + to perform subtract could only pay out if `wasting' a key on minus meant making other popular operations longer. clearly not in this case.

in a gray area are operations like x^2. x^2 is actually quite common, but its only 2 keys if not present, one if present. does it justify that key?

also, some functions can share the same key. like pi and eex. early commodore used to have a 1 key memory. "M" is sto after = and rcl otherwise. a bit quirky yes, or should sto be f rcl or should rcl be f sto or should they have their own keys?

so this is a different minimization goal.


#50

Hugh wrote:

recently i asked myself a similar question. given a fixed number of keys (eg 36) some of which are allowed to be shift keys. what is the best function layout that leads to the minimal number of keypresses on average for scientific functions.

Thanks for your reply.

<didactic>

Clearly some functions are more important than others. No one would even dream of making [+] a shifted function, yet it seems perfectly reasonable for, say, hyperbolics.

So what you do is assign a weight to each function based on how ofter it's used. For instance, give each of [0]-[9], [.], [+], [-], [X], [/], and [ENTER] a weight of 0.03 (3%). Then we're saying that taken all together these keys account for half the keystrokes. [STO] and [RCL] are also popular, but not quite as much, say 0.02 each. And so on, down to, say, inverse hyperbolics, at perhaps 0.005 each. (When we're done hopefully the weights add up to 1.0.) Then design a hypothetical keyboard arrangement and score it by counting the keystrokes required for each operation and multiplying it by that operation's weight. Now your job is to arrange the keyboard so as to minimize the score (which is the weighted average of the number of keystrokes to perform all operations).

My apologies if the above is already obvious to you.

I would be very very surprised if the calculator manufacturers were not doing this already. The layout of any given calculator reflects the engineers' attempt to minimize the keystrokes for the machine's expected use. Note that on some HP machines, square root needs a shift key to operate (some other operation was deemed more important), while on others, square root is unshifted (i.e. square root is very important).

This reasoning also applies to the question of what functions to include in the first place. Is 10^x so important that we must include it, even though y^x can be used instead? You get the picture.

</didactic>

#51

If I might add something to the discussion, IMHO, what I would need in my everyday life (an would for sure carry it always with me) is an RPN scientific calculator (0-9, +, -, *, /, ENTER, RollDown, x><y, CHS, EEX, CLX, LAST X, x^2, SQRT(X), 1/x, y^x, LN, LOG, EXP, 10^x, SIN, COS, TAN, ASIN, ACOS, ATAN, DEG, RAD, >HMS, >H, STO, RCL, SIGMA+ and nothing else) built into my mobile phone, which should be designed and manufactured in an oldHP fashioned way...

Or perhaps a mobile phone built into a HP11C :)


#52

Hello Nenad,

That's an interesting suggestion -- RPN calc + cell phone.

The good news is that from a technological standpoint, it's easy.

The bad news is that you would have to convince a cell phone manufacturer that there's a market for it. :(

Thanks for writing.

- Michael


#53

RPN calc + cell phone? Sure there'd be a market for it. I'd bet students would love it, at least until the instructors figured out what was going on and banned them from the classroom.

Regards,
James

#54

. . . and add a programmable, universal remote control capability. If I'm going to carry a phone around, it'd be nice if it could substitute for the always-misplaced VCR or TV control!

Universal remotes are cheap, small, and not too hard on batteries. One could easily be built into a Personal Multi-Function Device.

#55

Just a comment by a not-so-convinced minimalist :-)


#56

Hi Andrés,

Yes I do know about Turing Machines.

Of course a calculator is already a T.M. and can compute anything any other T.M. can, within the limits of its memory (and the patience of its owner).

I was thinking of building a T.M. but I couldn't find out where to buy the infinite tape. :)

Thanks for writing.

- Michael


#57

Have you tried www.infinitetapes.com? There seems to be a specialized seller out there for just about anything else you could imagine.

#58

Michael:

I enjoyed the thread, and some of your points are valid indeed, but... don't get too minimalist!

Best wishes!


Possibly Related Threads…
Thread Author Replies Views Last Post
  HP Prime: Long integers (continued) Helge Gabert 2 1,501 11-07-2013, 11:24 AM
Last Post: Helge Gabert
  HP Prime: Pass "Long" Integers to a Program Helge Gabert 6 2,440 11-03-2013, 01:12 PM
Last Post: Helge Gabert
  HP Prime polynomial long division bluesun08 13 3,651 10-30-2013, 03:29 AM
Last Post: parisse
  Availability of scientific HPs Matt Agajanian 4 1,592 08-28-2013, 07:40 AM
Last Post: Eddie W. Shore
  JOT scientific calculator Richard Berler 4 1,765 08-21-2013, 05:25 PM
Last Post: Richard Ottosen (Denver, CO, USA)
  Our 11C Scientific Calculator Android app is on launch sale, 0.99$ only John 1 1,185 06-22-2013, 01:38 PM
Last Post: Marcus von Cube, Germany
  Vicinno 11C Scientific Calculator app is on Android now John 0 952 06-14-2013, 02:28 PM
Last Post: John
  Great news - Vicinno's HP 15C Scientific Calculator iPhone app is FREE now John 21 6,081 06-07-2013, 05:49 AM
Last Post: Mike (Stgt)
  A very long HP-17BII equation Gerson W. Barbosa 22 5,335 04-19-2013, 12:37 AM
Last Post: Gerson W. Barbosa
  A long WP-34S night Siegfried (Austria) 10 3,100 04-16-2013, 02:11 AM
Last Post: Siegfried (Austria)

Forum Jump: