Plus42 Equations, Preview Release

[Thomas Okken]

New update:

1. XEQ in RUN mode, with a LBL from the catalog, would set the current directory to the directory containing the program. This is intended behavior for GTO in RUN mode, but not for XEQ. Fixed.
2. Paste didn't deal with 0x200b, zero-width space. Fixed, and also added code to handle 0x200c and 0x200d (zero width joiner & non-joiner), all three by ignoring them; and added code to handle 11 (vertical tab), 12 (form feed), 0x85 (Latin-1 line break), 0xa0 (Latin-1 non-break space), 0x2000 - 0x200a (Unicode spaces), 0x2028 (Unicode line separator), 0x2029 (Unicode paragraph separator), and 0x202f (narrow non-break space), translating them all to 0x20, standard ASCII space.

[Thomas Okken]

I posted landscape and shortened skins, for use in the Android and iOS versions, here.

I'll be adding logic to those versions later, to make them generate these skins on the fly, by modifying the standard Plus42 skin.

[Nigel (UK)]

Here's a couple of pictures showing a GTK version of Plus42 with an extended character set:





The code patches and extra files required are hosted at https://gitlab.com/njdowrick/extra-chara...ree/master, where the README.md file contains more details.

Right at this last moment, I've noticed a potential licensing issue: I've used characters from the WP34S project, which is licensed under GPL v3; but Plus42 is GPL v2. Does anyone know if this could be a problem?

Nigel (UK)

[Thomas Okken]

(02-08-2022 11:59 AM)Nigel (UK) Wrote:  Right at this last moment, I've noticed a potential licensing issue: I've used characters from the WP34S project, which is licensed under GPL v3; but Plus42 is GPL v2. Does anyone know if this could be a problem?

In the United States at least, I believe the answer is no: it's not a problem. Being a legal matter, though, nothing is ever quite that simple. See here, for example.

In Free42, I assumed that I could use the original fonts from the HP-42S, and so far, no one has told me otherwise. I seem to remember font copyrights being an issue when Apple was suing other companies over their copying of various aspects of the Mac user interface, and one ruling I read about specifically stated that low-resolution graphics (fonts and icons) cannot be protected by copyright, since there simply isn't enough room for creativity at low resolutions. In other words, form follows function, and in those cases, functional forms cannot be copyrighted.

[Nigel (UK)]

(02-08-2022 01:15 PM)Thomas Okken Wrote:  

(02-08-2022 11:59 AM)Nigel (UK) Wrote:  Right at this last moment, I've noticed a potential licensing issue: I've used characters from the WP34S project, which is licensed under GPL v3; but Plus42 is GPL v2. Does anyone know if this could be a problem?

In the United States at least, I believe the answer is no: it's not a problem. Being a legal matter, though, nothing is ever quite that simple. See here, for example.

In Free42, I assumed that I could use the original fonts from the HP-42S, and so far, no one has told me otherwise. I seem to remember font copyrights being an issue when Apple was suing other companies over their copying of various aspects of the Mac user interface, and one ruling I read about specifically stated that low-resolution graphics (fonts and icons) cannot be protected by copyright, since there simply isn't enough room for creativity at low resolutions. In other words, form follows function, and in those cases, functional forms cannot be copyrighted.

Reading your link, I think it's probably all right. If anyone from the WP34S project did object, all I'd have to do would be to remove the font.inc and the genfont_nd2 code and compiled program. The font patterns themselves would not be an issue.

I'll leave things are they are for now. Thank you for your comment!

Nigel (UK)

[Thomas Okken]

I noticed one thing that looked like a potential error in your patch: a comment that read "hollow right-pointing triangle. XtoA doesn't show this."

That is incorrect, XTOA does let you add the hollow right-pointing triangle to ALPHA, just not with the character code you might expect. In the font definition table, it follows right after the small-caps T, which makes it look like its character code should be 132, but it's actually 134, or 0x86, to correspond with the solid triangle having code 0x06. There's code in the character drawing routines to deal with this gap in the character code sequence.

[Nigel (UK)]

(02-08-2022 05:56 PM)Thomas Okken Wrote:  I noticed one thing that looked like a potential error in your patch: a comment that read "hollow right-pointing triangle. XtoA doesn't show this."

