Little explorations with HP calculators (no Prime)

[DavidM]

(02-19-2018 08:03 PM)pier4r Wrote:  Is John H Meyers still active? It is impressive how many 48/50g-based contributions he made that pop ups in searches (same with DavidM, Joe Horn, James Prager and the like)!

edit: if someone knows better replacements to INFORM, please share!
edit2: if you wish to put INFORML and INLIST in port2, remember to edit INFORML to call :2:INLIST and your program to call :2:INFORML . (on the calculator :2:INLIST shows up as :2: INLIST with a space. Dunno why)

First, please don't place me in the same sentence as Joe, James, and John. I may have posted a few more times than I should have, but those three (and many, many others) are far more knowledgeable, helpful, and entertaining than I would ever dream to be.

As for John Meyers, it does appear that shortly after he stopped posting to comp.sys.hp48 (and comp.mail.eudora.ms-windows), there was a death notice for someone with his name from Fairfield, IA (the location of his employer). I don't know for sure that this is the same person, but given how prolific he once was I suspect it's a good likelihood.

[John Keith]

I too miss John H. Meyers. I always looked forward to his posts on comp.sys.hp48. Several of the programs he posted are still on my HP50.

[pier4r]

Thanks for the (sad) info about John H. Meyers . I read it at the time but I did not reply.

--

Another question. While I am porting little procedures that I find interesting in one userRPL directory, see this thread, I realized that I would like to integrate an "help" when the user provide no arguments or not enough of them (the type/size/dimension checking comes later, if at all).

This is what I do when I make bash/shell/scripts that interact from the keyboard. I check the number of arguments, if those are not enough, I throw an error message that is the usage of the command.

On the 50g if one provides no argument one gets the standard error "too few arguments". Is it possible to catch this error?

I did not try but the first thing that I thought is to make an IFERR around the entire program such as the following example

Code:


\<< IFERR 
  \<< 
    \-> 
    var 
    \<< 
      program 
    \>> 
  \>> 
  THEN
  "explain the usage"
  END 
\>>

anyway has anyone already experienced this situation? What was the solution?

[DavidM]

(03-10-2018 11:36 AM)pier4r Wrote:  On the 50g if one provides no argument one gets the standard error "too few arguments". Is it possible to catch this error?

Using an IFERR structure to encapsulate your code would work, and you can even use ERRN (or ERRM, but not as efficiently) to determine what the actual error was that occurred. That would allow you, for example, to branch in different directions depending on exactly what error condition was triggered. Error trapping is a nice feature on the RPL machines that can improve the usefulness of programs when applied correctly.

However...

You could also use the approach used by most built-in commands, which is to check both an argument count as well as the types of those arguments at the beginning before proceeding. The basic premise of this model is that if you know the arguments are good at the beginning, the rest of the program flow should guarantee that intermediate results will always match what is needed as the program proceeds. This is exactly what almost every UserRPL command does internally -- arguments are checked at the beginning, then operations are performed knowing that all intermediate results should be in place as expected until the command completes. Once control is passed back to the whim of the user, all bets are off, so the next UserRPL command has to perform all the checks again since it can't assume that everything is where it needs to be.

The fact that most all UserRPL commands do this is both good and bad. Good in that the commands are robust, but bad in that all of this checking going on at each and every step slows things down. This is actually one of the biggest reasons that SysRPL programs generally run faster than UserRPL: they only check the arguments at the beginning, and the rest of the commands simply execute with no safety checks on the arguments given to them.

The DEPTH and TYPE commands can be used to check argument counts and types, but you would have to customize your code around them. It's also possible to generalize this concept by providing your own sub-program that could be more generic. Something like the following could be useful:

Code:

ARGCHK
\<<
  0. ADD DUP SIZE \-> at ac
  \<<
    IFERR
      ac \->LIST
    THEN
      DROP ERRN DOERR
    ELSE
      DUP 1 \<< TYPE \>> DOSUBS 0. ADD
      SWAP LIST\-> 1 + ROLL
      IF at SAME NOT THEN #202h DOERR END
    END
  \>>
\>>

ARGCHK takes one argument: a list of types as defined by the TYPE command. So some examples of how you might call it are as follows:

Code:

@ check for two strings on stack
{ 2 2 } ARGCHK

