Plus42 algebraic expressions update

[Vincent Weber]

Oh and one more thing: the 27S allows to enter the PRINT menu in the equation editor, in both list mode et editing mode. This is most useful to print both the equation list and the current equation (especially because we only have one line to edit). Now I understand the whole equation list could be printer by printing the EQNS variable, but to print the current equation there is no easy solution. The 27S has a dedicated PRT key that helps, which the 42S doesn't have. Any idea ?

Cheers

[Vincent Weber]

Another thing.
In a previous version, using ->REC and ->POL in the equation editor would neatly convert this into XCOORD (YCOORD with shift), and RADIUS (ANGLE with shift), which I found was a very neat way to emulate the 27S solver functions without touching the 42S menus.
Now, in the current version, this is changed to REC() and POL()... why ?

Cheers,

Vincent

[Thomas Okken]

(02-28-2021 08:49 AM)Vincent Weber Wrote:  it is great to be able to access the catalog from the equation editor, but this is the old catalog, not the new one with extended functions organized in groups ? Why ?

It's a subset of the old catalog, showing only the functions that are usable in expressions. That's a much shorter list than the complete catalog, so organizing it in groups seems a lot less useful here.

(02-28-2021 09:19 AM)Vincent Weber Wrote:  the 27S allows to enter the PRINT menu in the equation editor, in both list mode et editing mode. This is most useful to print both the equation list and the current equation (especially because we only have one line to edit).

Ah, yes, I forgot about printing. Noted!

(02-28-2021 12:19 PM)Vincent Weber Wrote:  In a previous version, using ->REC and ->POL in the equation editor would neatly convert this into XCOORD (YCOORD with shift), and RADIUS (ANGLE with shift), which I found was a very neat way to emulate the 27S solver functions without touching the 42S menus.
Now, in the current version, this is changed to REC() and POL()... why ?

The 27S doesn't have a complex type, so the rectangular/polar conversions must be provided by pairs of functions, XCOORD/YCOORD and RADIUS/ANGLE. The 42S does have complex numbers, and vectors, so the conversions can be done in single functions.

I think I'll also implement the 27S-style functions, for compatibility, but given the 42S' capabilities, providing REC() and POL() seems like the more natural option.

[Vincent Weber]

Thanks Thomas.
Noted for the catalog and printing (I think that allowing shift PRINT to print the current equation should do the job - the whole equation list can be print using PRV "EQNS").
As for complex numbers, well, I'm not too sure on how they would blend easily with the solver, that's why I thought that the 27S-style was more appropriate. Besides, typing XCOORD is quite long...

By the way, any intention to implement (after equations of course) the list-based stats of the 27S ? Or playing with matrices in user code (like the programs in the 42S manual) should do the job ?

Cheers

[Thomas Okken]

Once you've hit CALC, you'll be back in the HP-42S environment, where entering a complex number is as easy as typing x ENTER y COMPLEX. The numerical solver can't solve for a complex value, but the symbolic solver will be able to, and there's no reason not to allow any type for the variables that aren't being solved for as well.

Regarding list-based statistics, I haven't thought about those yet. Is that a SOLVE feature?

[Vincent Weber]

Wow, are you going for symbolic solving as well ? I thought in a previous discussion we said it would be useless: in the 27S symbolic solving is limited to isolating a variable when it appears only once formally (i.e. not within G()). This feature can also easily be done by numerical solving, so why bother, but if you are ambitious.... Anyway that does not change the fact that real numbers solving with single parts (XCOORD...) is useful, whereas I don't see how this could be achieved in a complex environment... enlighten me please

Re list-stats, well that's not stricly speaking a solver feature. Its only link wiht the solver is the ITEM function, that allows to get (but not set, as discussed, which is a pity) a value in a given list at a given index. Of course you will be able to do this with matrices, in a 2-dimensial way so more flexibily. Still, list-stats are nice, they allow you to review all the statistical values that have been entered (not possible with the SIGMA+ sytem used in RPN-based calculators). For you to see at latter stage maybe

Cheers,

Vincent

[Thomas Okken]

Symbolic solving, 17B/27S style, is so easy to implement that I can see no reason not to.

As far as XCOORD etc. are concerned, they will be available.

[Vincent Weber]

For symbolics, ok, fine with me, that exceeds my wishes !

As for XCOORD, sure I understand you will parse them, but I liked the idea to generate them by touching REC and POL, rather than typing them/going to catalog. Oh well. I trust you, you're the man

Cheers,

Vincent

[Thomas Okken]

5:26 PM EST / 22:26 UTC -- New build. PRINT now prints the current equation.

