DB48X: HP48-like RPL implementation for DM42

[c3d]

(05-20-2024 05:03 AM)sunpazed Wrote:  Hi Christophe — you might be interested in this little side project of mine. As a proof-of-concept, I built a version of your simulator that runs in the web-broswer (and therefore on mobile devices). I found that Qt runs fairly sluggishly after some time, so that was part of my motivation. It's also quite nice to use db48x in the palm of your hand (as I don't yet have a dm42!).

Here's what it looks like on my iPhone;


Try it in your browser here — the simulator can be run fullscreen by selecting "Add to Home Screen" on iOS or your Android device;
https://sunpazed.github.io/db48x-wasm/bin/index.html

Be warned that there are many bugs, with the simulator hanging when accessing system services (help, save state, system menu) which are not implemented .

And finally here's the repo for review; https://github.com/sunpazed/db48x-wasm — apologies in advance for butchering your excellent code.

This is amazingly cool. I will see if I can merge your code with the main repo in a meaningful way, so that you don't have to reapply the patches every time. Also, I found a few bugs here and there, and it would be nice if the fixes specific to wasm and the main branch were kept in sync easily.

That being said, I don't recommend this approach for mobile devices, since it's bound to consume a lot more resources, which are a bit scarce. So while I fully intend to leverage your work for example to integrate in the web site, I think that we need to have native versions for mobile phones.

For Android, I have not reinstalled the SDK in a while, but my recollection was that targeting the Android SDK with Qt was relatively easy. Like for Windows, it would be nice to have someone familiar with the platform picking that up. Otherwise, I'll do that myself "sometimes in the future™".

For iOS, I have a native version that is working on both iPhone and iPad. I need to spend the time to go through the hoops to get it published on the Apple Store. This is one of the reasons why there is colour support in the simulator ;-)

[spiff72]

Seeing this project show up for iOS I'm the App Store will be an exciting day for me! Does that make me a full-fledged calculator nerd?

And this web based side project is pretty cool!

[c3d]

(05-20-2024 06:39 AM)Steve Simpkin Wrote:  

(05-20-2024 05:03 AM)sunpazed Wrote:  Hi Christophe — you might be interested in this little side project of mine. As a proof-of-concept, I built a version of your simulator that runs in the web-broswer (and therefore on mobile devices). I found that Qt runs fairly sluggishly after some time, so that was part of my motivation. It's also quite nice to use db48x in the palm of your hand (as I don't yet have a dm42!).

Here's what it looks like on my iPhone;


Try it in your browser here — the simulator can be run fullscreen by selecting "Add to Home Screen" on iOS or your Android device;
https://sunpazed.github.io/db48x-wasm/bin/index.html

Be warned that there are many bugs, with the simulator hanging when accessing system services (help, save state, system menu) which are not implemented .

And finally here's the repo for review; https://github.com/sunpazed/db48x-wasm — apologies in advance for butchering your excellent code.

I can't tell you how awesome your side project is! I have been wanting to play with the DB48X project for so long but did not have access to a Mac or linux computer. Thank you very much!

I have added some links and general information about the HP48X project along with your side project to the features comparison table and photo gallery site I maintain.
https://sites.google.com/view/hp-plus-ca...sykspy4p3m

Great page. Thanks a lot for maintaining it!

[c3d]

(05-20-2024 12:49 PM)spiff72 Wrote:  Does that make me a full-fledged calculator nerd?

You had any doubt about this?

[sunpazed]

(05-20-2024 12:46 PM)c3d Wrote:  This is amazingly cool. I will see if I can merge your code with the main repo in a meaningful way, so that you don't have to reapply the patches every time. Also, I found a few bugs here and there, and it would be nice if the fixes specific to wasm and the main branch were kept in sync easily.

That being said, I don't recommend this approach for mobile devices, since it's bound to consume a lot more resources, which are a bit scarce. So while I fully intend to leverage your work for example to integrate in the web site, I think that we need to have native versions for mobile phones.

For iOS, I have a native version that is working on both iPhone and iPad. I need to spend the time to go through the hoops to get it published on the Apple Store. This is one of the reasons why there is colour support in the simulator ;-)

Thanks Christophe — I'm glad you like it! Also happy to hear that you have native apps in the works — this will be much better for performance, and will make it easier to save and manage state when the app closes, etc.

