Plus42 Equations, Preview Release

[Albert Chan]

(11-20-2021 08:22 AM)Vincent Weber Wrote:  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.

It may be simpler to EVAL string directly. (then, we don't need PARSE, UNPARSE)

[Vincent Weber]

(11-24-2021 05:50 PM)Albert Chan Wrote:  

(11-20-2021 08:22 AM)Vincent Weber Wrote:  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.

It may be simpler to EVAL string directly. (then, we don't need PARSE, UNPARSE)

Not only it would be simpler, but it would also allow to use the stack registers in equations properly like the 35S (REGX, REGY, REGZ, REGT). Currently the stack is deplaced by an equation, as it occupies the X register prior to parsing and evaluation. I would be in favor of an EQU instruction that would perform XSTR+PARSE+EVAL at one go, without touching the stack.

[Thomas Okken]

I don't like the idea of combining PARSE and EVAL: equation objects are rather heavyweight and shouldn't be created needlessly. The whole point of the design is to make evaluation fast, so you'll get performance comparable to regular user code programs when using them with the numerical solver and integrator.

I am thinking of making EVAL take a parameter, so you could store equations as regular variables and then execute them by name; that way you could execute them in such a way that they would have full access to the stack and not take up any space there.

[Vincent Weber]

(11-24-2021 07:42 PM)Thomas Okken Wrote:  I don't like the idea of combining PARSE and EVAL: equation objects are rather heavyweight and shouldn't be created needlessly. The whole point of the design is to make evaluation fast, so you'll get performance comparable to regular user code programs when using them with the numerical solver and integrator.

I am thinking of making EVAL take a parameter, so you could store equations as regular variables and then execute them by name; that way you could execute them in such a way that they would have full access to the stack and not take up any space there.

I understand the issue. It is true that on the 35S equations are unusable in a loop, as they are compiled every time.
So I understand your solution would be:
XSTR "whatever"
PARSE
STO "equ"
...
EVAL "equ"
...

Why not ! Or maybe keep track of how many times we've been though the XSTR step, and PARSE it only the first time, but not the subsequent times ?

[Albert Chan]

(11-24-2021 07:52 PM)Vincent Weber Wrote:  XSTR "whatever"
PARSE
STO "equ"
...
EVAL "equ"
...

Why not ! Or maybe keep track of how many times we've been though the XSTR step, and PARSE it only the first time, but not the subsequent times ?

I was thinking along the line XSTR "whatever" returned 'whatever' (single quoted for PARSE'd)

Example:
if we paste clipboard into Plus42, say, "∫(X^4:X:0:1)", X-register get '∫(X^4:X:0:1)'
if we then copy X-register to clipboard, clipboard get back "∫(X^4:X:0:1)"

Plus42 were already doing this anyway, when we paste numbers (real or complex) into it.
Also, when we paste code into PRGM, it parse the text into code.

---

For integral, why not allow an optional ACC ? Say, ∫(X^4:X:0:1:1E-6)

And, why ":" argument separator, and not "," ?
SpeedCrunch calculator use ";", and I never get used to it, example, arctan2(4;3)

[rprosperi]

(11-25-2021 12:22 PM)Albert Chan Wrote:  I was thinking along the line XSTR "whatever" returned 'whatever' (single quoted for PARSE'd)

Example:
if we paste clipboard into Plus42, say, "∫(X^4:X:0:1)", X-register get '∫(X^4:X:0:1)'
if we then copy X-register to clipboard, clipboard get back "∫(X^4:X:0:1)"

Plus42 were already doing this anyway, when we paste numbers (real or complex) into it.
Also, when we paste code into PRGM, it parse the text into code.

---

For some future enhancement, how about a feature that lets you paste a string with a valid algebraic equation (similar to "∫(X^4:X:0:1)") and it creates an equivalent 42 FOCAL RPN program? Now that would be a very Magic Paste.

[Werner]

(11-25-2021 12:22 PM)Albert Chan Wrote:  I was thinking along the line XSTR "whatever" returned 'whatever' (single quoted for PARSE'd)

PARSE should always be separate - how else are you going to keep strings and expressions apart?
Your string may be a partial expression, still to be concatenated with other parts. It's a way of dynamically writing programs.

Cheers, Werner

[ijabbott]

(11-25-2021 02:10 PM)rprosperi Wrote:  For some future enhancement, how about a feature that lets you paste a string with a valid algebraic equation (similar to "∫(X^4:X:0:1)") and it creates an equivalent 42 FOCAL RPN program? Now that would be a very Magic Paste.

Do you mean for a standard HP-42S? I think that would be quite tricky unless it is allowed to define some temporary matrix variable to store intermediate results.

I seem to remember someone here or on the SwissMicros forum writing a program to convert Python-style code to 42S FOCAL RPN, but I can't remember if it relied on any Free42 features or not.

[Thomas Okken]

(11-25-2021 02:10 PM)rprosperi Wrote:  For some future enhancement, how about a feature that lets you paste a string with a valid algebraic equation (similar to "∫(X^4:X:0:1)") and it creates an equivalent 42 FOCAL RPN program? Now that would be a very Magic Paste.

Well, you can paste an equation, PARSE it, and EVALuate it, and when you then switch to PRGM mode, you'll see the generated code. And you can copy or PRP that code and use it elsewhere, should you wish.

You probably won't wish to do that, because it won't be an HP-42S-compatible program. The code generated by the Plus42 equation parser relies heavily on the big stack, and a bunch of other functions I added specifically to make it easier to generate user code.

Generating code that runs on a vanilla 42S would be an interesting challenge, but not one that I think I'm going to be tackling any time soon!

[Thomas Okken]

New update:

1. Added EVALN function, which evaluates an equation object specified by name. The old EVAL function is still available, but its semantics have changed so that it is basically equivalent to EVALN ST X. This means that instead of replacing the contents of the X register (that is, the equation object) with the result of the evaluation, and saving X to LASTx, it pushes the result of the evaluation onto the stack. That is, it behaves like a recall operation now, not like a unary operator.
With EVALN, equations using REGX/REGY/REGZ/REGT should be able to perform the same kind of magic as on the HP-35s.
2. Added REAL?, CPX?, MAT?, LIST?, Σ, and ∫ to the PGM.FCN menu, and moved CDATE and CTIME there from the CONVERT menu; added RCOMPLX, PCOMPLX, and INT to the CONVERT menu; added ∫ and SEQ to the TOP.FCN menu (as Shift-Σ+ and Shift-XEQ, respectively), and also added the hyperbolic functions, LNP1, and EXPM1 in additional rows in the TOP.FCN menu.
3. ANGLE, RADIUS, XCOORD, and YCOORD can now be called with a single parameter, which will be interpreted as a complex number. That makes them inverses of PCOMPLX and RCOMPLX. (They can also still be used with two arguments, as before, of course.)

I also added some code to help me troubleshoot the equation object leak, and to prevent leaked equations from accumulating in the state file until I fix the underlying bug.

Because of EVALN, the generated code no longer starts with FUNC 11, but with FUNC 01, since it no longer needs to consume the contents of the X register. This shouldn't really affect anything, but you may want to UNPARSE and then re-PARSE your equations to make sure the generated code follows the new calling convention.

(Automatically recompiling in this kind of scenario is problematic because the application may be suspended in the middle of stepping through generated code. It shouldn't be a big issue because the format for generated code should settle down to its final form pretty soon.)

Happy Thanksgiving everyone!

[Thomas Okken]

New update:

1. Added a menu to the R↓ key, with REGX, REGY, REGZ, REGT, and STACK.
2. Added STAT menu.
3. Fixed equation leak in PRP/TRACE.
4. Moved the ":" from Shift-÷ to Shift-R/S
5. Made the decimal key produce "." or "," depending on RDX./RDX, mode and whether Shift is pressed or not.
6. Mapped RCOMPLX and PCOMPLX to Shift-STO, depending on RECT/POLAR mode
7. Mapped ∫ to Shift-8.

[Vincent Weber]

Awesome job Thomas. Many, many thanks !

[johanw]

(11-26-2021 04:49 PM)Thomas Okken Wrote:  New update:

This update crashes at startup, then shows "memory clear" when I start it again, then crashes at the next startup, etc. I got a debug log, I think this is the relevant piece. Android 11.

Code:


11-26 23:42:13.172 F/libc    (31605): Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x20 in tid 31605 (masokken.plus42), pid 31605 (masokken.plus42)
11-26 23:42:13.174 I/Layer   (4246): id=134721[1] Destroyed Surface(name=8a509c8 StatusBar)/@0x173a223 - animation-leash#0
11-26 23:42:13.174 I/Layer   (4246): id=134722[1] Destroyed Surface(name=acb003 NavigationBar0)/@0x47815b9 - animation-leash#0
11-26 23:42:13.198 D/SurfaceFlinger(4246): Display 0 HWC layers:
11-26 23:42:13.198 D/SurfaceFlinger(4246):      DEVICE | 0x724ee13280 | 0002 | RGBA_1010102 |  631.0    0.0 1711.0 2340.0 |    0    0 1080 2340 | com.android.systemui.ImageWallpaper$_17111#0
11-26 23:42:13.198 D/SurfaceFlinger(4246):      DEVICE | 0x724ee14400 | 0000 | RGBA_8888    |    0.0    0.0 1080.0 2340.0 |    0    0 1080 2340 | com.sec.android.app.launcher/com.sec[...].activities.LauncherActivity$_5399#0
11-26 23:42:13.198 D/SurfaceFlinger(4246):      CLIENT | 0x724ee14040 | 0002 | RGBA_8888    |    0.0 1007.0 1080.0 2087.0 |  797 1791  951 1945 | Splash Screen com.thomasokken.plus42#0
11-26 23:42:13.198 D/SurfaceFlinger(4246):      DEVICE | 0x724ee16ac0 | 0000 | RGBA_8888    |    0.0    0.0 1080.0   83.0 |    0    0 1080   83 | StatusBar$_17111#0
11-26 23:42:13.198 D/SurfaceFlinger(4246):      DEVICE | 0x724ee16d40 | 0000 | RGBA_8888    |    0.0    0.0 1080.0  126.0 |    0 2214 1080 2340 | NavigationBar0$_17111#0
11-26 23:42:13.198 D/SurfaceFlinger(4246):      DEVICE | 0x724ee15bc0 | 0000 | RGBA_8888    |    0.0    0.0 1080.0  151.0 |    0    0 1080  151 | ScreenDecorOverlay$_17111#0
11-26 23:42:13.198 D/SurfaceFlinger(4246):      DEVICE | 0x724ee14180 | 0000 | RGBA_8888    |    0.0    0.0 1080.0  151.0 |    0 2189 1080 2340 | ScreenDecorOverlayBottom$_17111#0

Edit: it produced a lot of .crash files in /data/data, this is one of them: http://www.xs4all.nl/~johanw/Untitled.p4...4468.crash

[Thomas Okken]

New update:

1. PCOMPLX and RCOMPLX, and possibly other functions, were not recognized by the parser if they were entered using the menus.
2. Missing labels for SDEVX and SDEVY in the STAT menu.

[Thomas Okken]

(11-26-2021 10:50 PM)johanw Wrote:  

(11-26-2021 04:49 PM)Thomas Okken Wrote:  New update:

This update crashes at startup, then shows "memory clear" when I start it again, then crashes at the next startup, etc. I got a debug log, I think this is the relevant piece. Android 11.

Code:


11-26 23:42:13.172 F/libc    (31605): Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x20 in tid 31605 (masokken.plus42), pid 31605 (masokken.plus42)
[...]

Edit: it produced a lot of .crash files in /data/data, this is one of them: http://www.xs4all.nl/~johanw/Untitled.p4...4468.crash

Could you try reinstalling? The app is working fine on other phones, and there's nothing wrong with your state file, either. This looks like a corrupted install -- which is rare, but I do see evidence of them occasionally in the Android developer console.

[johanw]

(11-27-2021 01:34 AM)Thomas Okken Wrote:  Could you try reinstalling?

That does not help, the problem stays the same.

Further, the same happens on 2 other Android 11 devices and an Android 6 device.

[Thomas Okken]

That's pretty bizarre. I assure you, the apk on my web site is fine. What makes it crash on four different phones in your case, I have absolutely no idea.

[Thomas Okken]

New update:

1. Code execution no longer ends in generated code, at least when it runs without error. The integrator and the numerical solver already took care of restoring the current program position; the direct solver and EVAL now do, too.
2. Tentative implementation of run-time error reporting for equations: shows the part of the equation where an error occurred in the bottom line of the display. Note that this is rather crude; the main point of the exercise is to test the logic that translates program locations back to positions in the equation text, and see how well it works in practice. Ultimately, the goal is to open the offending equation in the equation editor with the cursor at the trouble spot, and print the equation with highlight in trace mode, etc.
3. Implemented the VARS option in the PRINT menu, for printing all the variables associated with the current equation.

[Thomas Okken]

The last update didn't display the equation error message reliably, at least on Android. I fixed it and rebuilt all four versions, for good measure.

Note: (what I failed to mention in my previous post) In order for the app to be able to translate a location in the generated code back to the original equation, it requires a code map, and that map is only created when the code is generated, and that happens when the equation is parsed. What this means is that there won't be such a code map for any equations that existed before this upgrade; they will have to be re-parsed manually in order for the messages to work.

[Thomas Okken]

Just after posting the last update, I realized that I was using pc values in the code map, and those aren't portable. I changed the code to use line numbers instead, and uploaded a new build.