Plus42 Equations, Preview Release

[Thomas Okken]

New build, fixing memory corruption while reading the state file on startup.

WARNING!!!

As with the previous update, this one is backwards-incompatible, so export your equations using Copy & Paste before upgrading. The memory corruption bug in the last version was so nasty, possibly leading to corrupted state files as well, that I think it's better to just treat all older Plus42 state files as radioactive waste at this point, and start fresh.

Again, apologies for the hassle! I do hope there will be state file stability from here on out...

[Thomas Okken]

(12-13-2021 10:36 AM)Nigel (UK) Wrote:  Another point: I've noticed that (for example) dividing 1_yd by 1_ft gives 1_yd/ft, rather than 3. (Adding zero to this does give 3.) Is this deliberate?

Yes, while multiplying and dividing, it doesn't do anything to simplify units, beyond making sure that no unit appears more than once. So it will collect ft*ft and turn it into ft^2, and ft/ft will cancel out, but there is no awareness that yd/ft = 3 at that point. It won't even recognize that m/cm = 100.

Adding zero happens to work in this case, but that's more of a side effect than a feature: when adding, the contents of Y are converted to match the units of X, and it is this conversion that causes the units to be simplified. If you were to do, say, 1_yd/ft ENTER +, you'd get 2_yd/ft.

This behavior is copied from the 48G, I figured it was OK because it's familiar, and because you can always simplify the units using UBASE or UFACT (or by adding 0, if you happen to know the real value is dimensionless).

(12-13-2021 10:36 AM)Nigel (UK) Wrote:  

(12-10-2021 09:15 PM)Thomas Okken Wrote:  2. Since there's only one shift key, LeftShift+Unit is not available as a shortcut to convert to a unit, you have to use CONVERT, or attach the desired unit to zero and add that to the number you want to convert. (That second trick doesn't work for converting to and from Celsius or Fahrenheit, though.) I'm still thinking about a less clumsy way to handle CONVERT.

How about using the decimal point as a left-shift key for CONVERT? If 14mm is in the display, then pressing "." "yd" would convert to yards without the need to press "+". Perhaps this could be made to carry out temperature conversions automatically as well?

I'm leaning towards a somewhat unorthodox UI: keep the unshifted unit the same, as it is now, but for shift+unit, pop up a menu, with choices "divide by," "convert to," "factor," and "cancel." It's a bit ugly, but it does have the advantage of making all the important functionality available with just one additional keystroke, and making it all really easy to find.

I haven't actually decided on that route, though. I am open to other suggestions...

[Thomas Okken]

New update:

1. +/- didn't work on unit objects; now it does.
2. Copy & Paste now work for unit objects, alone and in lists.
3. Double-checked all units in UBASE, and found a few problems: V (volt) had the wrong base unit; Fdy (faraday) had the wrong magnitude; °C and °F were handled incorrectly in UBASE and in derived units. All fixed.

[Thomas Okken]

New update: Fixed a memory leak. Pretty minor, but persistent, i.e. the leaked memory isn't even recovered by exiting and restarting. This update fixes the leak, and recovers the previously lost memory.

[rprosperi]

(12-13-2021 02:00 PM)Thomas Okken Wrote:  I'm leaning towards a somewhat unorthodox UI: keep the unshifted unit the same, as it is now, but for shift+unit, pop up a menu, with choices "divide by," "convert to," "factor," and "cancel." It's a bit ugly, but it does have the advantage of making all the important functionality available with just one additional keystroke, and making it all really easy to find.

I haven't actually decided on that route, though. I am open to other suggestions...

This is rather unusual, but I like it. As you say, all the options in the most expected place.

[Klaus Overhage]

I tried 18 equations successfully and didn't find a discrepancy until the nineteenth. The equation for the gamma function on the website http://www.rskey.org/hp19bii supplies negative values ​​for X greater than 0 with PLus42. To try it out, you have to change a comma into a colon beforehand (Q:Σ instead of Q,Σ) and make ABS (i) better ABS (I):

Code:

G=(-1)^Σ(I:X:0:1:1)÷EXP(Σ(I:X:15:1:LN(ABS(I))))×L(Q:Σ(I:X:15:1:1)+X)^Q÷EXP(Q)×SQRT(2​×PI÷Q)×EXP(((((1÷1188÷SQ(Q)-1÷1680)÷SQ(Q)+1÷1260)÷SQ(Q)-1÷360)÷SQ(Q)+1÷12)÷Q)