Also, I found an interesting bug while developing this. Evaluate '65!/8888' and the calculator only displays the fractional part which is '58/101'. "SHOW" also only displays the fractional part. The integer part is still there — you can divide by 65 to see it. I believe this is a display issue caused by large numbers with many digits.

[c3d]

(05-21-2024 02:04 AM)sunpazed Wrote:  Also, I found an interesting bug while developing this. Evaluate '65!/8888' and the calculator only displays the fractional part which is '58/101'. "SHOW" also only displays the fractional part. The integer part is still there — you can divide by 65 to see it. I believe this is a display issue caused by large numbers with many digits.

Thanks the bug report. Tracked as issue 945. The fix will be in the next release.

[mahi]

First of all I'd like to express my thanks to Christophe for developing DB48X/DB50X! I had given up hope on a new physical RPL calculator, but this project looks very promising.

I discovered a few quirks I did not see in the github issues (I might not have looked very well). I'm using version 0.7.6.

In the syntax below [xx] indicates a button or soft key.

1 2 / [+/-] has a visualization bug: There are 2 minus signs in the fraction

2 [+/-] [+/-] gives 2, but '2' [+/-] [+/-] gives -(-2). Repeatedly pressing [+/-] just adds additional negation symbols instead of inverting the previous. Same issue happens with [1/x]. In fact, it also happens when alternating between square root and power of 2, log and 10^x, asin and sin,...

When you put a symbolic constant on the stack, like π, and press the [E] button (EEX), you get "cycle error: bad argument type". I understand that DB48X does not have an alternative representation for these, but it should not give an error. Pressing [E] on a variable name works fine (toggles between 'variable' and variable).

I like the idea of the [E] button cycling between visualizations and units, but it's not always consistent. For example 2_in [E] gives 50 4/5 mm and 5 2/25 cm, while in this case decimal notation would be preferred. A direct conversion to mm with [→mm] gives the same effect. So, I need an extra [→Num] operation to get the decimal value, whereas when I enter 50 4 5 / + [E], it shows me 50.8 immediately. I can work around this by entering 2._in, but it's bit strange in my opinion. Maybe I shouldn't be using the calculator in symbolic mode?

By the way, owners of an existing overlay may not like it, but I really think [→Num] should be accessible directly from the keyboard (update: already a github issue)

Entering 1000000_mm and then repeatedly pressing [E] alternates between 1000000 mm, 100000 cm and 39370 10/127 in. However, entering 1_km (which is exactly the same) reacts completely different to the [E] button: 1 km, 1/1000 Mm, 1/1000000 Gm, 0.000001 Gm, 0.001 Mm, 1.km, 10. hm, 100. dam, 1000. m, 10000. dm, 100000. cm, 39370.07874...in, 1000000. mm (from here pressing [E] keeps alternating between the last 3).

Entering 0.005_A and then repeatedly pressing [E] cycles between 0.005 A, 0.05 dA, 0.5 cA, 5. mA, 5000. µA, 5000000. nA, 5000000 nA, 5000 µA, 5 mA, 1/2 cA, 1/20 dA, 1/200 A, 1/2000 daA, 1/20000 hA, 1/200000 kA, 1/200000000 MA, 0.000000005 MA, 0.000005 kA, 0.00005 hA and 0.0005 daA. That's an awful lot of notations, and prefixes like centi, deci, deka and hecto are not that common with many (most?) units.

I'm not really sure what the best solution is for this, but maybe a toggle can be added to show only engineering prefixes?

When you have an expression on level 1 of the stack, pressing [E] also changes the rendering of expressions at deeper stack levels. I think I understand why it does that, but it's weird because if a non-expression is in level 1 you can't change the rendering of expressions on deeper levels.

Create a list 1 2 3 3 [→List]. Executing 4 [Get] gives index out of range (as expected), but 4 4 [Put] gives an out of memory exception. I don't think it's supposed to do that.

Maybe I looked over it, but one feature I miss when it comes to stack manipulation is the Up arrow behavior of the HP 48/50 series. Pressing Up on the HP 48/50 allows you to quickly pick or echo an item at a deeper stack level. I know you can do <num> [Pick], but sometimes you want an older item that is no longer in the viewable area of the stack. Similarly, the Up arrow lets you quickly create a list (like <num> [→List]).

