Plus42 Equations, Preview Release

[Vincent Weber]

(02-23-2022 04:04 PM)Marco Polo Wrote:  The 48 solver can solve also program objects, so the "equation concept" is somewhat superseded. I have not yet experimented the 17B/27S/Plus42 equation language, but from a quick manual reading it seems to me functionally like the 48 solver used with program instead of equation. I may be wrong

Of course you could do everything you do on Plus42 on a 48. And everything you do with a 48, you could do with a computer but not with the same simplicity. The beauty of the 17B/27S language is that it is purely functional, everything is an equation, even the L() statements which have side effect. This is sheer elegance...
I'm sure everything you can do in Python, you could also do in PERL, yet, you'll have to put a gun on my head to make me program in PERL

[Marco Polo]

(02-23-2022 03:56 PM)Thomas Okken Wrote:  I fixed the PLOT crash on Android.

I uploaded new builds for all platforms, since the bug had the potential to cause crashes on the other ones as well.

Just found a strange behaviour on axis label (both x and y): if the plot range is > 10 the axis labels are printed in exp format.
I could not figure if this behaviour is normal or i am missing something

[Thomas Okken]

(02-23-2022 04:20 PM)Marco Polo Wrote:  Just found a strange behaviour on axis label (both x and y): if the plot range is > 10 the axis labels are printed in exp format.
I could not figure if this behaviour is normal or i am missing something

That's intentional. The idea is that 1 in the least significant displayed digit corresponds with the distance between two tick marks.

[OlidaBel]

(02-23-2022 04:19 PM)Vincent Weber Wrote:  Of course you could do everything you do on Plus42 on a 48. And everything you do with a 48, you could do with a computer but not with the same simplicity. The beauty of the 17B/27S language is that it is purely functional, everything is an equation, even the L() statements which have side effect. This is sheer elegance...
I'm sure everything you can do in Python, you could also do in PERL, yet, you'll have to put a gun on my head to make me program in PERL

L() stands for ? Lower than?

Why did you speak about Perl ? until now it was a rather good day ;-)
Python with a PC keyboard, yes! Not very tempted on a calculator.
(Perl, no thanks)
edit: when is the Plus42 iphone app foreseen ?

[Vincent Weber]

(02-23-2022 04:44 PM)OlidaBel Wrote:  

(02-23-2022 04:19 PM)Vincent Weber Wrote:  Of course you could do everything you do on Plus42 on a 48. And everything you do with a 48, you could do with a computer but not with the same simplicity. The beauty of the 17B/27S language is that it is purely functional, everything is an equation, even the L() statements which have side effect. This is sheer elegance...
I'm sure everything you can do in Python, you could also do in PERL, yet, you'll have to put a gun on my head to make me program in PERL

L() stands for ? Lower than?

Why did you speak about Perl ? until now it was a rather good day ;-)
Python with a PC keyboard, yes! Not very tempted on a calculator.
(Perl, no thanks)

L() for Let, the primary statement keyword for the 17B/27S/Plus42 equation language.
I talked about Python vs. Perl as an analogy for RPN/17B equation language vs. RPL
This being said, Casio, Numworks, TI and even somehow HP have wonderful interfaces for Python on a calculator: menus, code snipsets, autocompletion, syntax highlighting...

[Thomas Okken]

(02-23-2022 04:44 PM)OlidaBel Wrote:  when is the Plus42 iphone app foreseen ?

If you would like to try the test builds, send me an email with your phone's UDID.

[Marco Polo]

(02-23-2022 04:26 PM)Thomas Okken Wrote:  

(02-23-2022 04:20 PM)Marco Polo Wrote:  Just found a strange behaviour on axis label (both x and y): if the plot range is > 10 the axis labels are printed in exp format.
I could not figure if this behaviour is normal or i am missing something

That's intentional. The idea is that 1 in the least significant displayed digit corresponds with the distance between two tick marks.

Thanks.
Is there any way to change the pixel scaling in the provided skins?
My aim is to have higher font (similar to original Hp42 or 48) to improve readability.
I find the provided font a little too small

