DB48X: HP48-like RPL implementation for DM42

[n1msr]

Christophe,

Thanks again for release 0.8.7. I was using the CATALOG to look for Attach and Detach added in the release and it led to this question on the behaviour of CATALOG. I understand that CATALOG is context sensitive, which makes sense if it bring functions that are likley to be of immediate use to objects on the stack, say. That's great :-)

This post refers to DB50X v0.8.7 on my DM32.

What I am unsure about is the cyclic nature of CATALOG. I have assumed that if I cycle through the CATALOG menus using the forward and back soft keys (F6 and SHIFT F6) I will be able to get to all functions or menus eventually and that it is a big loop. Is that right?

If I have nothing on the stack, I press f CAT (f = one press of blue function key on DM32) I get a set of 15 functions (F5 = %T) and the arrow keys of F6 and f F6. I can hit the F6 key (forward arrow) 42 times and am back at the first CATALOG menu (the one including %T on F5).

If I have a number (I type the number 3) and press forward ~44 times, I finish on a menu very similar to the first menu (with %T) but the F6 key has %Total, = and acosh. But there are no forward or back arrows on any of the soft menu keys. Is this intended?

In my several attempts to reproduce this "dead end" or "cul-de-sac" menu, the number of times I press forward arrow (F6) seems to vary. Another test it took 98 presses of the F6 key. Perhaps I have misundertood something? Anyone else seen this or maybe can explain?

Thank you again for the DB (Dave and Bill) project!

Mark.

[n1msr]

Christophe (and anyone who is using DB48X/50X),

Thanks again for release 0.8.7. I was using the CATALOG to look for Attach and Detach added in the release and it led to this question on the behaviour of CATALOG. I understand that CATALOG is context sensitive, which makes sense if it bring functions that are likley to be of immediate use to objects on the stack, say. That's great :-)

This post refers to DB50X v0.8.7 on my DM32.

What I am unsure about is the cyclic nature of CATALOG. I have assumed that if I cycle through the CATALOG menus using the forward and back soft keys (F6 and SHIFT F6) I will be able to get to all functions or menus eventually and that it is a big loop. Is that right?

If I have nothing on the stack, I press f CAT (f = one press of blue function key on DM32) I get a set of 15 functions (F5 = %T) and the arrow keys of F6 and f F6. I can hit the F6 key (forward arrow) 42 times and am back at the first CATALOG menu (the one including %T on F5).

If I have a number on the stack (the number 3 in 'D' mode) and press forward ~44 times, I finish on a menu very similar to the first menu (with %T) but the F6 key has %Total, = and acosh. But there are no forward or back arrows on any of the soft menu keys. Is this intended?

In my several attempts to reproduce this "dead end" or "cul-de-sac" menu, the number of times I press forward arrow (F6) seems to vary. In another test it took 98 presses of the F6 key. Perhaps I have misundertood something? Has anyone else seen this or maybe can explain?

So far, this behaviour has not occurred on the DB48X simulator v0.8.7 on Fedora (WSL). It has reliably cycled all the way through to the first CAT menu and starts again.

Thank you again for the DB (Dave and Bill) project!

Mark.

[c3d]

(12-03-2024 10:24 AM)n1msr Wrote:  Christophe,

Thanks again for release 0.8.7. I was using the CATALOG to look for Attach and Detach added in the release and it led to this question on the behaviour of CATALOG. I understand that CATALOG is context sensitive, which makes sense if it bring functions that are likley to be of immediate use to objects on the stack, say. That's great :-)

This post refers to DB50X v0.8.7 on my DM32.

What I am unsure about is the cyclic nature of CATALOG. I have assumed that if I cycle through the CATALOG menus using the forward and back soft keys (F6 and SHIFT F6) I will be able to get to all functions or menus eventually and that it is a big loop. Is that right?

Yes, although this is a very inefficient way to use the catalog.

