Plus42 Equations, Preview Release

[Marco Polo]

(04-07-2022 12:39 PM)Thomas Okken Wrote:  

(04-06-2022 07:30 PM)Marco Polo Wrote:  Just tried to download the latest Android beta, but couldn't find the apk in the download page....

I put it back in the download folder.

Got it!
Thank you.

[johanw]

A small remark: in the readme from Plus42 I see: "Starting with release 1.4, Plus42 comes in decimal and binary versions." I assume this is one of the places where Free42 should not have been replaced by Plus42, since Plus42 is still on 1.0 (latest beta).

[Thomas Okken]

Indeed. Or rather, the "starting with release 1.4" part should be removed.

[Thomas Okken]

New update:

1. Short version: GSTO and GRCL weren't being saved to raw and state files. Fixed.
Long version: GSTO and GRCL are global-only versions of STO and RCL, used by the equation parser to generate code for L() and G() in HP compatibility mode (MODES→COMP). If you use compatibility mode, you should re-parse your equations to make sure you have no incorrect generated code left.

[jonmoore]

(04-07-2022 01:14 PM)Richard Garner Wrote:  Thomas

You might look at offering the Android version on both Amazon App Store and Google Play, Amazon devices are blocked from using Google and Google devices are blocked from Amazon.

Although in fairness to the prospective Plus42 user, they're just the sort of individual who will be aware that it's very easy to install the Google Play Store on their Amazon Fire device. I'm an iOS/iPadOS user but purchased the latest-gen Amazon Fire 10 Plus to test Android app builds. The bonus here is that I can make use of calculator emulators that are only available on Android (or beta builds, as is the case with Plus42).

This page details the steps you need to go through to download and install the Google frameworks necessary to install the Play Store on any Fire tablet released from 2014 onwards. And best of all, you don't have to hack your device (no rooting or installation scripts required).

https://www.howtogeek.com/232726/how-to-...re-tablet/

To be clear, I think it's sensible to offer Plus42 through the Amazon app store, but one needn't limit themselves to the paltry set of apps Amazon offers directly when it's so easy to install Google services onto a Fire tablet.

@Thomas, I'm really enjoying the tweaks to Plus42 over Free42. Especially the ability to use 27S/19Bii Equation solver techniques. However, owning a 19Bii and both DM42/DM41x, I believe the utility of the Equation solving techniques as outlined in "Step-by-Step - Technical applications for the HP-27S and HP-19B" would be streamlined if Plus42 had a proper alpha keyboard, instead of the HP-42s alpha keyboard. Entering equations can be a tedious affair (even with a proper alpha keyboard) but the workflow is at least eased with a dedicated alpha keyboard.

I don't believe you'd have to adulterate the 42S faceplate with alpha legends, but the skin could dynamically update when in alpha mode. I've obviously been spoilt by the dedicated alpha keyboard on the 19Bii but the dedicated alpha keys on the DM42 is one of the most significant workflow tweaks of the DM42 hardware over the 42S.

When using Plus42 via a desktop build, the lack of a dedicated alpha keyboard isn't a UX bottleneck. But with the ubiquity of tablets and phones, I suspect that the majority of Free42/Plus42 users are using mobile devices these days. I never program Free42 on a mobile device because of the lack of a dedicated alpha keyboard, and Plus42 seems like a perfect opportunity to streamline that particular mobile workflow barrier (especially if Plus42 is going to be a commercial offering on mobile platforms).

On another note, I was really pleased to see ARM64 support (for Raspberry Pi's). Our kids are massively into classic calculator emulators (who'd of thought!), so the ability to get Plus42 onto their Pi's was a lovely bonus. Building Plus42 was a little gnarly the first time as some of the necessary packages weren't in the default Debian archives but that in itself was a useful learning exercise for our budding nerds.

However, they each use 13" Arzopa portable monitors with their Pi'si which run at 'retina' resolution (the same as you get on 13" MacBook Pro's) so Plus42 is far too small in terms of its interface real-estate (luckily their young eyes are still able to see the tiny on-screen faceplate legends). I'm sure you've factored in greater pixel density screens in your mobile and macOS builds, so it would be good to have the same options on the Windows and Linux builds of Plus42. 'Retina' equivalent pixel density is commonplace on non-Apple/mobile hardware these days too.

[Vincent Weber]