[Massimo Gnerucci]

(02-23-2022 04:19 PM)Vincent Weber Wrote:  I'm sure everything you can do in Python, you could also do in PERL, yet, you'll have to put a gun on my head to make me program in PERL

When I do that, I have no gun put on my head

[Thomas Okken]

(02-23-2022 05:34 PM)Marco Polo Wrote:  Is there any way to change the pixel scaling in the provided skins?

Only by editing the layout files by hand. In the Display: line, the two numbers following the display location are the number of screen pixels per calculator pixel, horizontally and vertically. On Android, iOS, and MacOS, those numbers don't have to be integers, but on Windows and Linux, they do.

[Marco Polo]

(02-23-2022 05:59 PM)Thomas Okken Wrote:  Only by editing the layout files by hand. In the Display: line, the two numbers following the display location are the number of screen pixels per calculator pixel, horizontally and vertically. On Android, iOS, and MacOS, those numbers don't have to be integers, but on Windows and Linux, they do.

Thanks. Is there a way to access the layout file of the skins embedded in Windows version?
For Android version is quite easy.

[Thomas Okken]

https://github.com/thomasokken/plus42des...ster/skins

[Thomas Okken]

New update:

Just a few minor things...

1. In the desktop versions, added key mappings for the former top row, to allow pressing the shifted functions as Shift-then-A etc., in addition to Shift-A etc. For the standard keys, this is default behavior, but with direct command mapping, it had to be made explicit.
2. The way the result of evaluating parameter-less expressions was displayed in the equation editor didn't work very well with 2-line displays. Made it a bit smarter.
3. When printing a plot using the Plot Viewer, the output now includes the axis limits.
4. Copy Print-Out As Text now handles the images generated by PRLCD when it prints sideways.
5. Changed the search order for global labels. They are now always searched for starting in the current directory, followed by the current directory's ancestors, all the way until HOME; followed by the directories in PATH; and finally, in running programs, by the directory where the currently running code resides, followed by that directory's ancestors.
Searching the current directory before the program's own directory may seem wrong, but it is necessary in order to allow programs to function that call back to user-provided programs (i.e. programs like DPLOT, or anything using PGMMENU). And this also applies to programs called by SOLVE, INTEG, and the new PLOT function.

[Marco Polo]

Just some proposals for improvement (imho):
1) keep screen soft menu row always on: there is plenty of screen room now
2) rearrange the 2nd row as DIR UNITS EQN (leave the rest as is)
3) add a shortcut to clear the stack: when in infinite stack mode the stack grows up very quickly and it happens (at least to me) to clear it quite often. It could be put in place of SST^ (VIEW key)
4) capability of assign custom key to UOM
5) capability of define custom UOM (like 48)

Cheers
Marco Polo

[Thomas Okken]

(02-25-2022 10:08 AM)Marco Polo Wrote:  1) keep screen soft menu row always on: there is plenty of screen room now
2) rearrange the 2nd row as DIR UNITS EQN (leave the rest as is)
3) add a shortcut to clear the stack: when in infinite stack mode the stack grows up very quickly and it happens (at least to me) to clear it quite often. It could be put in place of SST^ (VIEW key)
4) capability of assign custom key to UOM
5) capability of define custom UOM (like 48)

1, 4, and 5 are on the post-1.0 to-do list;
I won't do 2 and 3 but this is the kind of thing anyone can accomplish with customized skins.

[Thomas Okken]

New update:

1. Somewhat smarter PLOT axis label placement.
2. Removed the top-level GRAPH menu; GRAPH now takes you directly to the plot settings menu. I'll restore the top-level menu once I get around to actually implementing 3D and other plot types, and for now, focus on improving the 2D plot functionality and getting it ready for 1.0.
3. PRINT in the plot viewer now prints the program name or equation above the plot.
4. Fixed PRGM-mode behavior of the GRAPH menus and functions.

[Thomas Okken]

New update:

1. A few improvements in drawing axes, tick marks, and labels.
2. In equations, FCSTY and FCSTY are now recognized as being each other's inverses, so they can be handled by the direct solver.
3. You can now mark points using ENTER, and when two points are marked, you can then run the solver with those two X values as starting guesses (press Shift-7), or run the integrator with those two X values as limits (press Shift-8), or zoom in with those two points marking the corners of the new view rectangle (press 0).
4. When exiting, now writing the state file using a temporary name first, and renaming it to *.p42 only when successful. This way, a crash during exit won't wipe out all of the previous state.

Feature-wise, that's it for 1.0. I guess that makes this the first beta!

[Marco Polo]

(03-01-2022 01:44 PM)Thomas Okken Wrote:  3. You can now mark points using ENTER, and when two points are marked, you can then run the solver with those two X values as starting guesses (press Shift-7), or run the integrator with those two X values as limits (press Shift-8), or zoom in with those two points marking the corners of the new view rectangle (press 0).

Just some early comments.

Tried with a very simple equation Y=SIN(X) both in DEG and RAD mode.

Integration works quite fine (very nice the shading of integral area), even though not as fast as other operations (tried with FIX 5).

The solver, of course, tries to solve analitically the equation if possible and this causes the result being stuck to 0 regardless the selected points.
Forcing numerical solution (Y=X*0+SIN(X)) gives the desired root.
(BTW: is there a way to set the solver to always avoid analytical solution?)

No extremum identified, but i suppose this is the correct solver behaviour.

Cheers
Marco Polo

[Thomas Okken]

For integration, it may help to set ACC, e.g. 1E-4 STO "ACC". If ACC is unset, it defaults to zero, which is maximum precision.

I'll have to look into integration slowness. When integrating an equation where the direct solver can find an explicit inverse, it's supposed to keep the inverse for the duration of the integration, so each point is a simple evaluation, and that should be fast. It's not clear to me yet if there is something wrong with the caching of the generated inverse, or if it's slow because of ACC. I'll look into this tomorrow.

There's currently no way to tell it not to use the direct solver. Maybe there should be a flag to control this?

Regarding extrema: the solver doesn't look for them, it merely reports them if it happens to get stuck on one. The robust way to find extrema is to look for roots of the derivative.

[Marco Polo]

(03-01-2022 06:32 PM)Thomas Okken Wrote:  For integration, it may help to set ACC, e.g. 1E-4 STO "ACC". If ACC is unset, it defaults to zero, which is maximum precision.

I'll have to look into integration slowness. When integrating an equation where the direct solver can find an explicit inverse, it's supposed to keep the inverse for the duration of the integration, so each point is a simple evaluation, and that should be fast. It's not clear to me yet if there is something wrong with the caching of the generated inverse, or if it's slow because of ACC. I'll look into this tomorrow.

There's currently no way to tell it not to use the direct solver. Maybe there should be a flag to control this?

Regarding extrema: the solver doesn't look for them, it merely reports them if it happens to get stuck on one. The robust way to find extrema is to look for roots of the derivative.

The use of ACC increases enormously the integration speed even with 1e-15 and better accuracy: the integration is instantaneous on an Honor 7x smartphone. Tried with Y=X*0+SIN(X).

A flag or a MODE menu entry could do the trick of forcing numerical solutions.

Extrema: i was not sure if the solver would look for them. That's why I asked.

[Thomas Okken]

New update:

1. Added DIRECT / NUMERIC setting in the MODES menu, to enable / disable the direct solver. It is enabled by default.
2. Fixed drawing of results at the top of the screen, so numbers get erased before new numbers get drawn to the same spot.

I also checked the INTEG situation, and confirmed that when the direct solver generates an inverse during a PLOT or INTEG operation, the generated code is reused for the duration of the entire operation. This means that when INTEG is called by the plot viewer, for a function that is itself calculated using SOLVE, and the operation is very slow, this indicates that the numerical solver is at work, and setting ACC is the right thing to do to speed up the operation.