The intent is that you start typing something, and then you cycle through what begins with or contains what you typed. So for example if you are looking for "background" functions, you type "BACK", and then you only have two pages worth of commands. If you type "AS" or "AX", there are only 18 commands, so it fits on the first page.

Quote:If I have nothing on the stack, I press f CAT (f = one press of blue function key on DM32) I get a set of 15 functions (F5 = %T) and the arrow keys of F6 and f F6. I can hit the F6 key (forward arrow) 42 times and am back at the first CATALOG menu (the one including %T on F5).

If I have a number (I type the number 3) and press forward ~44 times, I finish on a menu very similar to the first menu (with %T) but the F6 key has %Total, = and acosh. But there are no forward or back arrows on any of the soft menu keys. Is this intended?

No. Next time, can you please take a screenshot (holding Shift and DISP together, the snapshot is in the SCREENS directory)?

Quote:In my several attempts to reproduce this "dead end" or "cul-de-sac" menu, the number of times I press forward arrow (F6) seems to vary. Another test it took 98 presses of the F6 key. Perhaps I have misundertood something? Anyone else seen this or maybe can explain?

98 presses sounds closer to what you should get. My guess is that you pressed something on the command line that caused the catalog to shrink to the number of pages you observed.

Quote:Thank you again for the DB (Dave and Bill) project!

Mark.

[n1msr]

