Hi,
Gene (and all interested readers, be warned that this is very long):
(02-11-2021 01:09 PM)Gene Wrote: [ -> ][...] since CALC mode was being discussed, I knew Joe's remarks about it in his article would be relevant. Questions are...
1) What points does he make that overall we would now think are incorrect?
2) What did he overlook that makes CALC less useful than he thought?
I feel that writing about
CALC mode is a complete waste of my time, the subject matter doesn't deserve it and I've far better things to do, but being precisely
you the one who asks some questions about it, it's my pleasure to comply and give my answers, with the kind permission of
Mr. Prosperi who is the
OP, as this will necessarily be off-topic. Let's begin:
Joe has several sections in
his article, beginning with
"The good point and bad points of AOS",
"The good points and bad point of RPN",
"The bad points of both AOS and RPN", and then
"The HP-71B is neither AOS nor RPN", where he then enthusiastically posits and discusses numerous advantages of
CALC mode many of which are either incorrect or misleading.
It's not so much that he plainly lies but he doesn't tell the whole truth either, because he doesn't know better or because telling the whole truth would severely weaken or destroy his points. The following points
1-11 are in part quoted from Joe's article and in part my additional observations. Let's see:
1. "CALC is true algebraic logic". So is evaluation out of
CALC mode, directly from the command line, so no advantage here over what command-line evaluation already offers without having to waste
5 Kb.
2. Command-line evaluation gives no intermediate answers. First, nothing forbids you from simply
concatenating several expressions in the command line so that you get as many intermediate answers as you need. Second, consider the often-mentioned
Mach example which Joe uses too, namely:
Would you really want to slow down computing this value by seeing and supposedly checking intermediate results one at a time, or would you rather simply press
[ENDLINE] and get the answer immediately ? And if you need checking, surely checking
once the whole expression for typos would be much
faster and easier. Try it, it's not difficult at all: from the command line key in:
SQR(5*(((((1+.2*(350/661.5)^2)^3.5-1)*(1-6.875E-6*25500)^(-5.2656))+1)^.286-1)) [ENDLINE]
.835724535179
The bottom line is, not every calculation requires you to see and check every intermediate subexpression, most of the time you just evaluate the whole expression right away and that's it. For the few times you need intermediate results, simply concatenating the subexpressions in the command line will provide for it with no significant extra complexity.
3. "But the best part of CALC mode is the "command stack". Joe makes quite the point of telling and demonstrating once and again how wonderful, magical the
"command stack" is. What he fails to tell is that the
command stack is
not a feature of
CALC mode and can be used equally effectively system-wide, in particular when evaluating expressions from the command line. But he doesn't tell, he lets the interested reader (who probably hasn't got an
HP-71B to try at leisure) to believe that this
command stack is a
CALC mode feature. Well, that's seriously misleading.
4. "CALC Mode lets you edit what's going on". Well, again so does evaluation from the command line, you can edit any portion of it before pressing
[ENDLINE] and you can edit any portion of it after pressing
[ENLINE] by recalling the evaluated expression from the
command stack to the command line. Again, seriously misleading, putting medals where none are deserved.
5. It's a visible stack, practically unlimited (96 characters long). So does command line evaluation. And
"practically unlimited" ? Don't make me laugh. Just try adding up the grocery's list of items and you'll hit a distracting error after just a few items, as we'll see next.
Joe also insists in the usefulness of
RES for reusing a result or continuing a long calculation but (again!) forgets to mention that
RES is also available elsewhere, including command-line evaluation and programs, so no
CALC mode advantage here either. More medals ...
6. "But that's not all ! You can even define your own functions in BASIC (DEF FN) and call them in CALC mode !". Again, utterly misleading. This is not a feature of
CALC mode but is perfectly usable in command-line evaluation out of
CALC mode. And Joe
"cheats" when he says:
"All you have to do is type DEF FNP(N,R)= [...]
which makes the readers think you can define a function
directly from the command line or
CALC mode (remember, the vast majority of readers had
zero experience with an actual
HP-71B), which is
not the case. You need to enter a
numbered program line with the definition in the current
BASIC program file, i.e.:
30 DEF FNP ..., which you must do
out of
CALC mode.
7. "EXAMPLES". The
"coup de grace" tells you to change
8.33 to
9.33 in some expression and then asks you to try that on the
HP-41 or the
TI-59, and makes you think that the easy editing is a feature of
CALC mode, which it isn't, you can edit likewise out of
CALC mode. Same with the following two examples, always
misleading and always comparing
CALC mode with the
HP-41C or primitive one-line numeric-display
AOS,
never with normal command-line
HP-71B evaluation out of
CALC mode.
As for relevant
"Examples" Joe forgot, it's funny that Joe didn't see fit to include the
"grocery list" example, which goes like this:
You return from the mart with a long list of items you've bought (typically 40-50 or so) and want to check that the
total is correct, so you get your
$0.95, 4-banger which only does basic arithmetic with 8 digits, and proceed like this:
item1 [+] item2 [+] ... [+] item40 [=]
and there you are, the desired
total. Now you feel daring and use your
HP-41 to do likewise, and proceed like this:
item1 [ENTER] item2 [+] item3 [+] ... item40 [+]
and you get the total, too, in a most natural
(RPN) way. Now, you enter the
Mother Of All Calculation Systems, aka CALC Mode and confidently proceed like this:
item1+item2+item3+ ...
and then, after perhaps some
10 items or so, you get out-of-the-blue a
totally unexpected error message,
"Line too long", which will get you completely
confused as to what just happened, and once you realize, you'll have to probably
delete the last item and evaluate the incomplete sum, then start a new expression to add up
another 10 items, careful of not getting the error message again, and so on for
another 10 items and finally
another 10 items.
In other words, the super-powerful
CALC mode
can't do what a
$0.95-cent 4-banger or
any RPN/AOS calc could trivially do with utmost ease.
And correcting the
"Line too long" was possible in this addition problem by backspacing the last item. If you were instead computing a complex expression (think Mach number) it surely won't be that easy to know how much backspacing is needed, adding to the confusion and worse, diverting your mind from the actual problem you were solving in the first place.
8. Confusing errors and confusing messages. This is best explained with an example right out of the
Owner's Handbook, where HP tries and juggles with confusing situations that very easily arise when using
CALC mode. Read carefully the text in this
first image
without peeking at HP's explanation in the
second image, and see if you understand what's happening:
Did you recognize what was
wrong and how to solve it ? HP's
messy explanation is ...
Another confusing message can arise due to the
"intermediate results" feature, which means that the part just evaluated is
replaced with an intermediate result and you might forget the last characters you keyed in and go on with an operator and get an unexpected
"WRN: Precedence" message (see the example in the
Owner's Handbook). This can't happen with normal command-line evaluation because you see the
whole expression all the time and thus you don't lose sight of what you just typed.
9. Unsupported operations. Joe says very little, if at all, about the many important operations that are perfectly supported in command-line evaluations but which
CALC mode doesn't allow, among them:
- strings and string functions, even if the result is numeric
- the Decimal and Hexadecimal conversion functions
- multi-line user-defined functions
- any and all statements (say FIX 4), except for assignment (A=).
This last one means that if you want to change the display setting (say from
FIX 4 to
FIX 6 or to
STD to see more digits or whatever), you
must do it
out of
CALC mode, so having to change the setting several times in a calculation will have you getting
in and
out of
CALC mode repeatedly. Nothing like this is necessary in normal command-line evaluation.
10. The dangers of CALC mode. If
CALC mode is such a fine piece of programming, you'd expect that using it wouldn't harm the system's integrity no matter what, and most especially not in case the user makes a casual mistake. But here's what the
Owner's Handbook says about this in
pag. 37:
CAUTION
Do not insert or remove a module when CALC mode is on. Doing so will cause a memory reset (loss of memory).
so the user simply forgets that
CALC mode is on, inserts/removes a module and puf ! all the valuable programs and data in the whole machine go to never-never land, which in a machine without easy access to external mass storage (an expensive card-reader with 650 bytes per card or an unaffordably expensive tape reader) simply means utter
disaster. This is completely
unacceptable and reason enough to never use
CALC mode and risk having all programs and data erased because of a moment of absentmindedness.
11. "THE VERDICT, PLEASE."
Here it is:
CALC mode is an unneeded, wasteful abomination.
It takes
5 Kb ( ~8% !! ) of ultra-valuable
System ROM space, which could have been used to implement all the
string functions the
HP-71B is seriously lacking (the ones in
STRINGLX take as little as 800+ bytes) and/or
complex arithmetic and/or
matrix operations and/or full
Boolean operations (like the ones in the
HP-IL ROM) or even
extended I/O operations (like the ones in the
HP-IL ROM, of course).
Complex arithmetic and
string functions were intended for the mainframe
System ROMs but had to be
removed to make room for this
stupid,
useless abomination called
CALC mode, which could have been made available in a
LEX file or
ROM or whatever instead, but wasn't because of imbecile marketing people and possibly someone's ego trip.
Last but not least, Joe adds as a final remark:
"I think there should be machines [...] and nothing but CALC logic. Forget RPN. It was nice while it lasted."
The facts are,
CALC mode was mostly
despised and
forgotten and never used in
any other machine many decades ago, yet
RPN is still very much
alive, liked and thriving and many pèople use nothing else for their quick daily calculations, including
adding up their grocery lists.
Joe wrote the above in
January/February 1984 but as stated in:
The HP-71B “Math Machine” 25 Years Old
it seems he thought just the same
25 years later, so the excuse of
"young" or
"inexperienced" doesn't quite cut it.
That's all,
Gene, sorry for the length but, well, you asked !. For my part, I'm done with
CALC mode's discussions.
Best regards.
V.