That is incorrect, XTOA does let you add the hollow right-pointing triangle to ALPHA, just not with the character code you might expect. In the font definition table, it follows right after the small-caps T, which makes it look like its character code should be 132, but it's actually 134, or 0x86, to correspond with the solid triangle having code 0x06. There's code in the character drawing routines to deal with this gap in the character code sequence.

Thanks. I had noticed the 134 -> 132 bit in the code but hadn't linked it with having the triangle code in the correct place. I've corrected the comment.

Nigel (UK)

[Eric Rechlin]

This is getting nicer and nicer all the time!

One unexpected behavior I have noticed with Units is that if you long-press a units softkey, it immediately says NULL but still performs the action (multiplies the value in X by that unit). With any other softkey that I've tried, long-pressing shows the action and then a bit longer shows NULL and cancels the action, which is what I would expect here too.

[Thomas Okken]

New update:

1. XEQ() didn't work in equations called from SOLVE or INTEG. Fixed.
2. When switching to a skin that only allowed 2 rows, while a 2-line message was in the display, the display would not get refreshed. Fixed.
3. Fixed NULL when pressing and holding unit keys.
4. Short, left-handed landscape, and right-handed landscape skins, now built into the Android and iOS versions. (This is causing the apps to grow by 1.5 megabytes; that bloat will go away when I integrate the logic to generate these skins from the original Plus42 skin into the apps themselves.)

[Werner]

Martin Hepperle's document mentions that it is necessary to include A*0 and B*0 in the equation:
L(X:A)*L(Y:B)*0+G(X)+G(Y)+A*0+B*0
or otherwise the solver would not find a solution.
I did not understand that, tbh, and it turns out Plus42 solves it without the A*0+B*0.
Is that just luck, and should the A*0+B*0 really be included?
Cheers, Werner

[Thomas Okken]

I'm not sure what the HP solver is doing there, but it sound like it considers L() to be invertible for its second argument, which would make the equation without the +A*0+B*0 a candidate for the direct solver. The direct solver would then fail, of course, because isolating A or B would lead to a division by zero.

The Plus42 solver does not consider L() to be invertible, so the appearance of the variable to be solved for as the second argument of L() immediately triggers the numerical solver. Also, with the Plus42 solver, a division by zero in the direct solver is not a fatal error, it simply falls back on the numerical solver in that case.

Should the Plus42 solver consider L() to be invertible? I had it that way initially, but changed it to non-invertible, I think because of questions about the evaluation order. If I had a test case for the HP solver, that uses L() with the variable to be solved for as its second argument, and works with the direct solver, and does something useful, I could revisit this issue...

[Werner]

I think I understand, and I prefer L() to be non-invertible ;-)

Thanks, Werner

[Thomas Okken]

New update:

1. PRLCD now fully supports the big display
2. Desktop versions: fixed 'g' => GTO mapping in Plus42 skin
3. Direct solver now puts the string "Direct" in the Y register, so you can easily check whether a solution was found by the direct solver or the numerical one
4. Fixed State File Corrupt when saving state while execution was suspended in code generated by the direct solver

[Thomas Okken]

New update:

1. When the direct solver moves a term from the left to the right of the = sign, it now adds it to the right of the RHS, instead of to the left. This should match the order in which the HP solver does this as well, and be more compatible with equations using L() and G().

[Thomas Okken]

New update:

1. Made L() invertible again. The example cited by Werner shows that L() is invertible in the HP solver, so it should be in Plus42 as well.
2. Better display size handling across restarts. Also, added GETDS and SETDS functions, for getting and setting the display size programmatically.
3. Now showing WSIZE, SIGNED, and WRAPPED indicators in the header line, while the BASE app or the third row of MODES are active.
4. Now allowing G(X) with undefined X in compatibility mode.
5. While editing equations, the X<>Y, +/-, period, and R/S keys are now relabeled to show the characters you can type with them.
6. L4STK did not fill the stack to 4 levels when used without FUNC. Fixed.

[Thomas Okken]

It looks like I was wrong to make L() invertible again. I have come up with a model of the behavior of the HP solver that appears to account for everything I've read and all the results from experiments that I've done so far, and it's actually pretty simple:

The HP solver tries the direct solver if the variable to be solved for appears exactly once, not counting appearances as the parameter of G() or S(), or as the first parameter of L(). The direct solver works its way towards the variable to be solved for, and any problem causes it to abort, but with an important difference: when it encounters a function for which it doesn't have a direct inverse (and that includes L()!), it aborts and moves on to try the numerical solver instead, but when it encounters a division by zero, it aborts and doesn't try the numerical solver, either.

This explains its behavior with L(X:A)*L(Y:B)*0+G(X)+G(Y): A and B both appear exactly once, making the function a candidate for the direct solver, but when it tries to isolate A, it gets

L(X:A)*L(Y:B)*0+G(X)+G(Y)=0
L(X:A)*L(Y:B)*0+G(X)=0-G(Y)
L(X:A)*L(Y:B)*0=0-G(Y)-G(X)
L(X:A)*L(Y:B)=(0-G(Y)-G(X))/0 <-- error: division by zero!

If that factor is anything other than zero, lets make it 3, the derivation becomes:

L(X:A)*L(Y:B)*3+G(X)+G(Y)=0
L(X:A)*L(Y:B)*3+G(X)=0-G(Y)
L(X:A)*L(Y:B)*3=0-G(Y)-G(X)
L(X:A)*L(Y:B)=(0-G(Y)-G(X))/3
L(X:A)=(0-G(Y)-G(X))/3/L(Y:B)

and then it's stuck because L() is considered non-invertible, so it can't isolate A from there.

Why the numerical solver is tried when the inverse fails because of a non-invertible function, but not when the inverse fails because of a division by zero, I don't know, but there you are. Adding +A*0+B*0 to the expression works because then both A and B appear more than once, so the direct solver isn't even tried, and the division by zero never happens.

[Werner]

(11-28-2021 10:12 AM)Thomas Okken Wrote:  1. Changed one-dimensional array/list indexing back from 0-based to 1-based, for compatibility.

But in the RPN environment, list indexing is 0-based?
Cheers, Werner

[Thomas Okken]

(02-14-2022 03:31 PM)Werner Wrote:  

(11-28-2021 10:12 AM)Thomas Okken Wrote:  1. Changed one-dimensional array/list indexing back from 0-based to 1-based, for compatibility.

But in the RPN environment, list indexing is 0-based?
Cheers, Werner

Register numbers are 0-based, but matrix indices are 1-based, and, in the equation environment on the HP calculators, so are Σ-list indices. But I see CFLO lists are 0-based, so that would mean that FLOW() and #T() are incorrect as they are now, being 1-based?

[Werner]

(02-14-2022 03:46 PM)Thomas Okken Wrote:  

(02-14-2022 03:31 PM)Werner Wrote:  But in the RPN environment, list indexing is 0-based?
Cheers, Werner

Register numbers are 0-based, but matrix indices are 1-based, and, in the equation environment on the HP calculators, so are Σ-list indices. But I see CFLO lists are 0-based, so that would mean that FLOW() and #T() are incorrect as they are now, being 1-based?

Yes, they are ;-) CFLO's are stored in Nx2 matrices (or Nx1) , so accessing them with CF[I:1] necessarily starts at index 1 though. B
What are Σ-list indices?
I meant lists created with NEWLIST, like

GET:SIZES(A)*0+ITEM(A:I)

If you pass it a two-element list in A, I=1 returns the first element. But in RPN, if A is a list, you get the first element with SUBSTR(0,1). But that would mean that GETITEM would have to work differently on lists vs matrices.

Werner

[Thomas Okken]

It sounds like I should change #T() and FLOW() to work with 0-based indices, and have them simply add 1 to those indices before passing them to GETITEM. Although that wouldn't agree with the behavior of ITEM(). Yuck. It's a bit messy since on the 17B, Σ lists are addressed using SIZES() and ITEM(), while CFLO lists are addressed using SIZEC(), FLOW(), and #T(), so it's OK for them to have slightly different semantics. But in Plus42, it's all general-purpose matrices and lists under the hood.

The goal here is just to have the equation language be as compatible as possible with the original. The fact that there is a bit of ugliness with 0- vs. 1-based indices under the hood is inevitable at this point. HP started it, just consider what happens with PRV "REGS" on the HP-42S.

Regarding Σ lists, that's how you enter data points for statistical calculations on the 17B and its ilk. I haven't used them myself, all I know from reading the 17B manual is that they use 1-based indices, while CFLO lists use 0-based indices.