This is a very minor thing, but I am not sure how to configure the DB48X simulator for Fedora WSL to open with a certain size (I don't mind editing a source or .h file to get what I need, as opposed to a menu option in the application). When I run the simulator on my WSL the DB48X is very small so I always have to resize it.

I suspect that the thing I want is part of Qt, but I don't know where this is done.

Mark

[c3d]

(12-03-2024 11:40 AM)n1msr Wrote:  This is a very minor thing, but I am not sure how to configure the DB48X simulator for Fedora WSL to open with a certain size (I don't mind editing a source or .h file to get what I need, as opposed to a menu option in the application). When I run the simulator on my WSL the DB48X is very small so I always have to resize it.

I suspect that the thing I want is part of Qt, but I don't know where this is done.

Mark

Run the simulator with option "-s 2" (for a 2x scaling).

HiDPI detection is a bit hazardous on Linux.

[raprism]

(12-03-2024 11:40 AM)n1msr Wrote:  This is a very minor thing, but I am not sure how to configure the DB48X simulator for Fedora WSL to open with a certain size (I don't mind editing a source or .h file to get what I need, as opposed to a menu option in the application). When I run the simulator on my WSL the DB48X is very small so I always have to resize it.

I suspect that the thing I want is part of Qt, but I don't know where this is done.

Mark

You can either use the command option db48x -s 1.5 or set environment variable QT_SCALE_FACTOR=1.5 db48x.

[n1msr]

Thanks for your prompt reply on the display sizing. Nice n' easy :-)

Mark.

[Orome]

(12-03-2024 09:31 AM)c3d Wrote:  

(12-02-2024 09:49 PM)Orome Wrote:  Possibly a very dumb question but: If I have an RPL program in a file, how do I load it (without disturbing any other state)?

Use something like

Code:


"MYFILE.48S" RCL

Also deals with CSV, 48B (binary format), TXT and BMP extensions.

Where do I find RCL? I can enter it manually or brows the catalog, but is there a faster way?

[Orome]

I'd like my state backups from my macOS DB50X and my iOS DB50X to go to the same location (so that State saving and loading on both apps operates on the same location). Likewise I'd like for "SOME.FILE" RCL and VAL "SOME.FILE" STO to operate on the same location.

How do I point both apps to the same (e.g. cloud) folder to achieve this?

[c3d]

(12-03-2024 04:13 PM)Orome Wrote:  

(12-03-2024 09:31 AM)c3d Wrote:  Use something like

Code:


"MYFILE.48S" RCL

Also deals with CSV, 48B (binary format), TXT and BMP extensions.

Where do I find RCL? I can enter it manually or brows the catalog, but is there a faster way?

It's in the Memory menu (LShift VAR in the new layout, RShift STO in the old one).

[c3d]

(12-03-2024 04:26 PM)Orome Wrote:  I'd like my state backups from my macOS DB50X and my iOS DB50X to go to the same location (so that State saving and loading on both apps operates on the same location). Likewise I'd like for "SOME.FILE" RCL and VAL "SOME.FILE" STO to operate on the same location.

How do I point both apps to the same (e.g. cloud) folder to achieve this?

Normally, there should be a DB50X folder in iCloud. If you save there, it should be sync'd between macOS and iOS. At least, it seems to work for me, but it's sometimes a bit capricious (like everything iCloud).

[Orome]

(12-03-2024 05:22 PM)c3d Wrote:  

(12-03-2024 04:26 PM)Orome Wrote:  I'd like my state backups from my macOS DB50X and my iOS DB50X to go to the same location (so that State saving and loading on both apps operates on the same location). Likewise I'd like for "SOME.FILE" RCL and VAL "SOME.FILE" STO to operate on the same location.

How do I point both apps to the same (e.g. cloud) folder to achieve this?

Normally, there should be a DB50X folder in iCloud. If you save there, it should be sync'd between macOS and iOS. At least, it seems to work for me, but it's sometimes a bit capricious (like everything iCloud).

Yeah I've got that and it works, but is there a way to make it the default location for both:

• "SOME.FILE" RCL and VAL "SOME.FILE" STO, and
• SETUP > (3) State >
  

[Orome]

(12-03-2024 05:56 PM)Orome Wrote:  

(12-03-2024 05:22 PM)c3d Wrote:  Normally, there should be a DB50X folder in iCloud. If you save there, it should be sync'd between macOS and iOS. At least, it seems to work for me, but it's sometimes a bit capricious (like everything iCloud).

Yeah I've got that and it works, but is there a way to make it the default location for both:

1. "SOME.FILE" RCL and VAL "SOME.FILE" STO, and
2. SETUP > (3) State >
   

For A it seems that there's no way for those commands to operate on anything other than the local data directory, so to exchange between macOS and iOS some moving or copying would be needed.

For B, as near as I can tell:

1. on macOS, I can just load and save (including SAVE) state directly to iCloud (or anywhere really); but
2. on iOS, it is not possible to load ("Operation not permitted") from iCloud (access to iCloud is apparently forbidden)
   

so on iOS it would be necessary to copy or between iCloud and the local state directory.

Is that right, or am I missing something?

[c3d]

Pre-release v0.8.8 is available for testing.

The focus of this release is power usage reduction while on battery, to try to get closer to the original DM42 firmware. This goes through a severe reduction of animations while on battery, caching of object rendering on the stack, and using hardware-assisted DMCP routines to transfer data to the display.

The custom menu in this release has entries to store statistics about battery levels in a file called BAT.CSV on the disk. I would appreciate if various users who regularly use the machine on battery could record the battery level on a regular basis, so that we can build some reasonable evaluation of battery usage.

[n1msr]

This post is only by way of discussion. Not complaining, but just interested :-)

In experimenting with RPL programs written for the HP-50g, I came across what looks like a difference between the DB48X and HP-50g. I have looked through some of the documentation for both calculators but haven't found an explicit description to explain the difference.

This has come about partly because not all HP-50g functions have been implemented on the DB48X yet - in this case the Real to Integer (R->I), which was used by several entries in the 2011 HHC programming contest.

It becomes important when the Comb[inations] function is used, because:

On the DB48X, it seems that the two parameters, n & r (for nCr) have to be Real Integers (type 28 objects). The result is a Real Integer.

The HP-50g doesn't seem to care. You can use Real Integers (Type 28), Real Numbers (Type 0) or mix them. If either input is a Real Number, the result will be a Real Number. If both inputs are Real Integers, the result is a Real Integer.

Until R->I is implemented I was going to resort to using only Real Numbers is these programs, except that Comb[inations] won't use Real Numbers. I could of course do the nCr calculation using factorial (x!), where nCr = n! / (r! * (n-r)!). The DB48X factorial function will take both Real Integers and Real Numbers :-)

I did wonder if there is a setting I could make in the DB48X calculator to change the way the functions behave, i.e. accept Real Numbers as well as, or instead of Real Integers?

[n1msr]

This post is only by way of discussion. Not complaining, but just interested :-)

In experimenting with RPL programs written for the HP-50g, I came across what looks like a difference between the DB48X and HP-50g. I have looked through some of the documentation for both calculators but haven't found an explicit description to explain the difference.

This has come about partly because not all HP-50g functions have been implemented on the DB48X yet - in this case the Real to Integer (R->I), which was used by several entries in the 2011 HHC programming contest.

It becomes important when the Comb[inations] function is used, because:

On the DB48X, it seems that the two parameters, n & r (for nCr) have to be Real Integers (type 28 objects). The result is a Real Integer.

The HP-50g doesn't seem to care. You can use Real Integers (Type 28), Real Numbers (Type 0) or mix them. If either input is a Real Number, the result will be a Real Number. If both inputs are Real Integers, the result is a Real Integer.

Until R->I is implemented on the DB48X, I was going to resort to using only Real Numbers is these programs, except that Comb[inations] won't use Real Numbers. I could of course do the nCr calculation using factorial (x!), where nCr = n! / (r! * (n-r)!). The DB48X factorial function will take both Real Integers and Real Numbers :-)

I did wonder if there is a setting I could make in the DB48X calculator to change the way the functions behave, i.e. accept Real Numbers as well as, or instead of Real Integers?

[battlecoder]

(Yesterday 05:07 PM)n1msr Wrote:  I did wonder if there is a setting I could make in the DB48X calculator to change the way the functions behave, i.e. accept Real Numbers as well as, or instead of Real Integers?

This is an interesting problem. I've not used the DB48X much (yet! waiting for a DM42n and overlay to arrive) but it could be implemented like some programming languages do; If a function expects a parameter of type T, but a parameter of type P is supplied, it would check if there's an straightforward conversion from P->T, and apply it automatically to the input.

[c3d]

(12-03-2024 07:13 PM)Orome Wrote:  

(12-03-2024 05:56 PM)Orome Wrote:  Yeah I've got that and it works, but is there a way to make it the default location for both:

1. "SOME.FILE" RCL and VAL "SOME.FILE" STO, and
2. SETUP > (3) State >
   

For A it seems that there's no way for those commands to operate on anything other than the local data directory, so to exchange between macOS and iOS some moving or copying would be needed.

For B, as near as I can tell:

1. on macOS, I can just load and save (including SAVE) state directly to iCloud (or anywhere really); but
2. on iOS, it is not possible to load ("Operation not permitted") from iCloud (access to iCloud is apparently forbidden)
   

so on iOS it would be necessary to copy or between iCloud and the local state directory.

Is that right, or am I missing something?

There is currently no way to change the default location for saving / restoring, mostly because the DM42/DM32 have very small disks with only one possible location. On iOS, the recent places can serve as a quick way to get to some other location.

Unfortunately, iOS has two very specific notions that do not play well with traditional filesystem semantics: application sandboxing and iCloud. Application sandboxing restricts the files that your application can touch. iCloud means some documents show up in the filesystem but are not actually there, they are proxies for something that needs to be downloaded before being used.

The semantics for these features are complicated. Most developers hide behind a higher-level layer, like "documents", that manage this somewhat transparently. Even so, this entire subsystem has been bogus since it was introduced (from memory circa 10.7) to replace the old "save / save as" (now instead of "save as", you have "duplicate"). For example, for many major releases, opening two documents in Preview or any application using the new semantics, and then saving one of them with the name of the other would lock up the application. In short, the system is difficult enough to master that even Apple developers took several major iterations of OSX to get it half right.

Now, don't get me wrong, the system is also very powerful, with support for multiple version, transparent synchronization of documents across machines, and so on. So it goes way beyond the traditional Unix or MS-DOS filesystem.

But for an application like DB50x on iOS, which only needs to save and load files by name, this makes things complicated enough that, at least for the moment, it mysteriously fails in ways that I have yet to understand.

Among the problems that I am aware of:

1) I have not found a way to use the same directory across variants of the application. This is probably only a concern to me, but iOS treats DB48x and DB50x as two entirely distinct applications, even if they share the same file types. According to the documentation, one application should be able to read the documents from the other, but so far, it does not work.

