HP-71B Custom Key Definitions to save lots of keystrokes

[mfleming]

(02-10-2021 11:19 PM)Gene Wrote:  Just to add to the discussion, a reminder of Joe Horn's Calc>RPN article. :-)

After playing around with Calc mode for a few hours and reading this article, I'm fairly impressed. I like the interplay between Calc & Basic with DEF FN and variables. Making a mistake with Joe's Mach number formula and then easily correcting it was the clincher. I wonder what the effect would have been if this mode had been adopted for all of the HP algebraic calculators? A 17BII using Calc mode with variables and named formulas?

[Gene]

and please note: I don't really have a stake in this discussion. I don't use the HP-71B very often. But since CALC mode was being discussed, I knew Joe's remarks about it in the 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?

[rprosperi]

(02-11-2021 01:09 PM)Gene Wrote:  and please note: I don't really have a stake in this discussion. I don't use the HP-71B very often. But since CALC mode was being discussed, I knew Joe's remarks about it in the 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?

The RPN program!

But it's possible this had not yet been released at the time the article was published, pretty early in the life of the 71B.

[Erwin]

(02-11-2021 01:33 PM)rprosperi Wrote:  

(02-11-2021 01:09 PM)Gene Wrote:  and please note: I don't really have a stake in this discussion. I don't use the HP-71B very often. But since CALC mode was being discussed, I knew Joe's remarks about it in the 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?

The RPN program!

But it's possible this had not yet been released at the time the article was published, pretty early in the life of the 71B.

Sometimes I use the CALC mode for simple calculations and for this it is ok cause I have results in between and can so do checks if I‘m on the right way.
But yes the space for this function could’ve been better filled with more useful stuff
Regards Erwin

[Valentin Albillo]

            
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.

[J-F Garnier]

(02-12-2021 02:52 AM)Valentin Albillo Wrote:  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 [..]

... so I switched to fast reading mode to review your post.
Nothing really new in your criticisms of the CALC mode, but I will correct a few assertions that, despite being repeated since many years, are wrong.

Quote: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).

The CALC mode doesn't take 5 kB.
Here is the HP-71 load map, from the IDS vol.3:
1551F - 1632B AB%CLC CALC Mode
1632C - 16671 AB%BLD CALC Mode Decompiler
16672 - 16AAD AB%ED CALC Mode Editor
This makes a total of 5519 nibbles so 2.8 kB. Not 5 kB.

And not all of these 2.8 kB would be available if the CALC mode was replaced by something else, since there are several general purpose utilities and a few supported entry points (i.e. potentially used by external LEX files) in the CALC modules.
I would estimate something around 2 kB of code space that could be gained by removing the CALC mode.

Quote: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.

Yet another often repeated assertion without evidences.
It may be that some string functions, now available in the STRINGLX file, may have been considered for inclusion in the mainframe. But I see no evidence, no comments in the source files, no indications anywhere.

For the complex numbers - something you, Valentin, repeated very often - I don't share this point of view.
Complex number support has been planned since the beginning of the HP-71 design, and this is what permitted the nice integration of complex numbers in the language (see the difference with the complex number support in the HP-75 Math ROM for instance).

But I have good reasons to think that it was NOT planned to incorporate all the complex number processing in the mainframe ROM.
The disassembly of the Math ROM shows that the designers of that ROM had to either duplicate/rewrite some parts of the HP-71 mainframe routines, or use several tricks to use the existing mainframe routines. This is especially clear in the processing of the math exceptions for complex numbers, for which the mainframe routines are not designed for at all, they are just unable to independently manage exceptions related to the real and imaginary parts.
This is one of the causes of the quite large size the HP-71 Math ROM.
So my opinion, based on my observations, is that the complex arithmetic has not been removed from the mainframe, it has never been in it, and probably never been planned to be in it. I believe that the marketing plan since the beginning was to have it in a Math ROM (following the same extension scheme as for the HP-41, HP-75, Series 80 and others).

J-F

[Gene]

Thanks to all, but especially Valentin and JF for their insightful responses.

I think it will do good for the future having all of this in one place, which has now happened.

Again, thank you. I was curious and not attacking or defending CALC mode. :-) I cannot remember the last time I used it.