[mahi]

I discovered a bug with the solver. It doesn't work when certain constants are in the equation.

For example 'E=m*c²' returns error "bad guess" when solving E or m. When substituting constant c for π (pi) or e, it does work.

Update: And another issue (maybe). Set 'E=m*c²' for the solver with [>Eq] soft key, then recall with the [Eq>] soft key. The equation changed to 'E-m*c²'. While mathematically correct, that's not the equation I saved. Or is this intentional?

I had another weird issue but I cannot reproduce it. I had several equations on the stack containing constants and was playing with the solver. At one moment I noticed that equations deeper in the stack no longer showed the constant name but it was substituted with "Chem".

[c3d]

(05-27-2024 08:37 PM)mahi Wrote:  First of all I'd like to express my thanks to Christophe for developing DB48X/DB50X! I had given up hope on a new physical RPL calculator, but this project looks very promising.

I discovered a few quirks I did not see in the github issues (I might not have looked very well). I'm using version 0.7.6.

In the syntax below [xx] indicates a button or soft key.

I appreciate the feedback, but it would make my life easier if you filed issues on GitHub instead of reporting here. I will file what you described here. Let me just address one thing I will not file because it's intentional.

Quote:I like the idea of the [E] button cycling between visualizations and units, but it's not always consistent. For example 2_in [E] gives 50 4/5 mm and 5 2/25 cm, while in this case decimal notation would be preferred. A direct conversion to mm with [→mm] gives the same effect. So, I need an extra [→Num] operation to get the decimal value, whereas when I enter 50 4 5 / + [E], it shows me 50.8 immediately. I can work around this by entering 2._in, but it's bit strange in my opinion. Maybe I shouldn't be using the calculator in symbolic mode?

This is intentional. This is intended to demonstrate customizable cycles, and I used for that demonstration a scenario that @spiff72 uses often, the conversion between mm and inches.

There are two cycles configured in the units.csv file:

"=Cycle"
"in", "mm"
"mm", "cm"
"cm", "in"
"USD", "EUR"
"EUR", "CHF"
"CHF", "USD"

So when you enter one of in, mm or cm unit, then the cycle takes priority over the normal behaviour. Same if you enter USD, EUR or CHF.

Quote:By the way, owners of an existing overlay may not like it, but I really think [→Num] should be accessible directly from the keyboard (update: already a github issue)

Yes, it's done now, it's on the "ASN" (which I remember as "As Number").

Quote:Entering 1000000_mm and then repeatedly pressing [E] alternates between 1000000 mm, 100000 cm and 39370 10/127 in. However, entering 1_km (which is exactly the same) reacts completely different to the [E] button: 1 km, 1/1000 Mm, 1/1000000 Gm, 0.000001 Gm, 0.001 Mm, 1.km, 10. hm, 100. dam, 1000. m, 10000. dm, 100000. cm, 39370.07874...in, 1000000. mm (from here pressing [E] keeps alternating between the last 3).

See explanation above. A configured cycle in the units file takes precedence.

Quote:Entering 0.005_A and then repeatedly pressing [E] cycles between 0.005 A, 0.05 dA, 0.5 cA, 5. mA, 5000. µA, 5000000. nA, 5000000 nA, 5000 µA, 5 mA, 1/2 cA, 1/20 dA, 1/200 A, 1/2000 daA, 1/20000 hA, 1/200000 kA, 1/200000000 MA, 0.000000005 MA, 0.000005 kA, 0.00005 hA and 0.0005 daA. That's an awful lot of notations, and prefixes like centi, deci, deka and hecto are not that common with many (most?) units.

The problem is that there are very common cases, e.g. cm, whereas almost nobody uses the cs or the cA. Teaching that to a calculator is a bit complicated.

Quote:I'm not really sure what the best solution is for this, but maybe a toggle can be added to show only engineering prefixes?

The solution has to allow cm to work. It's an extremely common unit outside of the US.

Quote:When you have an expression on level 1 of the stack, pressing [E] also changes the rendering of expressions at deeper stack levels. I think I understand why it does that, but it's weird because if a non-expression is in level 1 you can't change the rendering of expressions on deeper levels.

