Plus42 Equations, Preview Release

[jonmoore]

@Thomas, I've noticed an inconsistency in the 'Big Stack'. CLST, correctly empties all of the stack slots, whereas CLX adds a zero to stack slot 1 (Big Stack otherwise behaves correctly, without stack lift).

This is just a visual inaccuracy, as the stack correctly adds whatever value you next enter to stack slot 1.

I primarily use Big Stack as I'm less concerned with running legacy 42S programs than I am in using the new hybrid features of Plus42 (which includes classic keystroke programming). However, the more I use Plus42, the more I feel that Big Stack is underutilized.

I have my working area set up with 15 rows and 35 columns. This is very much influenced by my historic use of the 50g. However, the only real benefit I get from the extended UI real-estate is that equations are more legible as many fit on a single row and most fit in no more than two rows.

What I'd really like to see implemented is 50g style Matrix and Complex Number entry/visual feedback. These days I tend to stick to the HP Prime for CAS workflows but there's nothing more elegant than the 50g for working with matrices. For example the following keystokes:

[[1 2 3 4 5] 6 7 8 9 10 11 12 13 14 15]

is automatically added to the stack as,



You set the number of columns with a single inset set of braces [] and the 50g automatically fills all subsequent number entries to the correct row and column position. Even though the Prime is the more modern hardware, when you have the 50g setup with its mini-font in the stack, the 50g is a vastly superior user experience when tackling linear algebra tasks (plus, there are some great RPL matrix libraries over at hpcalc.org).

The story's the same with complex numbers. Rectangular Format entry and visual feedback of complexes offers superior UX (better even than 35S complex entry/visual feedback).

I'm not suggesting you introduce RPL language on the Big Stack, just that you make better use of the real estate that's on offer with configurable rows and columns.

I still feel that Big Stack manipulation tools are far too hidden away in the CATALOG, but this issue will be less problematic when you introduce proper alpha entry. I did have one other thought on how this might be remedied. And that's via the USR keyboard. If the user is able to create custom command groupings of individual commands, they could e.g. create a single STK bespoke soft key with all the RPL style stack manipulation tools. I took heed of your point that these have the most utility when programming, but that for me means that ease of access is an even greater priority.