The problem is at the beginning of the equation in G = (-1)^Σ(I:X:0:1:1) or more simply in G=Σ(I:X:0:1:1). On the HP-17B, this form returns the value 0 for all X>0, but the Plus42 returns 1.

I love the Solve functionality of the HP calculators and I'm excited about Plus42. Thanks a lot for this.

[Thomas Okken]

New update:

1. Fixed Σ, so it doesn't execute the loop body if the condition evaluates to 'false' at the beginning. Also fixed its behavior for step sizes <= 0. Note that you'll have to re-parse your equations for this to take effect!
2. Comparisons involving units, including inequalities.

[johanw]

(12-05-2021 10:01 PM)toml_12953 Wrote:  

(12-05-2021 06:40 PM)johanw Wrote:  This immediately made me wonder is we'll ever see a Plus42 firmware for the DM42. Especially now that the first user fork of the DM42 firmware has been released.

You beat me to this question! With the expanded display, it seems like it would be a good fit.

I asked on the SwissMicros forum, but they seem not to plan an official Plus42 firmware for the DM42: https://forum.swissmicros.com/viewtopic.php?f=20&t=3163

Maybe someone else will do it and post it in the user firmware section.

[Thomas Okken]

(12-13-2021 02:00 PM)Thomas Okken Wrote:  I'm leaning towards a somewhat unorthodox UI: keep the unshifted unit the same, as it is now, but for shift+unit, pop up a menu, with choices "divide by," "convert to," "factor," and "cancel." It's a bit ugly, but it does have the advantage of making all the important functionality available with just one additional keystroke, and making it all really easy to find.

I'll put this on the low-priority to-do list for now. I find I can live with the zero-with-unit trick (that is, 0_m + to convert a length to meters, for example). Keystroke-wise it's as close to optimal as it's likely to get without adding a second shift key, and the only downside is that it doesn't work for converting to and from °C and °F. I can live with that. And when I do implement the menu, I could make it an option, so you could still get the current, tidy design if you prefer.

This means that, for now at least, the only missing unit functionality is the ability to use units in programs and equations. The programs part will be messy, the equations part should be easier. I hope I can get it to work before the end of the week, and then get started on directories. Saving the big screen for after the holidays!

(BTW I just noticed that unit pasting has completely broken the ability to paste complex numbers. I already have a fix for this, which will be in the next build. I also discovered that it is possible for the current program pointer to end up pointing into the jungle when program execution is stopped in generated code and the owning equation is then deleted. It's not a super-common scenario, I hope, but it can cause a crash. I'll fix that tomorrow, but in the meantime, if you see a bunch of gibberish when you switch to PRGM mode, just switch back out and use GTO to go back to any regular user code program, and nothing bad should happen.)

[Thomas Okken]

New update:

1. Fixed the bug that could leave the program pointer pointing to nowhere when clearing the RTN stack while program execution was stopped in generated code.
2. Fixed = and ≠ comparisons so they won't say "Inconsistent Units" when comparing things with inconsistent units, and just say "No" instead (for =, or "Yes", for ≠). "Inconsistent Units" is an appropriate message in <, ≤, >, and ≥ comparisons, but not in = and ≠.
3. Made unit pasting pickier, so it no longer interferes with pasting complex numbers, and more generally will no longer treat anything like a unit unless it actually recognizes the unit.

[Albert Chan]

I tried to implement TVM, rearranged to match HP12C order: N,I,PV,PMT,FV

TVM: (1/EXPM1(N*LNP1(I))*(PV+0*PMT+FV)+PV)*I+PMT=0

Curiously, if I expand the expression, cut/paste to calculator:

1/EXPM1(N*LNP1(I))*(PV+0*PMT+FV)*I+PV*I+PMT

All I get is 1, not the string.

Looking further, "E" caused the parsing issue.
"Everything" --> <Not a Number>
"1+E" --> 1
"1-E" --> 1
"1*E" --> 1
"1/E" --> 1

[Vincent Weber]

(12-15-2021 03:25 PM)Albert Chan Wrote:  I tried to implement TVM, rearranged to match HP12C order: N,I,PV,PMT,FV

TVM: (1/EXPM1(N*LNP1(I))*(PV+0*PMT+FV)+PV)*I+PMT=0

Curiously, if I expand the expression, cut/paste to calculator:

1/EXPM1(N*LNP1(I))*(PV+0*PMT+FV)*I+PV*I+PMT

All I get is 1, not the string.

Looking further, "E" caused the parsing issue.
"Everything" --> <Not a Number>
"1+E" --> 1
"1-E" --> 1
"1*E" --> 1
"1/E" --> 1

If I paste this equation while in the equation editor, the whole equation is perfectly recognized.
Do you mean that you tried to paste this equation in the stack ? In that case it is normal that it is parsed as a number...

[Albert Chan]

(12-15-2021 06:39 PM)Vincent Weber Wrote:  If I paste this equation while in the equation editor, the whole equation is perfectly recognized.
Do you mean that you tried to paste this equation in the stack ? In that case it is normal that it is parsed as a number...

Yes, I tried to paste to the stack, to check the right name for "E↑X-1"

EXPM1(1) --> <Not a Number>

Then, I lookup core_equations.cc, and "EXPM1" is there.

[Thomas Okken]

Hmm, yes... the code that pre-selects what type to interpret the clipboard as, is too eager to see things as numbers. In EXPM1(1), it sees the E and thinks "aha! number!" but then the actual number parser is less enthusiastic and <Not a Number> is the end result. I'll fix that in the next build.

BTW, you can check the spelling of functions by trying them with the FCN catalog in the equation editor. The labels on the keys and the actual names used in equations are different in some cases, like E^X-1 vs. EXPM1 or 10^X vs. ALOG. I mostly tried to follow the lead of the 17B there; inconsistencies are bound to happen because the 17B and 42S use different names here and there, and I tried to be consistent with the 17B in the equations part while remaining true to the 42S elsewhere.

[Thomas Okken]

New update: Units in programs.

Note that you have to spell out units order to enter them in program mode, you can't use the UNITS catalog for this. I'll see if I can figure out a decent way to use the UNITS catalog in program mode after I add unit support to the equation editor.

[Ren]

What is the difference between Plus42 and Free42?

[Thomas Okken]

(12-16-2021 09:00 PM)Ren Wrote:  What is the difference between Plus42 and Free42?

Everything you read in this thread!

Plus42 is an extended version of Free42, currently under development. It will feature all the capabilities of Free42, plus equations (modeled on those found in the HP-17B, 19B, 27S, etc., this is finished), attached units (modeled on those found in the HP-48/49/50 series; almost done), and directories for hierarchical storage of programs and variables, and support for larger display sizes, coming soon.

This will be a separate product, GPLv2 and free for Windows, MacOS, and Linux, and priced at something like €10 for Android and iOS. Price not yet decided, release probably in January or February.

[Thomas Okken]

New update:

1. Basic unit support in equations. The syntax is slightly different from units in normal RUN and PRGM modes, in that the units must be enclosed in double quotes. So, instead of 16_oz, you write 16_"oz". What's going on here is that the units are actually string literals, and _ is a multiplicative operator that creates a unit object from a number on its left and a string on its right. (In compatibility mode, _ is an identifier character, so it's not available to use as an operator; in this case, the syntax UNIT(16:"oz") can be used instead.
2. Made number pasting a bit pickier, so it doesn't try to treat strings that start with E (like EXPM1(1)!) as numbers.
3. Can now create unit program lines with X2LINE.
4. Added UNIT? function.
5. Unit normalization: now replacing × ÷ ↑ with * / ^ in unit strings.

[roberto_abraham]

Hi Thomas,

What would you recommend as the best approach for incorporating physical constants into equations? As a simple example, I'd like to store the relationship between wavelength and frequency:

nu=c/lambda

where of course nu is frequency and lambda is wavelength and c is the speed of light. Plus42 lets me store the speed of light as an equation:

c:300000_"km/s"

however I'm not sure how to incorporate this constant into other equations. For example, I can imagine either of these being the appropriate syntax:

nu(lambda):c/lambda
nu=c/lambda

However in both cases the speed of light defined earlier is not being used. I could certainly include the physical constant directly into the equation:

nu=300000_"km/s"/lambda

However it would be very handy to be able to refer to physical constants symbolically.

Thanks,

Bob

[Thomas Okken]

You could write

C:300000_"km/s"

and then refer to it as C(), that is, a function call without passing arguments.

The only alternative, if you want to avoid the parentheses, would be to create a variable on the RPN side:

300000_km/s STO "C"

You could refer to that simply as C in your equations. It would be a variable, though, not a constant...