It toggles between the four possible graphical rendering states (result and other levels). Every cycle toggles graphical rendering for the result level. Every second cycle toggles graphical rendering for the rest of the stack. That is intentional, e.g. to reduce the space used for fractions.

[c3d]

(05-28-2024 11:52 AM)mahi Wrote:  I discovered a bug with the solver. It doesn't work when certain constants are in the equation.

The solver with equation is still being actively worked on, and support is still very incomplete. This was mentioned in the release notes IIRC. Support for units is deficient, support for constants is not there, and more.

Quote:For example 'E=m*c²' returns error "bad guess" when solving E or m. When substituting constant c for π (pi) or e, it does work.

That's because c has a unit. It's the support for units in the solver that is the most deficient part at the moment (and the primary focus for the next release). That specific issue was #947.

Quote:Update: And another issue (maybe). Set 'E=m*c²' for the solver with [>Eq] soft key, then recall with the [Eq>] soft key. The equation changed to 'E-m*c²'. While mathematically correct, that's not the equation I saved. Or is this intentional?

Fixed as part of #944.

Quote:I had another weird issue but I cannot reproduce it. I had several equations on the stack containing constants and was playing with the solver. At one moment I noticed that equations deeper in the stack no longer showed the constant name but it was substituted with "Chem".

I suspect this is related to another issue where I was opening the units and constant files at the same time. See, the DM32/DM42 firmware lets you open only one file at a time, so processing equations that contains constants with units has to be careful about that (3 files involved).

[c3d]

DB48X pre-release v0.7.7 is out.

This release keeps marching towards full support for an equation library. The primary focus was support for units in equations.

New features

solver: Accept equations in solver menu
solver: Add shortcut to solve an equation from the library
solver: Display the current equation above the stack
solver: Solve expressions containing units
solver: Add units for solver variables when entering them
equations: Add option to list variables with units
programs: Enforce numerical values for solver / plotter
constants: Implement programmatic lookup
fonts: Add support for fixed-width digits
keyboard: Interpret ASN as AsNumber (convert to decimal)
complex: Allow insertion of angle while entering phasors
complex: Implement auto-complex promotion
graph: Render abs(X) with bars (e.g. |X|)
functions: Automatic simplification of expressions
Bug fixes

arithmetic: Avoid null-dereference in complex operations
help: Close help file if topic not found
solver: Do not store tag for tagged values
graph: Gracefully fallback if fraction integral part does not render
units: Avoid null-dereference if unit simplification fails
units: Count parentheses while parsing units
put: Fix null-dereference checking the index
fractions: Do not render two negative signs in graphical mode
Improvements

cycle: Update behaviour for several data types
menu: Replace abs with |z| in complex menu
ui: Micro-optimization to avoid reading object type twice
parser: Accelerate and improve object parsing
recorder: Add recorder entries for evaluation
build: Remove any leftover references to Intel decimal library
tests: Add ▶ entry in tests
tests: Increase default wait time to 1000ms
tests: do not error out if teval takes less than 100ms
equations: Rename PerfectGas equation to IdealGas
menus: Adjust size of menus to make descenders visible
solver: Replace SolverPrecision with SolverImprecision

[spiff72]

I just updated this morning and found what I think is a significant bug.

I can't enter a decimal value that's less than zero on the stack without using a leading 0 before the decimal point. I get a syntax error if I enter .375 ENTER , but 0.375 ENTER works.

[mahi]

I can confirm the leading zero issue reported by spiff72 (#965)

I think all of the issues I reported in this topic have been fixed apart from:

(05-29-2024 08:31 AM)c3d Wrote:  

(05-28-2024 11:52 AM)mahi Wrote:  For example 'E=m*c²' returns error "bad guess" when solving E or m. When substituting constant c for π (pi) or e, it does work.

That's because c has a unit. It's the support for units in the solver that is the most deficient part at the moment (and the primary focus for the next release). That specific issue was #947.

This issue is supposedly fixed in 0.7.7, but I still get a "bad guess" error (or nothing) when trying to solve the mass-energy relation.

'E=m*c²' [>Eq] [Solve]
2 [>m] (I also tried with 2_kg)
[E?] gives either nothing or "bad guess"