Also fixed PRX, PRSTK, PRV, and PRUSR, so they print long strings in full, rather than cutting them off at 100 characters.

[Vincent Weber]

Awesome Thomas, many thanks.
Funny thing is that the print annunciator is not triggered when printing the current equation, unlike for other printing functions...

Also, the simplified catalog does not include all the solver functions, like DDAYS, USPV,.. and the ones we talked about, XCOORD etc... But I guess you will add them as needed ?

Cheers

[Thomas Okken]

(02-28-2021 10:38 PM)Vincent Weber Wrote:  the print annunciator is not triggered when printing the current equation

Yep, I noticed that right after I uploaded the build. I fixed it but the fix is not in the builds that are up on my web site now.

(02-28-2021 10:38 PM)Vincent Weber Wrote:  Also, the simplified catalog does not include all the solver functions, like DDAYS, USPV,.. and the ones we talked about, XCOORD etc... But I guess you will add them as needed ?

It does include DDAYS. As for financial functions, those aren't on my radar yet.
XCOORD etc., I'll deal with them once the parser and the solver integration are working.

[Vincent Weber]

Thanks Thomas, understood.
I had missed DDAYS for some reasons.
As for financial functions, they are part of the 27S (for some of them like USPV) and the 19B (more complete set with direct FV, PMT...), but anyway the good part is that since you will allow user-defined functions, we will always been able to add whatever is missing with such a UDF

Cheers

[Thomas Okken]

10:33 PM EST / 3:33 UTC -- New builds. Fixed the print annunciator in the equation editor, and implemented proper error handling. Also, fixed printing of long strings in lists, removing the length limit.

The equation editor is now complete, except for support for additional functions which will be added as needed, and of course whatever bugs still remain to be found. (Not too many, I hope! I tested it by throwing megabytes of text at it, both pasted and generated within the app, and it handled that without choking.)

Update: With error checking, introduced a bug that prevented saving an equation. New build at 11:18 PM EST / 4:18 UTC that fixes this.

[Vincent Weber]

Thanks Thomas ! Maybe just missing a shortcut for IF( as spoken, maybe on top of FLAGS or STAT...

Cheers

[Vincent Weber]

Actually wrt to what I was saying about 27S-style list stats, I think we can rule this out. I didn't realize that the 42S can use SIGMA+ with a matrix argument, which means you can store and edit your statistical data in a matrix, which has all the advantages of lists and more (and the GROW option let it grow as wanted). Pages 146-150 and programming examples pages 174-194 of the 42S programming techniques book cover this in great details.

So you could implement ITEM not on lists, but on matrics, in the form ITEM(NAME:i:j) and not just ITEM(NAME:i), and let this be a argument of L(), and you will retain a high level of compatibility with the 27S (just add an argument to ITEM) while using the full power of the 42S

Cheers

[Thomas Okken]

I'll add keyboard and/or menu mappings for IF(, and various other functions, as I implement them. Work on the parser starts today...

Yep, ITEM() should support two-dimensional indexing. In addition, I'll add square bracket syntax, so instead of the familiar but cumbersome ITEM(A:1), you'll be able to write A[1]. And you should be able to apply it to matrices and to lists, and you should be able to provide a single index when indexing an Nx1 or 1xN matrix, i.e. treat it as a vector.

[Vincent Weber]

Thanks Thomas.

I fully concur with you that the ITEM syntax is cumbersome and that the bracket syntax is much more efficient - especially with the 2-key stroke alpha entry system !
You said it should apply to lists ? but we have no lists in the 42S world ?

Cheers

[Thomas Okken]

(03-01-2021 12:33 PM)Vincent Weber Wrote:  You said it should apply to lists ? but we have no lists in the 42S world ?

Not in the 42S world, but we do in Plus42. Use NEWLIST to create a new, empty list, APPEND and EXTEND to add stuff to it, and HEAD to iterate over it.

This is all still rather rudimentary. I implemented the list data type because it made implementing FUNC, L4STK, and LNSTK a lot easier, and I exposed it to the user environment, because why not.

[Vincent Weber]

Thanks Thomas.
Sorry I had not followed closely enough what you have done with strings and lists - I'm mostly interested in equations That's awesome that you have implemented lists !

Cheers

[Vincent Weber]

I think I found a bug in Plus42.
Playing with strings and lists, i don't know how I got there, but I ended up with an "UnsupportedVarType" strange object on the stack. Trying to use "COMPLEX" on 2 identical numbers on X and Y (the strange object being in T) resulted in a surprising "insufficient memory". Deleting the strange object made things back to normal, and the COMPLEX number generation to work fine again.

Any idea ?

Cheers