(04-13-2022 10:38 AM)jonmoore Wrote:  @Thomas, I'm really enjoying the tweaks to Plus42 over Free42. Especially the ability to use 27S/19Bii Equation solver techniques. However, owning a 19Bii and both DM42/DM41x, I believe the utility of the Equation solving techniques as outlined in "Step-by-Step - Technical applications for the HP-27S and HP-19B" would be streamlined if Plus42 had a proper alpha keyboard, instead of the HP-42s alpha keyboard. Entering equations can be a tedious affair (even with a proper alpha keyboard) but the workflow is at least eased with a dedicated alpha keyboard.

I don't believe you'd have to adulterate the 42S faceplate with alpha legends, but the skin could dynamically update when in alpha mode. I've obviously been spoilt by the dedicated alpha keyboard on the 19Bii but the dedicated alpha keys on the DM42 is one of the most significant workflow tweaks of the DM42 hardware over the 42S.

When using Plus42 via a desktop build, the lack of a dedicated alpha keyboard isn't a UX bottleneck. But with the ubiquity of tablets and phones, I suspect that the majority of Free42/Plus42 users are using mobile devices these days. I never program Free42 on a mobile device because of the lack of a dedicated alpha keyboard, and Plus42 seems like a perfect opportunity to streamline that particular mobile workflow barrier (especially if Plus42 is going to be a commercial offering on mobile platforms).

An alpha keyboard would be nice to have, but on the other hand Plus42 greatly reduced its need, compared to the 19BII:
1) You have shortcuts for all importants functions: direct for L() and G(), programming menu for IF, S(), Sigma,... and full function catalog
2) You have access to all defined variables, so if you have a long variable you can just create it first, and then recall it rather than typing it every time.

[jonmoore]

(04-13-2022 10:44 AM)Vincent Weber Wrote:  

(04-13-2022 10:38 AM)jonmoore Wrote:  @Thomas, I'm really enjoying the tweaks to Plus42 over Free42. Especially the ability to use 27S/19Bii Equation solver techniques. However, owning a 19Bii and both DM42/DM41x, I believe the utility of the Equation solving techniques as outlined in "Step-by-Step - Technical applications for the HP-27S and HP-19B" would be streamlined if Plus42 had a proper alpha keyboard, instead of the HP-42s alpha keyboard. Entering equations can be a tedious affair (even with a proper alpha keyboard) but the workflow is at least eased with a dedicated alpha keyboard.

I don't believe you'd have to adulterate the 42S faceplate with alpha legends, but the skin could dynamically update when in alpha mode. I've obviously been spoilt by the dedicated alpha keyboard on the 19Bii but the dedicated alpha keys on the DM42 is one of the most significant workflow tweaks of the DM42 hardware over the 42S.

When using Plus42 via a desktop build, the lack of a dedicated alpha keyboard isn't a UX bottleneck. But with the ubiquity of tablets and phones, I suspect that the majority of Free42/Plus42 users are using mobile devices these days. I never program Free42 on a mobile device because of the lack of a dedicated alpha keyboard, and Plus42 seems like a perfect opportunity to streamline that particular mobile workflow barrier (especially if Plus42 is going to be a commercial offering on mobile platforms).

An alpha keyboard would be nice to have, but on the other hand Plus42 greatly reduced its need, compared to the 19BII:
1) You have shortcuts for all importants functions: direct for L() and G(), programming menu for IF, S(), Sigma,... and full function catalog
2) You have access to all defined variables, so if you have a long variable you can just create it first, and then recall it rather than typing it every time.

I agree with your points, but a dedicated alpha keyboard is useful as part of general calculator UX too. My alpha keyboard habits were probably learnt via my HP-41 use, but I find with the DM42, I seldom use the menus as I know most of the commands in a 42 without the need to dive into menus (well at least those commands I most commonly use). This speeds up general calculator usage significantly. I was using the equation solver use-case as an example as that's the Plus42 enhancement I've been using most often.

