Plus42 Equations, Preview Release

[Thomas Okken]

(04-22-2022 12:15 AM)Michael de Estrada Wrote:  

(04-21-2022 08:52 PM)tgray Wrote:  Plus42 sounds really exciting!...any chance of this ever making it to a Swiss micros hardware unit?

This would require a completely new hardware platform with an additional row of keys. Either that, or share the top row of keys with the softkeys, a la HP 42S with a TOP.FCN toggle. Anyways, this is a question you should ask of SwissMicros (Michael Steinmann), not Thomas Okken.

Plus42 can be used without the second row, or even without the top two rows. You can load the standard Free42 skin, or the DM42 skin, to see what that looks like.
Basically, UNITS and DIRS are moved to the first row of CATALOG to make them easy to access; instead of DIR.FCN, UNIT.FCN, and EQN.FCN, you can use the DIR, UNIT, and EQN sub-catalogs under CATALOG; instead of EQN, you can use the [=] menu key in the SOLVER and ∫f(x) menus; and you can reach the TVM menu using XEQ "TVM".

Only PLOT would be unreachable, since the function that enters it is called PLOT.MENU, which is too long to type with XEQ. But that could be fixed by simply shortening that name.

If someone is interested in some more serious hacking, Plus42 could possibly also be made into a firmware for HP graphing calculators, like newRPL. The Intel library would have to be replaced with something smaller, but it might fit with BCD20.

[Thomas Okken]

New update:

1. In ALL mode, the RND function didn't do anything. That behavior makes sense on a real HP-42S, but not here. RND should round to what you see in the display. I changed it so it rounds to 12 digits, i.e. the same behavior as in SCI 11 or ENG 11 modes.
This applies to Free42 as well and will be in the next release.

[Thomas Okken]

New update:

1. The behavior of CLV with respect to local variables didn't make a lot of sense. To make it a bit more logical, CLV will now only delete global variables, and if CLV "FOO" is executed while "FOO" is a local variable, a Restricted Operation error is returned; and added LCLV, which will delete only local variables, and only those that were created at the current RTN level.
These changes will be in the next Free42 release as well.

[nickapos]

Hey Tom, a question, I started plus42 on my Linux system yesterday and I could not see the bigger display, on my Mac it works fine. Is there anything I need to do to enable bigger display on Linux?

Thank you very much

[Thomas Okken]

No, you shouldn't have to do anything special on Linux, just use ROW+, COL+, or SETDS in the DISP menu to set the display to a larger size.

[nickapos]

(04-23-2022 12:46 PM)Thomas Okken Wrote:  No, you shouldn't have to do anything special on Linux, just use ROW+, COL+, or SETDS in the DISP menu to set the display to a larger size.

All right, thank you very much will do as you suggest.

[Thomas Okken]

New update:

1. The RND-in-ALL-mode change broke AMORT in ALL mode. Fixed.

[Werner]

(04-22-2022 11:13 PM)Thomas Okken Wrote:  1. The behavior of CLV with respect to local variables didn't make a lot of sense.

I don’t understand? What is/was the problem?
CLV “FOO” cleared variable FOO, that is, the last created local variable with that name, or the global one if no local one exists.
Seems logical enough to me?
Werner

[Thomas Okken]

The problem lies in using it to delete a local variable that may or may not have been created. You should be able to do that without risking side effects, like deleting a local in a calling scope, or a global. The previous version of CLV already wouldn't delete local variables from lower RTN levels for that reason, and it seems more consistent to me to just separate the functionality of deleting locals and globals entirely.

[Thomas Okken]

New update:

1. Renamed PLOT.MENU to PLOT.M.

(04-22-2022 10:01 AM)Thomas Okken Wrote:  [When using a Free42 skin] Only PLOT would be unreachable, since the function that enters it is called PLOT.MENU, which is too long to type with XEQ. But that could be fixed by simply shortening that name.

This means that skins containing a mapping for PLOT.MENU will have to be modified to use the new, shortened name. This has already been done for the built-in skins and all the skins on my web site.

[Pierre Mengisen]

The PLOT menu no longer works on the Mac version.
It works on the Windows version.

When will we have an iPad version of this excellent development?

Pierre

[Thomas Okken]

(04-25-2022 05:51 PM)Pierre Mengisen Wrote:  The PLOT menu no longer works on the Mac version.