@ check for a string, a list, and a binary integer
{ 2 5 10 } ARGCHK

@ check for an approximate number
{ 0 } ARGCHK

Additional objects above the expected ones are ignored, but anything else (including -nothing-) in the indicated stack levels will raise an appropriate error.

One of the issues you run into with this type of argument checking is that exact integers and approximate numbers have distinctly different types (28 and 0). So your program may work just fine with either of them, but you would have to adjust how you check for them to make sure that needless errors aren't generated. This could be done in a variety of ways, including creating your own "type number" to represent both numeric types and replacing the subroutine being passed to DOSUBS above to create that type when appropriate. Similar issues arise if you start to consider units and tagged objects as well. These are all things to keep in mind, and perhaps one of the reasons that not many UserRPL programs are written with these kind of checks.

[pier4r]

DavidM, once again a useful contribution that hopefully won't help only me!

--

Switching to another topic. So while I am going through the 50g user guide for possible procedures to integrate in the other thread ( http://www.hpmuseum.org/forum/thread-10271.html ) I read at page 10-11: RDM provides a more direct and efficient way to transform lists to arrays and viceversa, than that provided at the end of Chapter 9

I think the manual here has a little typo. As RDM should be good to transform a row vector in a column vector, as done in chapter 9, but no list is accepted as argument.

On a side note it is incredible how such relatively "little" documentation (about the 50g: user guide and AUR , 2 documents, 1600 pages or so) is virtually endless. I constantly learn or relearn concepts (ex: a command) or techniques, also thanks to the discussions here, and I checked it over the course of at least 3 years (2011, 2013, 2017-2018) if not more.

This let me think that, at least in my case, hoping to know "well" even the standard library of a modern programming language or framework is hopeless (not only IT stuff, can be a framework of math formulas, or definitions of a technical field or what not). I wonder how many interesting pieces I still miss from the two main manuals of the 50g. And I used "interesting" with a reason, as I can understand I miss all the info about, say, "graphics" as long as I am not interested in it.

[DavidM]

(03-11-2018 12:07 PM)pier4r Wrote:  I read at page 10-11: RDM provides a more direct and efficient way to transform lists to arrays and viceversa, than that provided at the end of Chapter 9

I think the manual here has a little typo. As RDM should be good to transform a row vector in a column vector, as done in chapter 9, but no list is accepted as argument.

I agree with you, Pier. That "note" doesn't seem to make any sense as written, at least with the current implementations of RDM and AXL. It does make me wonder if the design of one (or both) of those commands was changed or added after the note was originally written into the documentation. Perhaps that note somehow survived the editing process.

[Neve]

On a side note, I like the title with the (No Prime) at the end.
You’re right, you meant “REAL” HP calculators. ;-)

[pier4r]

No. It was added later to differentiate from this thread: http://www.hpmuseum.org/forum/thread-9096.html

Otherwise this was "little explorations with HP calculators" , but since the Prime has its own section, it won't be fitting here.

And we have different views of "real", for me anything that fits my needs is ok. For example for portable (that is: android, windows, mac; mostly android though) heavy number crunching I find the prime more fitting than other alternatives. As the alternatives are not that portable or locked down or missing flexibility.
I wrote more about it on the forum somewhere.

(03-11-2018 06:25 PM)DavidM Wrote:  I agree with you, Pier. That "note" doesn't seem to make any sense as written, at least with the current implementations of RDM and AXL. It does make me wonder if the design of one (or both) of those commands was changed or added after the note was originally written into the documentation. Perhaps that note somehow survived the editing process.

Yup. I thought the same. Especially because in the user guide AXL is briefly mentioned, then there are even creative but long commands to convert lists in a matrix, while with AXL is extra immediate.
See http://www.wiki4hp.com/doku.php?id=rpl:start "lists2matrixColumnsNo4" vs "lists2matrixColumns"

[pier4r]

First time I read the FAQ of comp.sys.hp48 . It was really well done, but how many dead links (another point for p2p backups).

https://groups.google.com/forum/#!search...yvJb5riSgJ

Also finally I understood what is this mythical "HP BASIC". Is the algebraic input mode on the 49/50g series. It makes sense, a bit. Although it is clumsy compared to the userRPL.

Plus the sysRPL and Saturn ASM / Arm ASM (coming later) seem, from that FAQ, not really designed by HP to be used outside HP itself.

