# HP Forums

Full Version: Plus42 Equations, Preview Release
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I just posted an update to Plus42 that includes full equation support.

(Latest Documentation: see here.)

The equation mode can be reached through the white [=] button in the SOLVER, ∫f(x), and PGMMENU menus. Equation objects can created in the equation editor, or by placing a string in the X register and converting it to an equation using the PARSE function, and they can then be passed to PGMSLV, PGMINT, VARMENU, and EVAL.

The CALC option in the equation editor performs PGMSLV if the editor was entered via the SOLVER menu, PGMINT if it was entered via the ∫f(x) menu, and it places the equation in both ALPHA and X and starts program execution if it was entered via PGMMENU.

When the solver is used with an equation, it supports direct solutions, using the same kind of algorithm, and the same restrictions, as the solver in the HP-17B and its ilk, and otherwise, it falls back on the familiar numerical solver.

In equations, you can use the full set of functions listed in Martin Hepperle's document "About The Solver in the HP Pocket Calculators," except for the financial functions.

There are a couple of additions to allow equations to call user programs and other equations: XEQ(NAME:X:Y:Z) calls LBL "NAME", assigning the parameters to the program's MVAR variables, if it has them, and pushing them on the stack otherwise; and NAME(X:Y:Z) calls an equation declared with a name and parameter list, like TRIANG(X):X*(X+1)/2; NAME can be anything that isn't the name of a built-in function.

In addition to the calculator's × and ÷ symbols for multiplication and division, the parser also accepts * and /, and in addition to the array access function ITEM(A:B), it also accepts the notation A[B]. For compatibility with the HP calculators, these features may be turned off, so the * / [ ] characters can be used in names; this is controlled using the STD/COMP setting in the MODES menu. The compatibility setting is applied when an equation is parsed and then stays with it for its lifetime, even if the system STD/COMP setting is changed later. When viewed on the stack, Plus42-style equations are displayed with straight single quote characters, while HP-compatible equations are displayed with backquote delimiters.

One potential compatibility issue that won't be easy to fix is that variable names must be no more than 7 characters long, instead of up to 10 characters on the original calculators. This is because Plus42 translates the equations to user code for execution, and variable access gets translated to HP-42S RCL "NAME" instructions.

From a user interface perspective, all this is still a bit rough around the edges; I'll add more functions in menus, and do a better job of hiding the user code that is generated by the parser and the direct solver. Some enhancements to the equation language are also planned, like access to the RPN stack, a generalized loop construct, and support for array indexing in the first argument of L().

Note that I decided to abandon compatibility with Free42 state files; I'm making a fresh start with the state file format, starting with this preview release. State files will be backward compatible going forward, but continuing to support compatibility all the way back to Free42 1.0 was becoming a burden, with all the changes that are happening under the hood.

Anyway, enjoy! I hope you like this and find it useful, and I'm looking forward to hearing what you think.

Here's the previous thread on this topic:
Really outstanding Thomas!
I've already entered a few equations in the list, gave each a name and have solved for different variables. I find it very intuitive and the HP-27S manual is a great companion to use this feature.
Now I need to find more time to enjoy playing with this and I feel I have just scratched the surface
Thank you!
Having beta-tested this extensively, I can tell you all that this is a fantastic job. All equations are working as expected as on the 27S, with an outstanding performance, the blink of an eye vs. minutes on the original machine. And believe me, I threw wicked equations to it, pushing the language to its limits (nested sigma, side-effects with L() and G(), etc..).

