DB48X: HP48-like RPL implementation for DM42

[c3d]

(07-17-2023 06:20 PM)FLISZT Wrote:  Personally, I hope you won't stray too far from the standard RPL. Finally, its main flaw, at least on the latest RPL calculators (hp-49g+, hp-48gII and 50g), is that it hasn't been rewritten for the new ARM platform (+ possibly a few uncorrected bugs).
But things are what they are...

Indeed. My approach is to always parse the standard RPL as input, but to be able to render it (and parse it) differently.

For example, consider the `Dup` function. In DB48X, this can also be spelled `Duplicate`. There are preferences that let you display (and see it in the editor) as either `dup`, `DUP`, `Dup` or `Duplicate`. On input, you can spell it either way, as well as all case variants, e.g. `DUPLiCATE`.

As another example, complex numbers can be entered as `(1;2)`, which is the standard RPL syntax, or as `1ⅈ2` (which is a bit faster to type), or `1+ⅈ2`, or `1+2ⅈ`. They can render using the old RPL syntax or using the fancy display.

The same logic applies to exponents, i.e. you can type 1E32 even if it's rendered with a fancy small "x10" and superscript exponent; or to based numbers, where you can type #1AE3h even if it shows with a subscript 16 on screen.

Even the ->Text command uses the compatibility format, just in case. And the plan is for the state files to also always use it (though that is not the case today).

Quote:In my opinion, the best thing is for RPL on DM-42 to be compatible with what already exists, even if it means adding a few new features.

The new features being added don't normally get in the way of compatibility, except maybe in corner cases that will have to be treated like bugs. If you can elaborate on how you see new features breaking compatibility (even if you don't have a precise example yet), please file issues on the project's GitHub's page to track it.

Quote:I'm thinking possibly of the possibility of using anonymous (lambda) functions and even more so of the possibility of creating "STRUCT" structures à la C.

Lambdas are already a part of standard RPL. \lambdax(x+1) is written « → x 'x+1' » in RPL. You do not need to name that object.

Structs also exist, they are called "lists". However, RPL is a dynamically typed language, and I do not plan on adding statically typed data (it would really not help much in terms of speed or size given how things are implemented today).

What could integrate well into RPL is an extension of the current local syntax to split lists into components. Something like « → { x y } « x x * y y * + » » would turn { 1 2 } into 5. The same could make sense for arrays as well, e.g. « → [ x y z ] 'sqrt(sq(x)+sq(y)+sq(z))' » would compute the norm of a 3-vector.

We could have a variant where the last variable could get "the rest" if there are too many items, something like « → { x y z… } « x y z » » with { 1 2 3 4 } would give 1 2 { 3 4 }. Need to think about the precise way for this to "work well".

Note that this integrates well with an existing extension which is planned (does not work at the moment) which is local variables with lists, e.g. « → x { x x } », which builds a list with the same item twice (currently broken).

Quote:I know that all this is a question of room (and time...) but, speaking of room, is it useful to have as many mathematical functions as those available on a hp-50g?
I'll let you answer that question

The way the DM42 is structures, you have about 700K available for the "PGM", and about 2M in "QSPI". I tried to use the QSPI for code, but it's broken on the DM42, not enough power when on battery (works fine on USB power). So I can use it only for read-only data, e.g. tables.

At the moment, I'm at 597K for the PGM, but I was at 583K for the last release before complex numbers were implemented. In short, all of complex arithmetic and trancendental functions cost me about 14K of PGM space. That gives me hope I can fit almot all the original HP48 functionality there. And maybe a few HP50 extensions which are already there, like large integers.

As for all the mathematical capabilities of the HP50, maybe this will require the next DM32-based platform, which is speedier and has more room. I have a DM32 to try things out, but I need SwissMicros to release a SDK for it.