DB48X: HP48-like RPL implementation for DM42

[c3d]

(07-31-2023 10:29 PM)Helix Wrote:  

(07-30-2023 04:15 PM)c3d Wrote:  Video posted here: https://youtu.be/ehiX6mhlgAY. But YouTube has not processed the HD variant yet.

I enjoyed the video, except for the boring advertising every 3 minutes. I don’t know if it’s a new "feature" of Youtube.

Annoying, isn't it? Well, it means the video is "successful".

Remember the humble beginnings of YouTube, where one of the leading differentiators with TV was "no ads"?

Quote:{ 1 2 3 0 } 3 * should give { 3 6 9 0 } instead of { 1 2 3 0 1 2 3 0 1 2 3 0 }
I would be very disappointed if this behavior is kept, because I use routinely operations on lists.

This is the behaviour you get with vectors. For lists, HP has unfortunately implemented a behaviour that is inconsistent, where { 1 2 } 3 + gives { 1 2 3 } but { 1 2 } 3 * gets { 3 6 }. I decided to have a per-type consistent behaviour, i.e. always process component-wise for vectors and always consider that lists are created to manipulate data items that are not necessarily numeric.

In programs, the 'map' function always works on individual elements. So a way that always work is { 1 2 } « 3 + » MAP. It's not ambiguous, more powerful, and more efficient if you do complex operations because it does not have to deconstruct / reassemble the list many many times, i.e. { 1 2 } « 3 + 5 * SIN » MAP will extract the list content once, do operations on the stack, and rebuild the list once, whereas the same thing as {P 1 2 } 3 + 5 * SIN would rebuild the list three times.

Interactively, there is a reserved primary key on the keyboard at the moment, EEX. It does nothing while not editing. The intent is to have that key, where the yellow label is "DISP", cycle between various visible representations of the first level of the stack. For complex, it would switch between rectangular and polar, between fractions and decimal, and between vectors and lists. So if you want to run a bunch of operations on a list interactively, you hit EEX, turn it to a vector, do your operations, and then turn it back to a list. At least that's how I see things at the moment.

For many of these subtle per-RPL variations in behaviour, I believe that if memory permits, at some point I will have flags controlling what happens, with high-level commands like "HP28", "HP48", "HP50" or "newRPL" giving different default behaviours. I will be doing that last, though, because it's unclear that there is enough space in the DM42 to get more important stuff in. If the options don't fit, I will probably make them compile-time switches so that you can build the firmware with your preferences baked in. But again, relatively low priority. In any case, my philosophy is that this is a matter of taste, so if you don't like it as it works today but I do like it, we'll try to make it a user preference.

Note newRPL took a different approach, with "add" and "+" doing different things. Just to point out that I'm not the only one trying to figure out the correct approach ;-)

Quote:A small detail: the variable menu could use only one row in my opinion. Only the black row can be displayed, with the appropriate triangle after a shift press. This would give more space for the stack.

I like the three rows as a very visible indication of what operation happens (because the row is highlighted). But here too, I could certainly make it a preference.

Quote:Unless there is a good reason for the three rows?

The good reason is that on real HP48, I keep mixing store and recall and overwriting variables in the VAR menu. For whatever reason, my brain is wired backwards with that specific functionality.

Quote:Will the keyboard be re-definable, at list for some keys or shifted keys?

Yes. The infrastructure is actually already there, but the ASN function is not implemented yet.

Quote:The base conversion is a marvel, and I like the fact that it can go beyond 64 bits!

Thanks. I wonder if I should spend any time on stuff like 1-complement, which the HP16 supported. I've never had any use for it.