Plus42 Equations, Preview Release

[rprosperi]

Thanks for the link Thomas!

[nickapos]

Hey Thomas,

thanks for all the hard work you are putting into this. I have one request. Even though the unit conversion functionality in my HP Prime and my HP 50g is not my most used feature, it is handy for me occasionally and I have noticed that bit/byte conversions are missing.

Would it be possible to add bit/byte conversions in Plus42? If you do not have time for this I could maybe attempt to raise a pull request when the time is right, even though i have not written C for decades?

Best regards

[Thomas Okken]

(12-08-2021 07:42 AM)nickapos Wrote:  Would it be possible to add [...] conversions in Plus42?

Sure. The plan is to start by replicating the 48G's units, but once that's working, adding units (or changing them... I'm sure some of the conversion factors used in the 48G are out of date) should just be a matter of editing a table or two.

[nickapos]

(12-08-2021 09:35 AM)Thomas Okken Wrote:  

(12-08-2021 07:42 AM)nickapos Wrote:  Would it be possible to add [...] conversions in Plus42?

Sure. The plan is to start by replicating the 48G's units, but once that's working, adding units (or changing them... I'm sure some of the conversion factors used in the 48G are out of date) should just be a matter of editing a table or two.

Thank you very much

[Thomas Okken]

I noticed the 48G doesn't seem to care about the order of units in compound units; it has no preference for, say, N*m over m*N.

I thought, in the unit management logic in Plus42, I could do a bit better, and always put compound units in standard order. The problem: what is the standard order? Is there a reference for this?

[rprosperi]

(12-08-2021 10:35 PM)Thomas Okken Wrote:  I noticed the 48G doesn't seem to care about the order of units in compound units; it has no preference for, say, N*m over m*N.

I thought, in the unit management logic in Plus42, I could do a bit better, and always put compound units in standard order. The problem: what is the standard order? Is there a reference for this?

I don't believe there is an absolute standard, at least for many compound units, as it is often driven by the Engineering or Science discipline that you are in, for example torque is expressed (in US) as often in Foot-pounds as it is in Pound-feet. For other cases, there may be some guidelines, but I suspect HP would have checked that and concluded that not forcing a standard format would flexibly let users create and use them in a format they are accustomed to.

[Werner]

I found this:
Dimensions of derived quantities
It would seem the preferred ordering is L^a.M^b.T^c.... (see the article)
eg Newton would then be m.kg/s^2
(even if I have always learned it to be kg.m/s^2, but that is admittedly a long time ago)

Cheers, Werner

[Gjermund Skailand]

Hi Thomas,
if you are going to expand the functions for logic or bits it would be nice to have a "find first set bit function". Presently the fastest way I know of is to calculate IP(ln(X)/ln(2)+1) and possibly correct for rounding errors. Is there any faster way?

BR Gjermund

[Thomas_Sch]

(12-07-2021 09:13 PM)Marco Polo Wrote:  

(12-07-2021 12:41 PM)Thomas Okken Wrote:  Given all the changes since the first post of this thread, I thought it might be a good idea to post a little summary of all the new equation functionality...

Thank you very much.
I was getting a little lost....
Are you planning to implement a multiple equation solver similar to HP48 MES or Solvesys?

+1
many thanks to you, Thomas

[Thomas Okken]

(12-09-2021 08:56 AM)Werner Wrote:  I found this:
Dimensions of derived quantities
It would seem the preferred ordering is L^a.M^b.T^c.... (see the article)
eg Newton would then be m.kg/s^2
(even if I have always learned it to be kg.m/s^2, but that is admittedly a long time ago)

I think that article is just stating that every unit can be expressed as the product of integral powers of those seven base units; I'm not sure they mean to imply that those seven units should necessarily be written in that order. And even if they do, I'm inclined to ignore it, because it clearly violates established usage, as in kg usually coming before m, and it doesn't even help when it comes to compounds containing derived units, like N*m.

My current code sorts according to whatever order is used by std::map<string, int>, which I'm guessing just sorts by character code. This actually works rather well, since it sorts uppercase characters before lowercase ones, and that's exactly right in many cases.

[Klaus Overhage]

Are equal signs not allowed?

I downloaded the latest Plus42Windows.zip from here
https://thomasokken.com/free42/download/test/
Then I start Plus42Decimal.exe with a Double-click and press:
Shift SOLVER [=] [NEW]
And copy this example with CTRL-V into
PYTHAGORAS:A^2+B^2=C^2
ENTER
[CALC]
I always get "Invalid Equation" with a blinking cursor at the position of the equal sign. If I change the equal sign to a minus sign, [CALC] works. What am I doing wrong?

[toml_12953]

(12-10-2021 02:17 PM)Klaus Overhage Wrote:  Are equal signs not allowed?

I downloaded the latest Plus42Windows.zip from here
https://thomasokken.com/free42/download/test/
Then I start Plus42Decimal.exe with a Double-click and press:
Shift SOLVER [=] [NEW]
And copy this example with CTRL-V into
PYTHAGORAS:A^2+B^2=C^2
ENTER
[CALC]
I always get "Invalid Equation" with a blinking cursor at the position of the equal sign. If I change the equal sign to a minus sign, [CALC] works. What am I doing wrong?

Is post #85, point 2 relevant to this?

[Thomas Okken]

(12-10-2021 02:17 PM)Klaus Overhage Wrote:  Are equal signs not allowed?

I downloaded the latest Plus42Windows.zip from here
https://thomasokken.com/free42/download/test/
Then I start Plus42Decimal.exe with a Double-click and press:
Shift SOLVER [=] [NEW]
And copy this example with CTRL-V into
PYTHAGORAS:A^2+B^2=C^2
ENTER
[CALC]
I always get "Invalid Equation" with a blinking cursor at the position of the equal sign. If I change the equal sign to a minus sign, [CALC] works. What am I doing wrong?

That's a bug. It should disallow the equals sign when the equation has a name and an argument list, not when it only has a name and no argument list. I'll fix that tomorrow.

(12-10-2021 02:31 PM)toml_12953 Wrote:  Is post #85, point 2 relevant to this?

Yes. Apparently I botched that check.

[Thomas Okken]

New update: Units. They are under CATALOG: on the first row, UNITS has all the units from the 48G, and on the fourth row, UNIT has the unit-related functions.

This should all be pretty similar to the way it works on the 48G, with a couple of exceptions:

1. In addition to applying units using the UNITS catalog, you can type them alphabetically, by pressing Shift-Period during number entry. You have to finish the unit by pressing ENTER, or you can get rid of it by pressing EXIT.
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.

There's no support for units in programs or in the equation editor yet, nor in Copy and Paste. But they should work with arithmetic (including STO and RCL arithmetic), 1/X, X^2, SQRT, and Y^X (integer and 1/integer exponents only; with 1/integer exponents and SQRT, all the units must have powers divisible by the exponent, since units with non-integral exponents are not allowed, unlike on the 48G). Also, SIN, COS, TAN, →REC, and COMPLEX in POLAR mode will recognize angles with angular units and treat them appropriately, ignoring the current angle mode.

[roberto_abraham]

Wow! Units work great for me in Plus42. They're useful now and when they're supported in programs it'll be unreal. Thanks so much, Thomas!

[Thomas Okken]

New update: mostly bug fixes

WARNING!!!

For reasons I'll go into below, this new build will not handle older state files. If you have a state file with anything useful in it, be sure to export your programs and data first. In particular, you can save your equation list by copying the EQNS list on the HP-42S side, or by doing Copy in the list view on the Equations side.

Why the incompatible change?

Plus42 has a new data type, the equation object, that is a bit tricky to handle under the hood. On the one hand, it is a data object, using shared data, much like the matrix and list types. But on the other hand, it is also a code object, containing executable code, generated from the parsed expressions.

This mixing of data and code within one object type creates headaches because of the way state file persistence is handled in the Free42 code. I thought I had implemented a pretty elegant solution for this, but I could never really get the bugs out, as Vincent can attest. In the end, I decided to give up on it, and changed to a completely different approach.

The new approach is far simpler than the old one, and should be more robust. Unfortunately, I can't promise I didn't introduce any new bugs with this change, since it was rather drastic. But at least I should be able to actually troubleshoot this new logic, so it will eventually become as solid as Free42 again. I apologize for the upheaval, and thank everyone testing this for their patience!

The only other new thing is that this version finally treats ^ and ↑ as distinct characters.
And it fixes the bug with named equations.

[johanw]

The crash after each successfull start on my devices has vanished with this last release (the 12-12-2021 11:48 version). One device gave me an invalid state file after first startup but that was also gone after that first time.

[Thomas Okken]

That is good to hear.

I'm still no closer to understanding why the startup crash would happen on your devices in particular, but if getting rid of that flaky memory management logic also cured those crashes, I'll be happy to count my blessings and move on!

[Nigel (UK)]

(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?

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?

Nigel (UK)

[John Keith]

(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?

FWIW, the 50g also returns 1_yd/ft.