[pier4r]

Little note about a quality of the RPL language that I am seeing mostly now. Now I can compare with calculators that should be able to compete with the 48/49g/50g series.

I started to consider again the ti89 some months ago and then I added to my arsenal a ti nspire clickpad (2006-2007) a casio 9860g and a 9860GII.

The difference between RPL and the TI-basic / Casio Basic is huge. While ti-basic and casio basic surely can do a lot, the RPL has a lot of flexibility, as passing entire program objects as arguments to the next program. As far as I know with casio/ti basic that is impossible or not immediate to achieve.

Of course then the casio-s have the official C SDK while the TI have community based programming languages (or lua on the nspire, super clumsy to use), but in my case I am comparing the designed programming language for the average calculator user.

The ti89, the 9860g series and the nspire can do a lot of things that the 50g does as well, and maybe something better, but in terms of user programming - in my opinion - the RPL (and its library of commands) may be not faster, but much more expressive.

The RPL is really impressive. Another gem that was not ported by HP on common computers (although we have now rpl/2 and likely newRPL).

Question to the RPN masters. Can one pass functions to a RPN program? For example a label that then is used by the program to recall another program. In other words the main program doesn't know a priori which other program to call, this will be defined by the value of an argument.

Question to the 71B masters. Can basic on the 71B - another environment that I recently discovered and I got impressed by it - receive a program (or a reference to a program) as an argument?

[Thomas Okken]

(03-16-2018 07:48 PM)pier4r Wrote:  Can one pass functions to a RPN program? For example a label that then is used by the program to recall another program. In other words the main program doesn't know a priori which other program to call, this will be defined by the value of an argument.

You can pass a label number as a number, and a label name as a string. Store in, say, register 00, then call them with XEQ IND 00. The only limitations are: can't call local alpha labels this way (A-J and a-e), nor global labels with names more than 6 characters long.

EDIT: I am assuming you're talking about the HP-41 or 42S here, those obviously being the only RPN calculators you should be using for serious programming. Although some (not all) other RPN models also support indirect calls, like the 19C/29C or 67/97.

[Dieter]

(03-16-2018 07:48 PM)pier4r Wrote:  Question to the RPN masters. Can one pass functions to a RPN program? For example a label that then is used by the program to recall another program. In other words the main program doesn't know a priori which other program to call, this will be defined by the value of an argument.

Sure. This has been done since the Seventies when the first programmable calculators with indirect addressing were available.

You can pass a label number on the stack, or with calculators like the HP41/42 a program name in alpha, and this can then be called indirectly.

Example for HP41: call an equation solver with two guesses (1 and 2) in X and Y and the function to solve ("MYFUNC") in alpha

1
ENTER
2
"MYFUNC"
XEQ "SOLVE"
...

LBL "SOLVE"
STO 02
X<>Y
STO 01
ASTO 00
RCL 01
XEQ IND 00
STO 03
RCL 02
XEQ IND 00
STO 04
...

LBL"MYFUNC"
X^2
2
–
RTN

You can even do this with an HP67: simply pass the label number. The called program stores this in register I and then does a GSB i. This is also possible for LBL A ... LBL e which are encoded with index 10...19.

Dieter

[pier4r]

(03-16-2018 08:24 PM)Thomas Okken Wrote:  EDIT: I am assuming you're talking about the HP-41 or 42S here, those obviously being the only RPN calculators you should be using for serious programming.

Thanks to you and Dieter. I forgot indirect calls, and yes, that's it. So now I have also to check whether ti basic/casio basic have indirect calls.

Now little question about the 41/42 observation above.

While reading the hpjournal I realized that the 41 was a little monster due to the expansion roms and the ability to control various other devices thanks to the clever HP IL interface (that survived for long time).

The 42S, for the little that I know, was a powerful calculator but limited, as one had no expansion ports. (although it had the saturn like the 71B and the 48)

So could one say that all in all the 41 was better?

Little note, thanks to wikipedia here https://en.wikipedia.org/wiki/HP_Saturn - how many things I still discover so late - I got to know that the saturn family as well as the 50g ended also due to the fact that was not anymore economical to produce the main CPU/SoC. I wonder if they could still produce the saturn, as the ti is still somehow getting the 68k or the zilog z80, they would still produce saturn models or not.

