DB48X: HP48-like RPL implementation for DM42

[rprosperi]

(10-30-2024 12:55 PM)floppy Wrote:  Exact. For me,
- the DMx path is way too expensive
- the other direction (most impressive for me this year) is the RPN83 way: with very very cheap HP83 or HP84 hardware, you can have an RPN calculator.
So, please, we need now the calculator for the poor, and not only calculators for the rich.

I assume you mean TI83 and TI84 ??

[LinusSch]

(10-30-2024 12:55 PM)floppy Wrote:  So, please, we need now the calculator for the poor, and not only calculators for the rich.

Noted and seconded.

I have a spare 50g so that makes sense to me, but those are getting harder and harder to come by. I could get my hands on some cheap TI hardware and theoretically I could have a go at making it work. But there are many things I want to spend my time on and few things I actually end up spending time on. No promises.

[Gjermund Skailand]

Hi
I am running DB50X v. 0.8.3 on DM42N
I just started playing with this wonderful software, and may have done a lot of strange things.
There seems to be something wrong with matrix Random and HwFP Prec 7. Can someone confirm if they also get hard fault crash with the following setting?
shift MODES HwFP
shift DISP 7 Prec
{ 3 3 } shift shift MATRIX Random

The battery is running low, but the same happens on USB power.
best regards
Gjermund

[Gjermund Skailand]

Hi
there is also something else strange happening on DM42N when calculating directly from commandline using CATALOG menus
e.g
6 ENTER SHIFT CATALOG !
is ok

whereas
6 SHIFT CATALOG !
result in rubbish or it hangs
Maybe due some pointer error?
PS it does not happen in the browser.
best regards
Gjermund

[LinusSch]

(10-30-2024 10:01 PM)LinusSch Wrote:  

(10-30-2024 12:55 PM)floppy Wrote:  So, please, we need now the calculator for the poor, and not only calculators for the rich.

Noted and seconded.

I have a spare 50g so that makes sense to me, but those are getting harder and harder to come by. I could get my hands on some cheap TI hardware and theoretically I could have a go at making it work. But there are many things I want to spend my time on and few things I actually end up spending time on. No promises.

I looked around a bit and I found the following thoughts:

• TI 83 plus and 84 plus can work
  • but 512 kiB flash in the 83 plus may be limiting
  • Silver edition hardware has enough flash to maybe put db48x in there as a program
  • the display resolution of 96x64 may be tough challenge
  • the good ones are more expensive than I had guessed, on my used market
    
• TI 89 seems better
  • a display resolution of 160x100 is a definitive step up
    
• agarza's PX41CX has too limited flash
  • finding a 28-pin microcontroller with at least 1 MiB of flash may or may not be possible, at least it is not easy
  • the 250x122 pixel display is a welcome step up from TI hardware
  • this isn't really cheap
    
• Raspberry Pi Pico and Pico 2 may be a good way to get a good chip
  • 2 MiB flash on the original, 4 MiB flash on the Pico 2, compute power overkill but I like overkill
  • these are really cheap for what we get
  • displays are the challenge:
    • Adafruit sells a module with the 2.7" 400x240 Sharp Memory LCD that is pretty much perfect for calculators, yes, but it is... not exactly cheap (and requires soldering I think) https://www.adafruit.com/product/4694
    • Pimoroni had a 2.8" 320x240 IPS display at a better price, still a good chunk of the entire build cost, can be plugged in without soldering if your Pico has headers, eats more power and it is currently out of stock https://shop.pimoroni.com/products/pico-...y-pack-2-8
      
  • well there we go, everything except keyboard and case, 2.4" is a slight step down in size, eats power but not wallets https://shop.pimoroni.com/products/tufty-2040
    

The prices I found were

• 800 SEK for a good used TI
• 50 SEK for a Pico or 80 SEK for a Pico 2 so those are cheap as chips
• 700 SEK (but only $45) for the Adafruit display module
• €19 for the Pimoroni 2.8" display
• €24 for the Pimoroni Tufty 2040 that really seems tempting
  

That's more than enough calculator musings for my Saturday, I need to get my misbehaving computers in order.

[jibanes]

Another approach would be a hp48 (there are thousands on ebay, many under $100); gutted out with its internals replaced with a swissmicros-compatible (or like) internals (including LCD); basically you'd be buying the hp48 (or really hp50) just for the keyboard and shell. The PCB would be powered using the AAA batteries.

But then again, if db48x/newrpl comes to the hp50, then there's no need for the surgery. I just dislike keyboard overlays and stickers.

Meanwhile I use db50x on my dm42n daily.

[spiff72]

(11-02-2024 05:20 PM)jibanes Wrote:  Another approach would be a hp48 (there are thousands on ebay, many under $100); gutted out with its internals replaced with a swissmicros-compatible (or like) internals (including LCD); basically you'd be buying the hp48 (or really hp50) just for the keyboard and shell. The PCB would be powered using the AAA batteries.