2) The data directories sometimes disappear until you reboot your device. This notably happens when you upgrade (or, in my case, when I install a new version, but not every time).

3) iCloud directories created by one version of the application may become inaccessible by the next version of the same application (this is the "operation not permitted" you saw). What is really weird about this one is that if I start an iPhone simulator from scratch and connect it to my iCloud account, then I can access the directory, but not if I reuse a simulator where the previous version had been installed.

So in short, at the moment, iCloud support is very theoretical. When it works, it works well and you can sync your state files across multiple devices (even an iPhone and iPad in my case), but it sometimes goes boom for reasons that I don't understand yet. Sometimes, just restarting the iPhone fixes the problem, but it seems absolutely insane that you would have to do that.

I'm doing something wrong in the code, but I don't know what yet.

[Thomas Klemm]

(Yesterday 05:05 PM)n1msr Wrote:  It becomes important when the Comb[inations] function is used (…)

I just cobbled together this program for the HP-15C to calculate:

\(
\binom{n}{k} = \frac{n!}{k!(n-k)!}
\)

Code:

   001 {    44  0 } STO 0
   002 {    42  0 } f x!
   003 {       34 } X<=>Y
   004 {    42  0 } f x!
   005 {    43 36 } g LSTx
   006 { 45 30  0 } RCL - 0
   007 {    42  0 } f x!
   008 {       10 } /
   009 {       34 } X<=>Y
   010 {       10 } /

