Plus42 Equations, Preview Release

[Thomas Okken]

I personally find a real, hard edge more esthetically pleasing than a toroidal topology, but it wouldn't be difficult to modify the code to implement the latter, or even both. Having gliders vanish over the edge is trickier, though, because that would require having invisible cells beyond the edge, and then the question becomes: how far should those invisible cells extend?

[Steve Simpkin]

Hi Thomas. I believe I may have found a subtle difference in the operation of the solver between the HP-27S and Plus42. When working through the temperature conversion example on pages 94-95 of the HP-27S Owner's Manual, I see a slightly different operation in the way the variable keys work on Plus42. After using the F/C equation to convert 350 F to 176.667 C, the example has you press EXIT then {down arrow} to choose the K/C equation and press CALC to solve the new equation (see attached picture). The example then has you press the "K" variable key. In the HP-27S example, pressing the variable "K" key immediately solves for K using the current value in variable "C" (176.6667). On the Plus42, pressing the "K" variable key assigns the number in the X register to "K" instead of solving for "K". I have to admit that I see advantages in either operation method but they are different from each other.

[Thomas Okken]

Hi Steve -- Good catch, thanks! I'll fix that in the next build.

[ijabbott]

(03-25-2022 09:34 PM)Thomas Okken Wrote:  Having gliders vanish over the edge is trickier, though, because that would require having invisible cells beyond the edge, and then the question becomes: how far should those invisible cells extend?

"To infinity and beyond!"

[Thomas Okken]

(03-26-2022 03:47 PM)ijabbott Wrote:  "To infinity and beyond!"

Insufficient Memory

[Thomas Okken]

New update:

1. In the solver called from EQN -> CALC, allow the solver to run on the very first menu key press. (Fixing the issue pointed out by Steve, above.)
2. In the equation list view, DELET would offer to delete variables belonging to functions that didn't have any. Fixed.
3. In the equation editor, the CUSTOM menu now deals properly with keys that have assignments of things other than built-in functions.
4. In Y^X with complex Y and real integer X, restrict repeated squaring to exponents between -256 and 256. This is just a preliminary fix to limit the impact of errors in numbers close to 1 blowing up. Maybe it should just be removed altogether? Numbers of the form x+0i will be handled by the real pow() anyway.

[Thomas Okken]

New update:

1. No new code today, but the documentation is finally complete. It can still use lots of improvement, but at least it covers everything now.

[ggauny@live.fr]

Great, thank Thomas, kudos !

[nickapos]

Hey Thomas, thank you very much for the great work on plus42.
I have one question regarding custom units. Reading through the the doc, I was able to define a few custom units and they work fine, but I wonder if there is a way to define custom units using copy and paste.
Something that we could type in a computer and then paste in the calculator instead of typing everything in the calculator directly?
That would make things a lot faster.

Thanks and regards

[Thomas Okken]

Not specifically, but you can come close with a program.
For example,

Code:

0.5_kg
STO "pond"
2_one
PI
*
STO "tau"
0_one
STO "USD"

Copy that, paste it into Plus42 in PRGM mode, run it, et voilà.

[nickapos]

(03-27-2022 07:05 PM)Thomas Okken Wrote:  Not specifically, but you can come close with a program.
For example,

Code:

0.5_kg
STO "pond"
2_one
PI
*
STO "tau"
0_one
STO "USD"

Copy that, paste it into Plus42 in PRGM mode, run it, et voilà.

Awesome that is exactly what I was looking for.

Thank you very much

[Thomas Okken]

New update:

1. When PPAR got corrupted, like through an accidental HEAD "PPAR", this could lead to persistent errors (incorrect results) when calling SOLVE from the plot viewer. Fixed by making the code more resilient against this scenario.

[Thomas Okken]

New update:

1. PLOT: When XMIN > XMAX, Bad Things could happen. Added code to sanitize the plot domain and range, to prevent these and other problems.
2. Y^X with complex Y and integer X: removed the repeated-squaring logic, and replaced it with special-case logic for pure-real and pure-imaginary Y and integer X. Other cases are now handled using the logic for complex Y and non-integer real X.

[Thomas Okken]

New update:

1. On second thought, why get rid of repeated squaring for Y^X with complex Y and integer X completely? Following the same principle as the case for real Y and integer X, now using repeated squaring as long as it is exact. So this now applies to all complex numbers, not just pure-real or pure-integer, so you can get exact results for things like (3+4i)^48.

[Albert Chan]

How do you check complex multiplied result is exact ?

(a+b*i) * (c+d*i) = (a*c-b*d) + (a*d-b+c)*i

Do you check all 4 products exact, then check add/sub part exact too ?

[Thomas Okken]

(03-30-2022 04:43 PM)Albert Chan Wrote:  Do you check all 4 products exact, then check add/sub part exact too ?

Yes.

[Albert Chan]

I think complex powers with integer exponents should be done via squaring.
This is true even if result is not exact.

Y^X = |Y|^X * cis(arg(Y)*X)

Unlike pow() for real, we don't have excess precision to correct close to actual result.
Essentially, we are getting this, from Free42/Plus42:

Y^X ≈ round(round(|Y|)^X) * cis(round(round(arg(Y))*X))

Worst, argument inside cis() would required reduction, to within ±pi.

Python already does integer powers by squaring.
Complex pow (last column) not as good.

Python 3.9.5 (default, May 27 2021, 19:45:35)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> z = 3+4j
>>> q = 2+1j # sqrt(z)
>>> for i in range(10): print(i, q*z**i, z**(i+0.5))
...
0 (2+1j) (2+1j)
1 (2+11j) (2.0000000000000013+11j)
2 (-38+41j) (-37.999999999999986+41.00000000000001j)
3 (-278-29j) (-278-28.99999999999994j)
4 (-718-1199j) (-718.0000000000008-1198.9999999999995j)
5 (2642-6469j) (2641.9999999999964-6469.000000000001j)
6 (33802-8839j) (33801.99999999999-8839.000000000015j)
7 (136762+108691j) (136762.00000000006+108690.99999999996j)
8 (-24478+873121j) (-24477.99999999971+873121j)
9 (-3565918+2521451j) (-3565917.9999999995+2521451.000000001j)

[Thomas Okken]

Hmmm... for all integer exponents?

[Albert Chan]

(03-30-2022 08:01 PM)Thomas Okken Wrote:  Hmmm... for all integer exponents?

Python limited integer squaring to +/- 100, "normal" complex pow beyond that.
source: complexobject.c, static Py_complex c_powi(Py_complex x, long n)

This is Python 2.6 (newer version is similar)

>>> z = 3+4j
>>> z100 = z**100
>>> abs(z - z**101/z100), abs(z - z100/z**99)
(2.4565801279300335e-14, 9.9301366129890925e-16)
>>>
>>> z = 4+5j
>>> z100 = z**100
>>> abs(z - z**101/z100), abs(z - z100/z**99)
(1.7680105590573434e-14, 0.0)

[Thomas Okken]

New update:

1. Rolled back changes to Y^X for complex Y and integer X; now using repeated squaring again for all cases with exponents up to 2^31-1 absolute. Also cleaned up the code a little and improved error handling.

Albert, thank you for the suggestion!