Plus42 Equations, Preview Release

[Thomas Okken]

It's getting late so I'm signing off. If you'd like me to send you the pre-built Intel libraries, send me an email or PM with your email address and I'll send them to you tomorrow.

[Albert Chan]

Is this a feature, or a bug ?

emu71b:
>FNROOT(0,3,1+(1-SIN(FX))^3)
 1.54979993037
>FVALUE ! minimum = 1 + 0 = 1
 1.00000000001

Plus42:
eqn = "1 + (1-SIN(X))^3", go in "CALC", 0 "X" 3 "X", "X" (to solve)

375.E-3 - i831.E-3 // complex solution ?

[Vincent Weber]

(11-30-2021 03:11 PM)Albert Chan Wrote:  Is this a feature, or a bug ?

emu71b:
>FNROOT(0,3,1+(1-SIN(FX))^3)
 1.54979993037
>FVALUE ! minimum = 1 + 0 = 1
 1.00000000001

Plus42:
eqn = "1 + (1-SIN(X))^3", go in "CALC", 0 "X" 3 "X", "X" (to solve)

375.E-3 - i831.E-3 // complex solution ?

In the real domain, SIN(X) is always ≤=1, -SIN(X) ≥ -1, 1-SIN(X)≥0, and (1-SIN(X))^3≥0, so the equation result is always ≥1, and therefore never equal to 0. How on earth can the HP-71B find a real root to this ??

[Albert Chan]

(11-30-2021 03:25 PM)Vincent Weber Wrote:  In the real domain, SIN(X) is always ≤=1, -SIN(X) ≥ -1, 1-SIN(X)≥0, and (1-SIN(X))^3≥0, so the equation result is always ≥1, and therefore never equal to 0. How on earth can the HP-71B find a real root to this ??

Not real root, but extremum. We expected minimum when x = PI/2 + 2*K*PI

1+(1-SIN(PI/2+2*K*PI))^3 = 1+0 = 1, close to HP-71B FVALUE of 1.00000000001

---

Another Plus42 example, with expected behavior (no complex number result)

"K=X/COSH(X)", go in "CALC" 1 "K" "X" --> 1.19967864026 "Extremum"

Enter "K" "K" --> 0.662743419349 (see Catenoid soap bubbles thread, H/R when bubble pop)

[Vincent Weber]

I see, ok.
I'll let Thomas answer, then

[Thomas Okken]

(11-30-2021 03:11 PM)Albert Chan Wrote:  Is this a feature, or a bug ?

[...]

Plus42:
eqn = "1 + (1-SIN(X))^3", go in "CALC", 0 "X" 3 "X", "X" (to solve)

375.E-3 - i831.E-3 // complex solution ?

It's a feature.

Since X appears only once in the equation, Plus42 uses the direct solver, which finds the solution algebraically, by transforming the equation to 1+(1-SIN(X))^3=0, then (1-SIN(X))^3=-1 (subtracting 1 on both sides), then 1-SIN(X)=500E-3+i866E-3 (raising to the power 1/3 on both sides), then SIN(X)=500E-3-i866E-3 (subtracting from 1 on both sides), then X=375E-3-i831E-3 (taking the arcsine on both sides).

If you set REALRES mode, there will be an error during this procedure when it tries to calculate (-1)^(1/3), and it will switch to the numerical solver and find an extremum.

[Thomas Okken]

New update:

1. Preserving the stack during SOLVE and INTEG, so you can use REGX/REGY/REGZ/REGT and get results reflecting the initial state of the stack. (Once SOLVE and INTEG return, they'll leave results of their own, of course, so at that point, the stack will no longer be preserved.)
2. Created EQN versions of several PGM functions. The idea is to eliminate the ambiguity between "FOO" meaning a program starting with LBL "FOO" and an equation stored with STO "FOO". This distinction was already explicit in XEQ vs. EVALN, and now the same applies to PGMSLV vs. EQNSLV, PGMINT vs. EQNINT, PGMVAR (formerly PRMVAR) vs. EQNVAR, and VARMENU/VARMNU1 vs. EQNMENU/EQNMNU1.
3. If::invert() no longer generates code twice.

[Nigel (UK)]

(11-29-2021 04:56 PM)Thomas Okken Wrote:  

(11-29-2021 11:51 AM)Nigel (UK) Wrote:  Is there any chance of an extended character set for Plus42?

I don't see why not. I am open to suggestions. Apart from codes 128, 129, 134, and 138, the upper half of the character set is currently unused, so there is plenty of room to work with!

That's good news. As a first step, I've attached a file containing 124(!) characters to fill this space. It's a trimmed version of the font.inc file from the WP 34S project. I've removed all of the characters already present in Free42, plus some others, to bring down the number to something that should fit. Remaining are all the Greek letters not yet included, various symbols (e.g., \(\infty, \hbar\)), and a lot of Roman letters with umlauts and other accents. I believe that the WP 34S project aimed to support as wide a range of written languages as the limited space would allow, and carrying this across to Plus42 might be nice.

In any event, I hope this gets things started.

Nigel (UK)

[Albert Chan]

A suggestion to the SOLVER menu. I think CALC can be eliminated.
Just select the equation to be solve, then press ENTER

[Vincent Weber]

(12-01-2021 01:34 AM)Albert Chan Wrote:  A suggestion to the SOLVER menu. I think CALC can be eliminated.
Just select the equation to be solve, then press ENTER

Plus42 mimics the HP17BII/27S interface.
I don't see what eliminating CALC would bring, it will not save a keystroke, since you would have to press enter. The menu CALC/EDIT/DELETE/NEW makes it crystal clear what you can do...

[Albert Chan]

Hi, Vincent Weber

I don't know there were a historical reason for CALC/EDIT/DEL/NEW

It just felt odd that with the equation selected, press ENTER just produce a beep.
How about mapping ENTER to CALC ? (just like mapping cursor keys in eqn mode)

[Thomas Okken]

New update:

1. The previous update broke the ∫ element, due to the PGMINT → EQNINT split. The generated code used PGMINT, but because it uses an equation object for the integrand, now it needs to use EQNINT.
2. Added sections for list and equation variables to the CATALOG, and also added a section for named equations, i.e. equations that have names in the equation editor. (Equation variables are like any other variable, created with STO and retrieved with RCL; named equations are created in the equation editor, and can be retrieved with GETEQN.) The new sections are in the new OTHER submenu, together with MEM.
3. Exposed the full CATALOG in the equation editor.

[Thomas Okken]

New update:

1. Mapped ENTER key to CALC in list view
2. Enabled MODES and DISP menus in list view
3. Added optional ACC parameter to ∫

[Thomas Okken]

New update:

1. Menu navigation: can now enter the equation editor from PRGM mode.
2. Menu navigation: can now switch between SOLVER and ∫f(x) modes without leaving the equation editor. This affects the behavior of CALC, and which menu you end up in after leaving the equation editor.
3. When executing an equation in TRACE mode, now prints the position in the equation text, in addition to the user code steps being executed.

[Thomas Okken]

New update:

1. Fixed crash caused by a bug in CodeMap::lookup(), causing unpleasantness when tracing slightly larger functions.
2. Better handling of where to go when exiting the equation editor.
3. Made the statistics sums, introduced as special variables for equations, into functions callable by user code. They aren't in any catalogs yet, so you have to know what they are called: ΣX, ΣX2, ΣY, ΣY2, ΣXY, ΣN, ΣLNX, ΣLNX2, ΣLNY, ΣLNY2, ΣLNXLNY, ΣXLNY, and ΣYLNX. Apologies about the "ΣN", but calling that one the more logical "N" would just be asking for problems.

[Albert Chan]

(12-03-2021 03:01 PM)Thomas Okken Wrote:  Apologies about the "ΣN", but calling that one the more logical "N" would just be asking for problems.

Perhaps Σ1 (= N) ?

Example, mean of X = ΣX / Σ1

[Thomas Okken]

New update:

1. When a function without a top-level = sign is selected in the solver, now showing a white EVAL button in the variables menu, which will simply EVAL the function, without trying to solve it.
2. Better parse error checking for array element lvalues in L().
3. Made sure that Invalid Type errors on array literal elements are highlighted on the element in question.
4. Made PRINT menu sticky for all functions.
5. Some memory allocation failure handling (more work still needed in this area).

I think that's it for equations. There is still a bit of work to be done behind the scenes: memory allocation failure handling during parsing and code generation, stress testing with large numbers of equations, bug fixing, and minor tweaks, but as far as functionality and user interface are concerned, I think this is ready.

[Vincent Weber]

(12-04-2021 01:43 PM)Thomas Okken Wrote:  New update:

1. When a function without a top-level = sign is selected in the solver, now showing a white EVAL button in the variables menu, which will simply EVAL the function, without trying to solve it.
2. Better parse error checking for array element lvalues in L().
3. Made sure that Invalid Type errors on array literal elements are highlighted on the element in question.
4. Made PRINT menu sticky for all functions.
5. Some memory allocation failure handling (more work still needed in this area).

I think that's it for equations. There is still a bit of work to be done behind the scenes: memory allocation failure handling during parsing and code generation, stress testing with large numbers of equations, bug fixing, and minor tweaks, but as far as functionality and user interface are concerned, I think this is ready.

Thomas, I'm not sure everyone realizes all the countless days of hard work you have put into this, to come to an awesome unification of both worlds, the power of RPN and of the 17B/27S solver, with many powerful extensions (functions defintion, full indirect addressing,..).

Having beta-tested it extensively I testify of this amazing quality work.

A big thank you !!

I propose a statue for you !

[Thomas Okken]

Vincent, thank you! And I should acknowledge that without your testing and feedback, this would have been much harder to develop. Your contribution is greatly appreciated!

I also thank Bob Prosperi, who lent me an HP-27S and gave me an HP-17B, both of which I have used extensively, to familiarize myself with the equation editor, equation syntax, and solver behavior. I was skeptical about this functionality at first, but I have come to appreciate it while studying it and attempting to reproduce it.

Of course this is only one of four major features planned for Plus42. Next week, work continues...

[Vincent Weber]

Thanks Thomas for your kind words, it was really a pleasure, and I did very little compared to you !

Yes the 17B/27S solver is strange at first, but I came to like it a lot, a pure functional language embedded in a solver with menu, quite efficient. I always thought that adding user-defined fonctions and r/w indirect addressing would make it a fully-fledge language. You have done it, plus adding the 32SII/35S awesome possibility of using equations in RPN program. This is what the 42SII should have been !

I believe equations were THE big feature of Plus42. I don't care much about units (as a French I was brought up in the International System, never had to deal with Oz, lb, pounds and other UK stuff ) but yes there is more to it, within the IS itself.

Big LCD is nice (a true 19BII !), but I hope should not be as complicated.

Financial features of the 19BII would be a really plus for me.

Some people are keen on the fraction mode of the 32SII/35S. I don't see much use of it myself, but I would like one-step complex number entry a la 35S, with i and theta...

Then, the sky is the limit, but careful not to make this a monster, otherwise you'll end up with a 50G simulator the beauty of the 42 is to keep it simple !

Thanks again and cheers