Example

5 ENTER 3
R/S

10.0000

Nothing to see here. That's what we expected.
But it also allows us to calculate values of \(\binom{0.5}{k}\) for consecutive \(k\).

Examples

0.5 ENTER 0
R/S

1.0000

0.5 ENTER 1
R/S

0.5000

0.5 ENTER 2
R/S

-0.1250

0.5 ENTER 3
R/S

0.0625

0.5 ENTER 4
R/S

-0.039062500

0.5 ENTER 5
R/S

0.027343750

0.5 ENTER 6
R/S

-0.020507813

Compare this to the Taylor series of:

\(
\begin{align}
\sqrt{1+x}
&= (1+x)^{\frac{1}{2}} \\
&= 1+\frac{x}{2}-\frac{x^2}{8}+\frac{x^3}{16}-\frac{5x^4}{128}+\frac{7x^5}{256}-\frac{21x^6}{1024}+\cdots
\end{align}
\)

As we can see in this example, there are good reasons to allow non-integer values in binomial coefficients.

---

Hint: Don't try this with an HP 20b.

[c3d]

(Yesterday 05:05 PM)n1msr Wrote:  This post is only by way of discussion. Not complaining, but just interested :-)

In experimenting with RPL programs written for the HP-50g, I came across what looks like a difference between the DB48X and HP-50g. I have looked through some of the documentation for both calculators but haven't found an explicit description to explain the difference.

This has come about partly because not all HP-50g functions have been implemented on the DB48X yet - in this case the Real to Integer (R->I), which was used by several entries in the 2011 HHC programming contest.

Good point. I never implemented that, it's easy enough to do (the internal functions all exist).

Quote:It becomes important when the Comb[inations] function is used, because:

On the DB48X, it seems that the two parameters, n & r (for nCr) have to be Real Integers (type 28 objects). The result is a Real Integer.

