Plus42 algebraic expressions update

[Thomas Okken]

I've been working on expressions in Plus42 (a.k.a. Free42+) for the last few days, and the equation editor is more or less done. Note that this doesn't actually evaluate or solve any expressions yet! But the equation list and editor was sufficiently complicated that I would like for some other people to take a look at what I have so far and get feedback.

The UI is modeled after the HP-17B and 27S (graciously provided by Bob Prosperi -- thanks Bob!). There are a few minor differences, but it should look pretty familiar.
The equations are stored in a matrix variable named EQNS, which is automatically created, resized, or deleted, as needed. If you have a list of equations, you can import them by copying the list and pasting it in Free42; this will create a matrix containing one string element for each line in the text. If you then save that variable as EQNS, the equation editor will recognize it. The process works in the opposite direction as well: RCL "EQNS" and then Edit->Copy, and you can paste the list into a text editor.

Again, the equations aren't actually parsed or evaluated yet. Work on that will start in the next couple of days, and I expect it to take a week or two.

Test builds are in the usual spot: https://thomasokken.com/free42/download/test/

UPDATE: Uploaded new builds at 10:00 PM EST, to fix a bug that was turning all the ALPHA sub-menu labels into the letter B...
UPDATE: Uploaded new builds at 11:40 PM EST, to fix scrolling behavior when pressing DEL.

[Thomas Okken]

One difference with the 17B/27S that I should explain because it isn't obvious: in the list view, the rightmost two menu slots are unused on the original calculators, and I added white up-arrow and down-arrow keys there.

The new arrow keys move the currently displayed equations up or down in the list, swapping it with the one above or below. They will first show the equation currently at that spot, that is, the equation that the current one is going to be swapped with, and then they perform the swap and move the view position to that new location.

I don't think you can rearrange the order of the equations in the list on the original calculators, and that seemed like an annoying omission.

[Vincent Weber]

Hi Thomas,

Awesome job as usual ! Much more useful than the big stack IMHO Very well integrated, and the reordering is a nice addition.
You were right to start with the wonderful 27S, please go all the way with the powerful L() and G() functions, the ITEM() function to retrieve data from a list (or matrix ?). Making it a L-value to assign elements (impossible of the 27S) would be a big plus.
And of course, being able to call such equations from a RPN program would be awesome

Cheers,

Vincent

[SammysHP]

With this I probably don't want to use my real HP 42S anymore.

[Vincent Weber]

I've just noticed that there are two new entries in the CATALOG. "STR" seems to be loaded with string management functions, and "DIR" mysteriously only countains "NOP" (which is also in "MISC").
Thomas, could you explain the rationale for this ?
Thanks a lot and cheers,
Vincent

[Thomas Okken]

Just uploaded new builds, fixing a data corruption bug in the row swap operations.

[Thomas Okken]

(02-25-2021 12:14 PM)Vincent Weber Wrote:  please go all the way with the powerful L() and G() functions, the ITEM() function to retrieve data from a list (or matrix ?). Making it a L-value to assign elements (impossible of the 27S) would be a big plus.

I didn't know about ITEM() yet, thanks for the reminder! But yes, array indexing is planned, including two-dimensional indexes so you can implement matrix operations. How would you use them as lvalues, though? It seems like that would only make sense inside L(). Do you have an example of how you would use it?

(02-25-2021 12:14 PM)Vincent Weber Wrote:  And of course, being able to call such equations from a RPN program would be awesome

Yes, that's the plan, equations should be able to call RPN programs and vice versa.

(02-25-2021 04:39 PM)Vincent Weber Wrote:  I've just noticed that there are two new entries in the CATALOG. "STR" seems to be loaded with string management functions, and "DIR" mysteriously only countains "NOP" (which is also in "MISC").
Thomas, could you explain the rationale for this ?

Directory operations. I haven't given a lot of thought to what functions that's going to require or how to integrate it into the UI, but while I was doing the CATALOG revamp anyway, I thought I should set aside a space for those functions.

[Vincent Weber]

Thanks Thomas.

Re ITEM, yes, one big let-down on the 27S is that L(ITEM(THING:I):J) triggers a syntax error, while it really shouldn't. This would enable true indirect indexing within the equation language, making it Turing compatible.

Also, it would be great to define functions rather than just equations, like DEF F(X,Y,Z)=X+Y+Z, and reuse them in either equations or RPN program. Now we are talking true programming

Cheers

[Thomas Okken]

(02-25-2021 05:32 PM)Vincent Weber Wrote:  Also, it would be great to define functions rather than just equations, like DEF F(X,Y,Z)=X+Y+Z, and reuse them in either equations or RPN program.

The DEF syntax isn't needed. The function already defines its formal parameters simply by using them, i.e. the mechanism by which the calculator decides which variables to show in the CALC menu.

The way I see it, you should be able to write, for example,

QUAD:X^2-3*X+2

Or

LBL "QUAD" MVAR "X" RCL "X" X^2 LASTX 3 * - 2 + END

and use both exactly the same way, calling them using XEQ, or from SOLVE or INTEG.

(An expression containing an equals sign would be evaluated by evaluating the LHS and RHS separately and then subtracting them from each other. I believe this is how the numerical solver in the 17B and 27S works as well. Conversely, an expression without an equals sign is interpreted by adding =0 to it when solved symbolically.)

[Vincent Weber]

Excellent Thomas, this is indeed as simple as it gets !

[Vincent Weber]