But then again, if db48x/newrpl comes to the hp50, then there's no need for the surgery. I just dislike keyboard overlays and stickers.

Meanwhile I use db50x on my dm42n daily.

NewRPL is already available for the 50g - am I missing something in this discussion?

[nickapos]

(11-02-2024 06:46 PM)spiff72 Wrote:  

(11-02-2024 05:20 PM)jibanes Wrote:  Another approach would be a hp48 (there are thousands on ebay, many under $100); gutted out with its internals replaced with a swissmicros-compatible (or like) internals (including LCD); basically you'd be buying the hp48 (or really hp50) just for the keyboard and shell. The PCB would be powered using the AAA batteries.

But then again, if db48x/newrpl comes to the hp50, then there's no need for the surgery. I just dislike keyboard overlays and stickers.

Meanwhile I use db50x on my dm42n daily.

NewRPL is already available for the 50g - am I missing something in this discussion?

Newrpl is not as feature rich as DB48X. Also is is not under active development any more.

[jibanes]

> Newrpl is not as feature rich as DB48X. Also is is not under active development any more.

Oh thanks, I didn't know newrpl was stable. I will definitely give it a shot.

[n3mmr]

(11-03-2024 02:56 AM)jibanes Wrote:  > Newrpl is not as feature rich as DB48X. Also is is not under active development any more.

Oh thanks, I didn't know newrpl was stable. I will definitely give it a shot.

It isn't really stable, the author just stopped working on it.

And the db50x is potentially a really complete implementation, if Mr de Dinechin can find the time to take the project all the way.

[LinusSch]

I keep forgetting that I actually need to learn building Android apps. Which creates an obvious answer to what zero-budget db48x project I should actually attempt. Both the process and the result would be of most use to me personally if I did that.

So why... maybe I just want to look at hardware options for hours, without looking in my drawer of old phones for some reason.

Physical keyboard, you say? Most Androids happily accepts standard USB keyboards and I think that can be made use of to have the app double as a true desktop calculator. Phone screen can then be only screen, no keys... not the best aspect ratio, but with single line soft menus and landscape orientation I think three levels of the stack could be shown in a reasonably large font. Not high priority, not at all, but this possibility makes me at least a little excited - so that maybe I'll eventually get to work.

[raprism]

(07-11-2023 10:16 AM)c3d Wrote:  

(07-10-2023 09:46 PM)Helix Wrote:  I would be curious to know the result for this benchmark too.

I used the following program:

Code:


« Ticks 0 1 10000
for i
    i atan sin exp cbrt +
next Ticks Rot - »

The result for 10'000 loops is
- USB: 12.5s (stock DM42 is 26s)
- Battery: 36.4s (stock DM42 is 65.73s)
[/code]

Because of the current release doc in dev branch ("0.8.4") I researched to find the code of this benchmark "floating point sum" test. With 0.8.4 self-compiled from dev branch, and the released 0.8.3 I used this code:

Code:


« Ticks 0 1 1000
for i
    i atan sin exp cbrt +
next Ticks Rot - 1000 ÷ » 'T1K' STO

Note that T1K uses 1000 instead of 10000 loops, because timings were far slower as expected - although I can confirm the speed-up from 0.8.3 to 0.84. Results for DM42 USB-powered are:

• 0.8.3 ~18.3 s
• 0.8.4 ~16.2 s
  

What might be the reason that some early db48x version was much faster when running this test?

[Dashier]

There's a Facebook thread regarding a test of calculator accuracy based on an exam question that results in:

Code:

 (SQRT(2)-1)^10 = 3363-2378*SQRT(2)

There are a number of comments regarding the accuracy of various calculators.

I elected to set the DB50X to 2000 digits precision and test it. The difference between the LHS and RHS was 2.15651x10^-1997

Nice job Christophe!

Post script: doing the LHS as a series of multiplications gives virtually the same results. Setting the precision to 6400 digits, yields of a difference of: 9.59198x10^-6397

[LinusSch]

(11-04-2024 08:37 PM)raprism Wrote:  What might be the reason that some early db48x version was much faster when running this test?

Early versions used the Intel decimal floating point library, current versions use a custom floating point library that saves a lot of code space as compared to the Intel one and provides arbitrary precision. If you set your precision low enough the current versions should be able to go faster than the early versions, but I do not know how low you'd need to set it for which cases.

[raprism]

(11-05-2024 01:05 AM)LinusSch Wrote:  

(11-04-2024 08:37 PM)raprism Wrote:  What might be the reason that some early db48x version was much faster when running this test?

Early versions used the Intel decimal floating point library, current versions use a custom floating point library that saves a lot of code space as compared to the Intel one and provides arbitrary precision. If you set your precision low enough the current versions should be able to go faster than the early versions, but I do not know how low you'd need to set it for which cases.

Good hint. I remember that this was changed to get the envisaged functionality implemented on DM42.