The story is much the same when using my DM41x. I generally use the same set of .mods on a day to day basis (mainly Angel's Sandmath family of modules, inclusive of his complex/matrix math modules). It's not a case that I memorise the whole of their available program catalogues but those that are part of the User keyboards and launchers you end up learning unconsciously without any dedicated effort.

I rely on menu diving on my 50g but that's because the library is massive, and the menus themselves minimise extra clicks.

[Thomas Okken]

(04-13-2022 10:38 AM)jonmoore Wrote:  [...] I believe the utility of the Equation solving techniques as outlined in "Step-by-Step - Technical applications for the HP-27S and HP-19B" would be streamlined if Plus42 had a proper alpha keyboard, instead of the HP-42s alpha keyboard. Entering equations can be a tedious affair (even with a proper alpha keyboard) but the workflow is at least eased with a dedicated alpha keyboard.

I don't believe you'd have to adulterate the 42S faceplate with alpha legends, but the skin could dynamically update when in alpha mode.

I agree. This is on my to-do list for 1.1.

I actually implemented support for the native on-screen keyboard in iOS and Android, so it slides up whenever ALPHA mode is activated. It was working fine in the iOS version, but I had problems with the Android version, where it worked fine in the Android Emulator, but didn't work at all on my Moto G5. I'll have to revisit that, but even if I can get it to work reliably, a DM42-style alpha keyboard may still be the better option, because the native keyboard isn't great for all the exotic characters in the HP-42S character set. And as you said, the alpha legends could be dynamically overlaid on the keyboard so they don't clutter it up when not in use.

(04-13-2022 10:38 AM)jonmoore Wrote:  On another note, I was really pleased to see ARM64 support (for Raspberry Pi's). Our kids are massively into classic calculator emulators (who'd of thought!), so the ability to get Plus42 onto their Pi's was a lovely bonus. Building Plus42 was a little gnarly the first time as some of the necessary packages weren't in the default Debian archives but that in itself was a useful learning exercise for our budding nerds.

You should only need to install libgtk-3-dev and libasound2-dev.

(04-13-2022 10:38 AM)jonmoore Wrote:  However, they each use 13" Arzopa portable monitors with their Pi'si which run at 'retina' resolution (the same as you get on 13" MacBook Pro's) so Plus42 is far too small in terms of its interface real-estate (luckily their young eyes are still able to see the tiny on-screen faceplate legends). I'm sure you've factored in greater pixel density screens in your mobile and macOS builds, so it would be good to have the same options on the Windows and Linux builds of Plus42. 'Retina' equivalent pixel density is commonplace on non-Apple/mobile hardware these days too.

I actually ported Free42 from GTK2 to GTK3 specifically to make it compatible with high-density screens (and Plus42 inherited that capability). If Plus42 doesn't notice the presence of a HiPDI screen, maybe you need to set GDK_SCALE=2, either globally or in whatever script or .desktop file is being used to launch the app.

[jonmoore]

(04-13-2022 11:35 AM)Thomas Okken Wrote:  I actually ported Free42 from GTK2 to GTK3 specifically to make it compatible with high-density screens (and Plus42 inherited that capability). If Plus42 doesn't notice the presence of a HiPDI screen, maybe you need to set GDK_SCALE=2, either globally or in whatever script or .desktop file is being used to launch the app.

Splendid news, GDK_SCALE=2 within the .desktop file should do the trick nicely. I've set up their desktops a little strangely as it has parts of the Cinnamon desktop (from Mint) hacked in, and interface scaling is generally handled on a per-app basis (where possible).

Raspberry Pi OS 64 is a great improvement on Raspian but terribly bland for teens who've grown up with the elegance of Apple UX conventions.

[Thomas Okken]

New update:

1. In the previous update, in addition to the fix for writing GSTO and GRCL in raw and state files, I also fixed the program byte count so it properly takes the size of GSTO and GRCL into account. Unfortunately, while fixing that second issue, I broke certain other byte counts, so functions like X=? "A" and CRDIR "A" were counted for one byte too many. This update fixes this.

[Thomas Okken]

New update:

1. STD/COMP mode override: To force an equation to be parsed in STD mode, regardless of the STD/COMP mode setting in the MODES menu, you can now insert :STD: between the equation name and the equation itself, or insert :COMP: to force the equation to be parsed in COMP mode. The name is still optional, so you can say, for example, :COMP:I/P=I/YR÷P/YR -- but don't forget that initial colon, or else the COMP part will be considered to be the name.

[Thomas Okken]

New update:

1. In EQN→CALC, fixed the check of whether or not to re-parse the current equation. It needs to be re-parsed if the MODES→STD/COMP setting has changed since the last time it was parsed, but not if the equation contains :STD: or :COMP: tags.

Also, removed a couple of restrictions, of which I can't even remember why I put them in in the first place:

2. Now allowing \(\pi\) as an alternate spelling of PI in both STD and COMP modes. It used to be allowed only in COMP mode for some reason.
3. Now allowing top-level = in equations with parameter lists. That is, PY(A:B:C):A^2+B^2=C^2 was not allowed, while PY:A^2+B^2=C^2 was; now they're both OK.

[Thomas Okken]

New update:

1. All versions except Android: made the skin loader more efficient, so it doesn't switch to 24-bit mode the instant it sees a local colormap in the GIF stream, but only when it actually needs more than 256 colors. Most skins aren't affected by this, but for those that are, this can save megabytes of RAM.

[Albert Chan]

(04-14-2022 01:17 PM)Thomas Okken Wrote:  New update:

1. STD/COMP mode override: To force an equation to be parsed in STD mode, regardless of the STD/COMP mode setting in the MODES menu, you can now insert :STD: between the equation name and the equation itself, or insert :COMP: to force the equation to be parsed in COMP mode.

I am not a fan of modes.
Why not remove STD/COMP mode altogether ?

This will force user to use the better STD mode.
Having variables named "I/P" or "X*Y" may be asking for trouble ...

Add the :COMP: tag to the "old" equation, but only as a stop-gap.

[Thomas Okken]

Modifying legacy code to comply with new standards can be tedious and error-prone. I like backward-compatibility modes for allowing legacy code to be used unchanged, without having to run the risk of introducing new bugs. But of course anyone can choose to ignore COMP mode and use STD for everything, that's up to each user to decide for themselves!

[toml_12953]

(04-15-2022 03:55 PM)Thomas Okken Wrote:  Modifying legacy code to comply with new standards can be tedious and error-prone. I like backward-compatibility modes for allowing legacy code to be used unchanged, without having to run the risk of introducing new bugs. But of course anyone can choose to ignore COMP mode and use STD for everything, that's up to each user to decide for themselves!

+1

[jonmoore]

(04-15-2022 03:55 PM)Thomas Okken Wrote:  Modifying legacy code to comply with new standards can be tedious and error-prone. I like backward-compatibility modes for allowing legacy code to be used unchanged, without having to run the risk of introducing new bugs. But of course anyone can choose to ignore COMP mode and use STD for everything, that's up to each user to decide for themselves!

I think this is a smart approach considering that many will 'program' equations based on listings in old HP documentation or online media resources. You're providing a more robust approach for those that want to make use of the new workflow, without punishing those who are relying on old documentation resources.

[Thomas Okken]

New update:

1. HEAD nn, when used with a string that was one character longer than the longest that can fit in a register in place (*), would corrupt the first few characters of the string. This happened because the old string would be freed before the new one was copied into the register, which isn't safe if the new string happens to be a substring of the old one, as is the case with HEAD.
This affects Free42 as well, and will be fixed in 3.0.11.
2. In the equation editor, the \(\pi\) key now inserts the \(\pi\) character in STD mode. In COMP mode, it still inserts PI.
Note that this is strictly a cosmetic issue, since \(\pi\) and PI are both recognized as the number \(\pi\), in both STD and COMP modes. But since the HP calculators with which COMP mode is supposed to be compatible don't have the \(\pi\) character, avoiding it makes sense for the sake of two-way compatibility.
3. Added \(\pi\) to the ALPHA menu, in the MATH submenu. This is so it can be entered into equations even in COMP mode.
4. The ▸ and ↵ characters didn't have appropriate small-chars versions for use in menus. Fixed.

(*) Strings are stored in the matrix array if they fit within the same space as a floating-point number, including one byte for the string length. In the binary version, this means that strings up to 7 characters can be stored in the array, and in the decimal version, strings up to 15 characters can be stored in the array. Longer strings are stored in memory that is allocated separately, outside of the array. Normally, this is transparent to the user.

[johanw]

When I run the Life program Thomas posted here on page 24, it initializes (the initial filling of the screen with random values) a LOT faster on my phone than on my laptop. Is that a difference between the windows and Android version or does that have another reason? It tends to run faster on my phone too but that difference is not as much.

The laptop is a modern i7, the phone runs a 2019 Exynos CPU so the laptop should have much more raw power.

[Thomas Okken]

When the VITA program initializes, it calls PIXEL for every black pixel, and it looks like it's repainting the entire display every time PIXEL is called. The subsequent calls to the LIFE function are a lot faster, because LIFE repaints the entire display all at once.

The PIXEL issue is on my to-do list. For certain settings, full display repaints are normal (e.g. the "always repaint entire display" mode, for preventing aliasing artifacts), but it looks like it may be repainting the entire display even in some cases where it shouldn't.

It's a non-issue in most contexts; the VITA program is a bit of an unusual case. But I am aware of the anomaly.