Not only that, but you can import equations in programs (XSTR "), PARSE then EVAL them, making the 35S looking like a slow toy in comparison.

Moreover, I could implement the missing financial stuff easily with functions definitions, a very powerful addition to the system.

With future enhancements like matrices/list elements as lvalues (providing true indirect adressing and therefore Turing-completness), indefinite loop constructs, and stack interaction, this will be the most powerful functional language on a calculator ever (Python excepted).

Well done Thomas ! you're a hero to this community.
Plus42 is terrific!

Two questions:

1. Is there a bug with scientific notation in equations? When solving the following the exponent appears to be ignored:

HZ=(3E17)/NM

2. The README.txt file notes support for attached units. This is a dream come true for me. Is this functionality built into the current version, or is it something planned for the future?

Thomas, thank you so much for developing this!
(11-20-2021 06:18 PM)roberto_abraham Wrote: [ -> ]1. Is there a bug with scientific notation in equations? When solving the following the exponent appears to be ignored:

HZ=(3E17)/NM

Yes, that is a bug. I'll fix it in the next build.

(11-20-2021 06:18 PM)roberto_abraham Wrote: [ -> ]2. The README.txt file notes support for attached units. This is a dream come true for me. Is this functionality built into the current version, or is it something planned for the future?

I shouldn't be including that README file yet -- Plus42 is work in progress. I'll get started on units once the equations are all done, that could take another week or two. The official release with all the planned features will probably be ready in January, but there will be development builds posted here in the meantime.
(11-20-2021 06:18 PM)roberto_abraham Wrote: [ -> ]1. Is there a bug with scientific notation in equations? When solving the following the exponent appears to be ignored:

HZ=(3E17)/NM

It is odd, I did not see the bug. (even tried 0.3e18 ... same result)

But, I did noticed keyboard cursor keys (and DEL) does not work in equation mode.
I just uploaded a new build. It contains:

1. REGX, REGY, REGZ, REGT, and STACK[n] for accessing the RPN stack (read-only)
2. Two-dimensional indexing for matrices: M[A:B] and ITEM(M:A:B)
3. Ability to assign to a matrix element using L()
4. Get number of rows and columns of a matrix: MROWS(M) and MCOLS(M)
5. Integration element: ∫(eqn_name:var:lo:hi)
6. Also works for user programs: ∫(XEQ:prgm_name:var:lo:hi)
7. Fixed a potential crash while cleaning up on exit or while switching states
8. Experimental fix for blurriness in print-out on certain Android devices

I couldn't reproduce the 3E17 bug, but after I posted the update, I realized it only happens with the small E used as the exponent character on the 42S; the normal letters E and e do work. I'll fix the small E in the next build.

UPDATE: There are several bugs in the way numbers are handled. It's not distinguishing properly between numbers and names in the lexer, and it's using sscanf() to convert numbers to floating-point, instead of using string2phloat(). This is proof-of-concept code from the early binary-only development builds, that I forgot about later on. I just fixed it, and those fixes will be in the next build.
(11-21-2021 12:59 PM)Albert Chan Wrote: [ -> ]But, I did noticed keyboard cursor keys (and DEL) does not work in equation mode.

Yes, Free42 and Plus42 ignore the cursor left, cursor right, and delete keys.
I agree it would be useful to have them work in the equation editor. I'm putting it on my list for future improvements.
Thomas,

There just are not enough words to praise your efforts, truly incredible.

So, I'll just say thank you.
Gene
New build uploaded, with the exponent parsing fix.
Thank you again, Thomas. It's working very well! I'm going to be following the progress of Plus42 with great interest, as the planned feature set looks perfect.
New build uploaded, with a new FOR loop: FOR(init:cond:next:expr-list)
It evaluates 'init' once, at the beginning; then checks 'cond' before entering the body of the loop, exiting if 'cond' evaluates to 'false'; then performs the loop body, consisting of 'expr-list', i.e. one or more expressions; and performs 'next' at the end of each loop.

'expr-list' may be one or more expressions. The return value of the loop is the value returned by the last loop body expression executed, or the value returned by 'init' if the loop body is executed zero times.

All four parameters to FOR are required. If you are looking for a no-op to use in the place of 'init', 'next', or 'expr-list', just use a constant, say, 0; if you want 'cond' to always succeed, use something like 1=1, or 1=2 if you always want it to fail. The latter isn't very useful since you could achieve the same effect using simply 'init' on its own.

Special expressions BREAK and CONTINUE are available and do what you'll probably expect. The whole thing is designed to be similar to the C for loop.

Also: added SEQ(expr-list). Allows executing multiple expressions in places where normally only one would be allowed. The return value of SEQ is the value returned by the last expression in the list. In other words, similar to the C comma operator.
I posted another update, with these enhancements:

1. In the ∫() element, you now provide an expression as the first argument, not a name. I expect that to be more convenient in most cases, but if needed, it is still possible to provide an equation name or program label, using the equation call or program call syntaxes: EQN_NAME(X:Y:Z) or XEQ(PRGM_NAME:X:Y:Z).
2. Matrices and vectors embedded in equations using [[A:B]:[C:​D]] notation. Row vectors can be entered like [[A:B:C]] and column vectors like [A:B:C]; the latter is basically a shorthand for [[A]:[B]:[C]].
3. Exposed these HP-42S matrix functions: CROSS, DET, DOT, FNRM, INVRT, RNRM, RSUM, TRANS, and UVEC.
Another update, this one pretty minor:

2. Made one-dimensional addressing 0-based, while keeping two-dimensional addressing 1-based. This matches the conventions on the HP-42S and HP-35s.
3. When storing an element in a list using L(List[n]:value), the list is now automatically grown, as necessary, to make room for the element.

I think that concludes the Plus42 equation language, at least for the time being.
I'll tackle the equation editor UI next: menus, key bindings, bug fixes...
I tried to install it over Plus42 3.0.6 but it failed because the version number has been reset to 1, is that deliberate?

(11-23-2021 05:31 PM)johanw Wrote: [ -> ]I tried to install it over Plus42 3.0.6 but it failed because the version number has been reset to 1, is that deliberate?

Resetting the version number to 1 was deliberate, but the side effect of not being able to install over an older version wasn't. You'll have to uninstall the old version first, I'm afraid.

It doesn't make much of a difference since I also removed the ability to read older state files; there will be backward compatibility again going forward, but I've taken this opportunity to remove a lot of backward compatibility baggage, which was making life difficult because of some drastic changes under the hood.

(11-23-2021 05:31 PM)johanw Wrote: [ -> ]BTW, have you already thought about pricing?

I'm thinking something in the general vicinity of €10.
New update:

1. Fixed behavior of CALC when an equation is selected that has no menu variables.
2. Windows, Mac, and Linux only: Cursor left, cursor right, and delete on the physical keyboard now activate menu keys labeled ← (left), <← or ↑ (shift left), → (right), →> or ↓ (shift right), and DEL (delete). This works in the equation editor, but it also works in any other menu with keys with those labels, most notably the matrix editor.
Amazing job Thomas !

Clearly a lot of thought went into this. One question coming from a 43s discussion on another forum: is there any limitation on the equation complexity vs. the current stack mode (4STK or NSTK)?
(11-24-2021 10:34 AM)Didier Lachieze Wrote: [ -> ]Is there any limitation on the equation complexity vs. the current stack mode (4STK or NSTK)?

No, the generated code starts with LNSTK, so it executes with the big stack, regardless of the stack mode in use by the caller.
New update:

1. When the function called by the solver had an error, the immediate return to the solver did not take care of restoring the previous stack mode, so if this happened while executing generated code, you would end up in NSTK mode. (This affects Free42 as well and will be fixed in the next release.)
2. When a run-time error occurred while executing the code generated by the direct solver, the numerical solver invocation that would run next would not terminate properly, failing to display the appropriate final message.