[3298]

(03-16-2018 09:10 PM)pier4r Wrote:  So now I have also to check whether ti basic/casio basic have indirect calls.

The Casios don't. Since you've asked this elsewhere too: No timing functions either. The incredibly limited programming language is one of the reasons my Casios haven't seen much use since your benchmark project 5 1/2 years ago. (Well, the AFX is dead anyway, but the 9750G+ is still operational. It's been on loan to my sister for school, but she's kind of the polar opposite of me regarding math affinity, so I fully expect its memory to be in the state I left it in.) The 50g simply beats them in pretty much any respect, except maybe in the category "working the way clueless lazy math-hating pupils expect it to". But again, it even has an algebraic mode for those...

The Casios limit labels to 38 per program (0-9, A-Z, r, theta), which can only be directly called with a Goto command. There is a Prog command to call other programs (only directly by name, and programs cannot be written or read by other programs), but the return stack is limited to about 10 levels, making it mostly useless. Most variables are limited to real or complex numbers (this includes all 28 regular global variables, the cells in matrices and lists, and the special-purpose variables for statistics, graphing, and so on). Starting from OS version 2.0 for the 9860 series, there are 20 string variables, but the string processing commands are quite limited (notably, no parsing is possible). The closest you can get to passing programs around is by using one of the 20 graphing function slots (Y=, r=, Xt=/Yt=, depending on coordinate mode: Cartesian, Polar, Parametric) or one of the 6 (up to CFX series, which includes my 9750G+, but not the 9860-based 9750GII) or 20 (starting from AFX) general function slots (tucked away in one of the last submenus of the OPTN menu, try finding that without help) to hold your formula. Those forbid command separators, though (newline, colon, and the little triangle that displays the result of the preceding command, waiting for EXE to be pressed), and many commands are also forbidden inside these (including Goto and Prog ).
Did I mention that there are NO local variables? Yeah, that's right. It's not so bad when your programs always initialize their stuff on startup, but when you start thinking about persistent storage, the nightmares about finding variables not used in any other program will begin.
While I'm ranting, I might just mention that spaces outside strings cause syntax errors. No code indenting for you! At least the no-empty-commands rule has been relaxed, so starting from the AFX series double newlines are acceptable.

I don't know much about TIs, having never wielded one, but I'd assume they're just marginally better. I just know that after the simple ASM programmability of many older series, on the NSpire there's a war raging between the community exploiting flaws to run native code (which spawns cool stuff, check out Ndless), and the company using 2048-bit RSA bootloader-validated (can't change that, it's in true ROM) signatures for their firmware, downgrade-locks and other drastic measures to suppress native code execution, for fear that it might be used to bypass the exam mode and therefore get the calculators banned on exams. Casio and HP seem much less concerned at least.

[Csaba Tizedes]

(03-17-2018 12:27 PM)3298 Wrote:  

(03-16-2018 09:10 PM)pier4r Wrote:  So now I have also to check whether ti basic/casio basic have indirect calls.

The Casios don't.

That is why I like the older CASIO units, like 4000P. If you want a good CASIO, this is the last one which can do all the functions like new ones but this is small enough to fit into your pocket.

For this small calculator with its indirect variable addressing you can write programs like a first-fit packing algorithm or bubble sort - just for fun. This is my only calculator which I programmed a very accurate sunrise-sunset algorithm. I really like it.

Unfortunately no any improvements in the CASIO line since 1990's. Like ProTrek watches.

Csaba

[grsbanks]

(03-16-2018 09:10 PM)pier4r Wrote:  Thanks to you and Dieter. I forgot indirect calls, and yes, that's it. So now I have also to check whether ti basic/casio basic have indirect calls.

I've not followed this thread in its entirety so I'm not sure which "dialect" of TI-Basic you mean.

If you mean the 68k version (TI-89 and 92 families of calculators) then the answer is an emphatic "YES!!" The indirection operator is the hash sign '#'. E.g.:

Code:

"funca"->funcb
2x^2->funca(x)

So, store the string "funca" in variable funcb and then define a function funca(x) that returns 2*x^2.

Code:

funca(10)  --  gives you 200.

#funcb(20)  --  gives you 800

[John Keith]