The HP-50g doesn't seem to care. You can use Real Integers (Type 28), Real Numbers (Type 0) or mix them. If either input is a Real Number, the result will be a Real Number. If both inputs are Real Integers, the result is a Real Integer.

For clarity, and since we are in a discussion, the type names you used above are those documented in the HP50G advanced user reference manual, and I dislike them with a passion. "Real integer" is a mathematical nonsense, and "Real number" is inaccurate because of the limited precision of the calculator. In any case, these are HP50G data types.

DB48x has a different terminology, which I believe is more precise, which corresponds to entirely different underlying data types.

- "integer" denotes integer values. They can have arbitrary precision, being encoded using LEB128 (7 bits of data per byte), but the calculator typically only uses that format for values that fit on 64-bit.

- Above that point, there is a crossover with "bignum", which is also arbitrary precision, but with an LEB128-encoded length and 8 bits of data per byte. You can check that 63 bits is 9x7bits plus a 1-byte type, so the largest optimal "integer" value is 9+1=10 bytes. 64 bits is 8x8bits + 1-byte length (coding the number of bytes, 8, in LEB128, + 1-byte type, which is also 10 bytes. Above 64-bit, the bignum format becomes more efficient, so that is what is being used.

- All these only hold unsigned values, so there are neg_ variants for negative values.

- The types can also be used for based numbers, so that are also based_ variants, e.g. based_integer and based_bignum.

- Decimal values are stored in the variable-precision "decimal" type (not "real" precisely because it belongs to the mathematical D set and not R).

- IEEE754 hardware-accelerated 32-bit and 64-bit floating-point values are called hwfloat and hwdouble, carrying the ridiculously inconsistent names of the underlying C++ types ("float" being an implementation detail, the format, "double" being another implementation detail, the precision).

That being said, you are entirely correct that:

a) COMB and PERM do not accept decimal or hwfloat input, which is a bug.

b) R->I is not implemented, which is a glaring missing feature, that I will cowardly blame, to the fullest extent permissible by law, on this universe only featuring 24 hours per day.

c) There is currently no correct way to convert a decimal to an integer. There is, however, an incorrect way, with the ->Frac or CYCLE functions, which, when given a non-fractional decimal input, happens to produce an integer. Problem is that they accept a fractional value and produce a fraction, but maybe that's what you want because then COMB or PERM will fail.

Quote:Until R->I is implemented I was going to resort to using only Real Numbers is these programs, except that Comb[inations] won't use Real Numbers. I could of course do the nCr calculation using factorial (x!), where nCr = n! / (r! * (n-r)!). The DB48X factorial function will take both Real Integers and Real Numbers :-)

Yes, but that raises an interesting question. If you compute COMB with 2.3 and 4.5 as input, the HP50G raises a Bad Argument Value error. By contrast, every HP calculator since at least the HP15C interprets x! as being derived from the Gamma function for fractional values. This means that the formula for nCr works just fine with fractional values.

So the question is: should a version of COMB that accept decimal input also accept fractional input and use the Gamma function to compute the result? I vote in favor of that personally, unless someone can prove that this would instantly destroy a non-negligible fraction of the known universe.

Quote:I did wonder if there is a setting I could make in the DB48X calculator to change the way the functions behave, i.e. accept Real Numbers as well as, or instead of Real Integers?

There is no setting to workaround that specific bug, because it's a bug. Internally, the bug is as follows: functions that take an integer input but should accept a decimal and truncate it to an integer (e.g. FIX) use an internal routine designed for that very purpose, that does all the type analysis and truncation correctly. For some reason, the idiot who wrote the code for COMB and PERM decided to explicitly test if the value was an "integer" type.

I'm allowed to write "idiot" because I personally know that idiot very well. And I can tell from reading the code that the intent was to mimic the HP50G behaviour and give a Bad Argument Value for fractional input, as shown by this code:

Code:


    if (n->is_real() && m->is_real())
        rt.value_error();
    else
        rt.type_error();

This is fixed on dev now, meaning that it will be fixed in 0.8.9.