Playing with it a bit more, i noticed that not all functions are readily available in the equation editor. The 27S let you access HYP, PROB, CONVERT,... menus but Plus42 doesn't. Would be neat to access the CUSTOM menu with whatever functions are there, the general CATALOG function, the INTEG function (to solve integrals !) etc...

Here you can access the top row functions with the "TOP.FCNS" key, maybe a more direct way (if possible) would be suitable...

Cheers

[rprosperi]

(02-25-2021 05:39 PM)Thomas Okken Wrote:  The way I see it, you should be able to write, for example,

QUAD:X^2-3*X+2

Or

LBL "QUAD" MVAR "X" RCL "X" X^2 LASTX 3 * - 2 + END

and use both exactly the same way, calling them using XEQ, or from SOLVE or INTEG.

This beings up an interesting point - if the user has in fact created an RPN program and an equation with the exact same name, which would be used if invoked? It's probably best to not allow one if the other exists, to avoid ambiguity... then again that's also hard as what if you edit a program's name from something non-conflicting to something that does conflict, and other weird scenarios... Hmmm???

[Thomas Okken]

6:15 PM EST / 23:15 UTC -- Uploaded new build, fixing menu problems when the equation list became empty while no MVAR labels existed.

[Thomas Okken]

(02-25-2021 10:46 PM)rprosperi Wrote:  This beings up an interesting point - if the user has in fact created an RPN program and an equation with the exact same name, which would be used if invoked?

The easiest thing to do, and totally within the spirit of the HP-41C and HP-42S, would be to allow that kind of name clash and simply define which one wins. Duplicate alpha labels have always been allowed, and the rule is that the last one in memory is the one that gets called (being the first in the global chain, so the first to be found in the global label search). In that spirit, it would be perfectly fine to say that labels are searched first, and expressions second.

In practice, it may not even matter much. Labels are still going to be limited to 7 characters but equation names can be any length. The only reason why there is a 7-character name limit at the moment is that the CALC key in the equation editor is implemented by calling PGMSLV or PGMINT, and because of the way those invocations take place, the 7-character alpha argument length limit applies. But that limit could be worked around, and the internal variable where the current SOLVE or INTEG program name is stored could also be changed from <= 7 characters to unlimited. If people use long, descriptive names for equations, and short names for labels (even shorter than 7 characters in practice, if you want them to fit in a softkey label), name collisions need not be very common, I would hope.

[rprosperi]

(02-25-2021 11:32 PM)Thomas Okken Wrote:  

(02-25-2021 10:46 PM)rprosperi Wrote:  This beings up an interesting point - if the user has in fact created an RPN program and an equation with the exact same name, which would be used if invoked?

The easiest thing to do, and totally within the spirit of the HP-41C and HP-42S, would be to allow that kind of name clash and simply define which one wins. Duplicate alpha labels have always been allowed, and the rule is that the last one in memory is the one that gets called (being the first in the global chain, so the first to be found in the global label search). In that spirit, it would be perfectly fine to say that labels are searched first, and expressions second.

Sure, it's logical to allow both and document which one would be used, but I'll make a $20 bet a question will be posted in one of the forums within a few weeks of launch insisting there's a bug, because the author didn't read the documentation.

I can see no specific benefit of allowing both, but there are too many people with too many ideas about how to do things to say for sure that there isn't any benefit, so let's see if I win my bet.

[Thomas Okken]

(02-26-2021 12:01 AM)rprosperi Wrote:  Sure, it's logical to allow both and document which one would be used, but I'll make a $20 bet a question will be posted in one of the forums within a few weeks of launch insisting there's a bug, because the author didn't read the documentation.

I'm not going to take that bet, I might as well give you the $20 right now!

It is a bit of a no-win situation: either answer questions from people who don't understand the issues with duplicate names, or answer questions about the error messages you'd have to introduce if duplicates are going to be forbidden. I think it's six of one or half a dozen of the other...

My solution to this kind of thing is to write a FAQ entry, so when people ask me the question, I can reply to their email by simply sending them a link.

[rprosperi]

That's a good point, there would indeed also be questions requesting explanation of error messages. "What does 'Error: duplicate label' mean?" and of course this coming from a user that has in fact created the duplicates.

So you may as well do the most pure and consistent thing, and your example of allowing multiple program copies with the same name provides good guidance. Also, it's a lot easier to simply build it to follow your own design rules, rather than spending time and code trying to prevent some other behavior.

Thanks for the discussion. And keep the $20! You earned it!

[Thomas Okken]

1:33 AM EST / 6:33 UTC -- Uploaded new builds, including CONVERT, PROB, and CUSTOM menus in the equation editor.

Also, and completely unrelated to the equation editor, it includes the generalized comparison functions: X=? param, 0=? param, etc.
And the Y^X fix, and a new error code for RTNERR: 8 => Too Few Arguments... forgot to add that one when I added the big stack.

[SammysHP]

I would expect that the same resolution applies as for multiple identical labels. Still unclear whether equations or programs should get a higher priority...

[Werner]

(02-26-2021 06:37 AM)Thomas Okken Wrote:  it includes the generalized comparison functions: X=? param, 0=? param, etc.
And the Y^X fix, and a new error code for RTNERR: 8 => Too Few Arguments... forgot to add that one when I added the big stack.

What is the Y^X fix? (EDIT ah of course the sign of complex zero, silly me)
and I hope the other functions make it into Free42 as well?

Thanks, Werner