Hmmm... It does work on my Mac. Could it be you have an old skin installed? Check the Skin menu to make sure the Plus42 skin is selected; if there are more than one, remove or rename the one in ~/Library/Application Support/Plus42/.

(04-25-2022 05:51 PM)Pierre Mengisen Wrote:  When will we have an iPad version of this excellent development?

Version 1.1, I hope. iPad support has been on my wish list for a while.

[Pierre Mengisen]

It's OK now after deleting PLUS42 in APPLICATION SUPPORT.
I don't know what file was corrupted and how.

I have noticed that plotting in my WINDOWS version under PARALLELS is very slow whereas it is almost immediate under MAC OS.
On the other hand, the calculation of an integral between two terminals has become very slow under MAC OS (about 30 seconds for a few complicated functions).
It seems to me that in older versions it was almost immediate. Unfortunately I have not kept these old versions.

Congratulations again on your work!

[Thomas Okken]

(04-26-2022 12:12 PM)Pierre Mengisen Wrote:  It's OK now after deleting PLUS42 in APPLICATION SUPPORT.
I don't know what file was corrupted and how.

Nothing was corrupted. The old layout just contains the mapping

Macro: 43 "PLOT.MENU"

which is no longer correct; now it needs to be

Macro: 43 "PLOT.M"

(04-26-2022 12:12 PM)Pierre Mengisen Wrote:  I have noticed that plotting in my WINDOWS version under PARALLELS is very slow whereas it is almost immediate under MAC OS.

"Very slow" is not good. If you take that state file and run the same test under MacOS, what happens? Note that plot speed can be affected by the choice of Y range when plotting using the solver, since YMIN and YMAX are used as the starting guesses.

If you get significantly different plot speeds when running the exact same test case with exactly the same settings (and again, I recommend using the same state file so you can be sure everything is the same), please send me the state in question and I'll take a look under both Windows and MacOS to see what's wrong.

(04-26-2022 12:12 PM)Pierre Mengisen Wrote:  On the other hand, the calculation of an integral between two terminals has become very slow under MAC OS (about 30 seconds for a few complicated functions).
It seems to me that in older versions it was almost immediate.

Calculating an integral, and especially an integral of a function calculated using SOLVE, can be slow if ACC is unset. If you set ACC to, say, 1e-6, is it still slow?

[Pierre Mengisen]

Yes you are right, that was the problem with the request for accuracy. I don't know why the ACC variable had been deleted. So the demand for precision was maximum.

The only difference I notice with the WINDOWS version is that it takes a while to draw the curve, about 2 seconds, whereas with the MAC version it is instantaneous.

Sorry for the inconvenience!

[Thomas Okken]

Yes, I see the same thing happening on my machine. The Mac version draws the circle plot instantaneously, while the Windows version takes one or two seconds, both the 32-bit and 64-bit versions. I'm running Windows in VirtualBox, but I don't think that makes a big difference in this case.

The issue here, just like with the earlier VITA initialization slowness, is that the Windows version performs all drawing operations immediately. All the others merely invalidate the affected display areas and then paint the display in the paint event handler, which is much more efficient when lots of display updates happen in quick succession.

I should change the Windows version to perform all painting in the WM_PAINT handler as well. I think I wrote the immediate-painting logic because I was concerned about responsiveness, but that really isn't an issue any more, after 17 years of CPU speed increases. There's no reason why the Windows version couldn't be just as fast as all the other, newer ones.

[Thomas Okken]

The iOS version is live in the App Store now. (link)
The Android version is still waiting for approval.
I changed the status of the app from "1.0 beta" to "1.0", but note that there have been no code changes since the last update.

[Steve Simpkin]

(04-29-2022 09:39 AM)Thomas Okken Wrote:  The iOS version is live in the App Store now. (link)
The Android version is still waiting for approval.
I changed the status of the app from "1.0 beta" to "1.0", but note that there have been no code changes since the last update.

Excellent! Just bought a copy for each of my iPhones (personal and work). Looks great! This is already my favorite calculator app.
Thank you Thomas!

[Thomas Okken]

Thank you!

[OlidaBel]

(04-29-2022 09:39 AM)Thomas Okken Wrote:  The iOS version is live in the App Store now.

Got it on Apple Store !
It overwrites the beta version, now it indicates a version 2.

Proficiat voor deze fantastische applicatie, Thomas !