(03-17-2018 12:27 PM)3298 Wrote:  I just know that after the simple ASM programmability of many older series, on the NSpire there's a war raging between the community exploiting flaws to run native code (which spawns cool stuff, check out Ndless), and the company using 2048-bit RSA bootloader-validated (can't change that, it's in true ROM) signatures for their firmware, downgrade-locks and other drastic measures to suppress native code execution, for fear that it might be used to bypass the exam mode and therefore get the calculators banned on exams. Casio and HP seem much less concerned at least.

Well, except for the Prime...

[pier4r]

Many thanks 3298 (especially all the casio related info, see n1 ) and grsbank. So Ti basic can do indirect addressing, interesting. I find the ti89 still viable, the nspire is quite a closed system without the ti software, but the ti89 has no usb power supply ability :/.

A question still remains.
Question to the 71B masters. Can basic on the 71B receive a program (or a reference to a program) as an argument? Or can do indirect addressing?

n1: although C.basic is quite some work to fix the shortcomings of the official basic system. I do not know if there exist any other "community programming languages" that are well done. Surely what you wrote, 3298, will help me to put on the casio only what is likely mostly a problem that on a non programmable calculator will be too tedious to type.

[pier4r]

Due to what I wrote here: http://www.hpmuseum.org/forum/thread-855...l#pid93245

sometimes I have the feeling that I need multiple 50g-s running (emulators at the moment are not an option). So in the past I let slip 40-50€ offers, but I have to say that since some months the price of a 50g just exploded everywhere. Ebay, ebay classified shows an average of 100 Eur (I can get 50g new for that price, at least here in europe).

Once again I damn myself for the 40€ offers not taken, even if the budget was short.

I have two 50g, but having a third as backup of the backup wouldn't be bad. Especially now that I see that the RPL is difficult to substitute and the newRPL still needs the 50g.

I am doomed. https://en.wikipedia.org/wiki/Vendor_lock-in

[3298]

(03-17-2018 02:37 PM)grsbanks Wrote:  So, store the string "funca" in variable funcb and then define a function funca(x) that returns 2*x^2.

Code:

funca(10)  --  gives you 200.

#funcb(20)  --  gives you 800

Sounds quite similar to the function slots on the Casios so far, though I'd like to know if the TIs' # operator is as crippled as the Casios' functions, i.e. can it be used to call full-blown programs with loops and all the fancy things, or does it only permit a single value-returning command?

(03-17-2018 08:00 PM)John Keith Wrote:  Well, except for the Prime...

Granted, it doesn't directly allow native code to be run inside the OS as it currently is, but you can replace the firmware with no fuss at all. As far as I know, the current options beside the official firmware versions have not gone beyond proof-of-concept stage (i.e. they say something like "Hello World" and stop), but there's nothing like TI's RSA signatures blocking Claudio from making the Prime a NewRPL target. Okay, I've not seen a lot of hardware documentation, but at least HP isn't actively trying to stop us.

(03-17-2018 08:55 PM)pier4r Wrote:  although C.basic is quite some work to fix the shortcomings of the official basic system. I do not know if there exist any other "community programming languages" that are well done.

I can't comment much on C.Basic, but the dev's English leaves quite a bit to be desired. Several of his posts left me with question marks hovering above my head.
Other languages on Casio calcs include Lua (via LuaFX for 9860, or LuAFX for, well, the AFX), which I've not used because it was published after my AFX broke, and the good old MLC (an ambitious project to invent a game-focused programming language that runs on several different calculators, even across brands). I had a lot of fun with MLC back when my AFX worked, but I wouldn't recommend using it now - it's dead. The programs I wrote about 8-10 years ago were probably among the last MLC programs to ever be written. At that point, the main hub for MLC activity had already been down for years (according to the Wayback Machine, it gradually went down in 2006; hosting expired in October of that year), rendering much of the relevant content unavailable. Regarding actually supported calculators, the only complete interpreters I've seen were for Casio AFX and TI86 (the latter with additional commands but sadly also some incompatible changes). A Casio 9860 version exists, but it's unfinished and abandoned, just like most of the other interpreters. To get the topic back to HP: a version for the 48 or 49 (don't remember which) was also started, but as far as I know it was abandoned even before the first alpha release, presumably due to lack of interest - unlike TI and Casio calculators, there wasn't much room for improvement over RPL.