To reduce the processing time to bit less than 1/2 minute for 10k loops, I have to set the precision to the minimum value of 3 (standard is 24). Any other means (without code optimizations) to increase the speed?

[grbrum]

Hello Christophe, I love the implementation of CST. Thank you very much for that.
I also love that you made it possible for different CST within each directory like the HP48.

I don't have a HP48 on me while I am traveling for work, but if I remember right, I could store the CST menu anywhere (directory), and if there was no CST variable in current directory, it would use the CST menu of the parent directory. I may be wrong. I tried this on the DB48 and it only sees the CST in current directory (this may be accurate to the HP48 behavior though).

I would like to please request the following enhancements:

- Would it be possible to have a "blank" command to put in the CST variable? basically to have an empty field in the CST menu?
{ Name Value "Blank"}
I am playing with the functionality of having shifted option for CST menu, and I think it is just easy to have the relevant menu items on top of each other (ie A, A> and >A) in CST menu.

- Would it be possible to implement this from HP48 manual page 30-3? "Also, instead of storing the list of objects itself in CST', you can optionally store the name of another variable that contains the list."

Finally, doing tests with MENU and TMENU I noticed that now I have a 1 in a box in top left corner, I could not find documentation about this, is this a flag that I accidentally set?
thank you.

[c3d]

(10-31-2024 10:12 PM)Gjermund Skailand Wrote:  Hi
I am running DB50X v. 0.8.3 on DM42N
I just started playing with this wonderful software, and may have done a lot of strange things.
There seems to be something wrong with matrix Random and HwFP Prec 7. Can someone confirm if they also get hard fault crash with the following setting?
shift MODES HwFP
shift DISP 7 Prec
{ 3 3 } shift shift MATRIX Random

The battery is running low, but the same happens on USB power.
best regards
Gjermund

Thanks a lot for the very detailed report. Such details make it very easy to reproduce and fix. I filed issue 1309. It will be fixed in the official 0.8.4.

[c3d]

(11-01-2024 09:36 AM)Gjermund Skailand Wrote:  Hi
there is also something else strange happening on DM42N when calculating directly from commandline using CATALOG menus
e.g
6 ENTER SHIFT CATALOG !
is ok

whereas
6 SHIFT CATALOG !
result in rubbish or it hangs
Maybe due some pointer error?
PS it does not happen in the browser.
best regards
Gjermund

I cannot reproduce that particular problem, but given your explanations, I suspect it is is a duplicate of issue 1296. There were several issues with insertion in general and catalog command insertion in particular that have been fixed recently. Issue 1296 is the latest one, which is not yet fixed.

[c3d]

(11-04-2024 08:37 PM)raprism Wrote:  

(07-11-2023 10:16 AM)c3d Wrote:  I used the following program:

Code:


« Ticks 0 1 10000
for i
    i atan sin exp cbrt +
next Ticks Rot - »

The result for 10'000 loops is
- USB: 12.5s (stock DM42 is 26s)
- Battery: 36.4s (stock DM42 is 65.73s)
[/code]

Because of the current release doc in dev branch ("0.8.4") I researched to find the code of this benchmark "floating point sum" test. With 0.8.4 self-compiled from dev branch, and the released 0.8.3 I used this code:

Code:


« Ticks 0 1 1000
for i
    i atan sin exp cbrt +
next Ticks Rot - 1000 ÷ » 'T1K' STO

Note that T1K uses 1000 instead of 10000 loops, because timings were far slower as expected - although I can confirm the speed-up from 0.8.3 to 0.84. Results for DM42 USB-powered are:

• 0.8.3 ~18.3 s
• 0.8.4 ~16.2 s
  

What might be the reason that some early db48x version was much faster when running this test?

As was correctly pointed out, the variable-precision implementation is roughly 10 times slower than the Intel decimal library.

This is not easily fixable, because having fixed-size allows you to pre-compute values, or select algorithms that converge faster but cannot be generalized to arbitrary precision, e.g. precisely optimized polynomial approximations where the coefficients and order of the polynomials have to be pre-computed.

Also, while the variable-precision implementation at 24 digits is slower than the original Intel Decimal library at 34 digits (15164ms vs 1434ms on DM42), the 32-bit and 64-bit hardware floating-point implementations are faster (388 and 879ms). So you get to choose.

[c3d]

(11-04-2024 09:36 PM)Dashier Wrote:  There's a Facebook thread regarding a test of calculator accuracy based on an exam question that results in:

Code:

 (SQRT(2)-1)^10 = 3363-2378*SQRT(2)

Can you share the link to the Facebook thread? I could not find it with a quick search. Thanks.

Quote:There are a number of comments regarding the accuracy of various calculators.

I elected to set the DB50X to 2000 digits precision and test it. The difference between the LHS and RHS was 2.15651x10^-1997

Nice job Christophe!

Post script: doing the LHS as a series of multiplications gives virtually the same results. Setting the precision to 6400 digits, yields of a difference of: 9.59198x10^-6397