Re: HP's and TI's calculator output rate

[Prev][Next][Index][Thread]

Re: HP's and TI's calculator output rate

In article <35D45B83.9DB83000@you.dare.spam.me>,
Richard Goedeken <IBM Corporation> writes:

> Say you wanted to do 1+2+3+4+5+6+7+8+9 (hypothetical example)..

> As fast as you can, hit 1<enter>2<plus>...

  I mis-read this the first time, so I guess I now need to delete
  a couple of paragraphs...

  All that a $5 calculator has to do, at the end of each operation,
  is to display one numerical value, generally using common 7-segment
  numerical display digits.  This can usually be done quite rapidly,
  although if done *too* rapidly, the user fails to get a slight
  "blink" as feedback that the calculator has even responded.

  The HP48, on the other hand, has to actually parse, compile and
  execute the entered text string upon each press of Enter or
  a command key, then it must re-display a complete screen,
  including interpreting up to four stack objects, decompiling each
  object (of which there are more than 25 different types), producing
  a dot-matrix display for each character, plus six graphic objects
  for the menu keys, a directory path, status annunciators, and
  possibly a clock display.

  The simpler calculator usually does not have key buffering at all;
  if you press a new key while a previous calculation is in progress,
  which is quite possible on many calcs, your keystroke is often
  simply not recognized.  The HP48 has a key buffer (pipeline)
  of about 15 keystrokes, I believe, and it beeps if you
  manage to outrun it (which I hardly think that you can
  manage to do during the one millisecond that most common
  floating-point arithmetic operations require to execute,
  although you can do so if your keystrokes require far longer
  processing, such as solving equations or re-arranging formulas).

  Screen updating is almost always suppressed if the key buffer
  is not empty, so even the above-mentioned display operations
  are eliminated if there is any other processing to be performed.

  N-key roll-over is also performed (press down 7 then 8 then 9,
  then release 7 then 8), which is not universal among all calculators.

  Still, HP has always seemed to target itself to be adequate for
  the data entry speed of engineering and scientific users, but not
  to keep up with all 120-wpm typists; it is not hard to outrun an
  HP16C's ability to catch up with digit keystrokes, but generally
  only an experienced accountant can manage it.  The HP48 never
  fails to keep up with me, unless I type way ahead while long
  programs are running.

As to the style of entry, which may not have been the issue intended
to be raised, but is a tangent I happened to get off on anyway:

As we have noted a great many times before, the first "adding machines"
tended to have some kind of crank, lever, or button for the operations
of mechanical addition and subtraction; generally the "+" key
(or lever, etc.) caused the *previously* keyboarded number
to be immediately added (or subtracted if "-"); this is
in fact the same as RPN: first you specify the new value,
then you cause the operation using that number to be performed.

It would have been ridiculous to try to make mechanical calculators
work in the opposite order; that is, to first tell the machine
what operation you were *going* to soon perform (but were not
ready to do yet, because you didn't yet have the next value
ready to be operated upon), and then expect the machine
to remember which operation to perform later on,
when you pressed yet another *future* operation key
(or an "equals" key, which didn't exist on mechanical calculators,
for this very reason).

Amazingly enough, people used such calculators for quite a long time
before good old TI came out with the first electronic calculator
that remembered parts of formulas, and carried out the
operations later on, after more data had been input;
this calculator had a new orange key on it:
yep, the first "=" key (not "+=" or "-=", but just plain "=").

Such is the power of common habit and custom that any variation
may strike us as a discomfort; for example, how many North
Americans touring in Great Britain are found waiting on
the wrong side of the road for a bus, because the customs,
as to which side of the road vehicles drive on and
the bus stops on, are exactly opposite; drivers from
either country are no doubt equally ill at ease
on the roads of the other country, and perhaps
very commonly make a few mistakes at first.

Either place is equally comfortable for its inhabitants,
however, and a seasoned traveler can no doubt make himself
equally comfortable anywhere, after having broadened his
personal experiences to become acquainted with other ways
of accomplishing similar things.

Anyway, I can add up the hypothetical numbers you mentioned
on any algebraic calculator; here's how I do it:

1 + 2 = + 3 = + 4 = + 5 = + 6 = + 7 = + 8 = + 9 =

Well, some day I may remember that I don't have to press "="
every time; likewise, HP users needn't press "Enter" every time.

There -- we're "even" on this one :)

-----------------------------------------------------------
With best wishes from:   John H Meyers   <jhmeyers@mum.edu>
Follow-Ups: References: