I clarified in a recently updated version of the text, and I refer the readers to this discussion. https://github.com/c3d/db48x/blob/dev/LEGAL-NOTICE.md

https://github.com/c3d/db48x/blob/dev/LEGAL-NOTICE.md

Some of these include contributions from third parties.

The problem is that the law is written without a precise enough wording that would ensure that there is no risk whatsoever for me. And the penalty is stiff, something like $7500 per child using the software.

As for mandating age verification, it's unclear to me how you think that it's possible to deliver an API giving age bracket info (in the case of DB48x, the idiomatic way would be an RPL command that returns that info) without having a facility to enter age or date of birth or something like that. So yes, everyone who reads the text interprets it as mandating age verification.

1. Not take any risk 2. Take a stand

The point is more to draw attention

I do not believe there is any possible infringement on a clearly new design, even if that design is intentionally reminiscent of the HP logo.

- A variable-precision decimal floating point that uses base-1000 internally with 10 bits for 1000 values instead of 1024, so reduced memory waste, and LEB128 for size and exponent encoding. So 1.23 is 5 bytes, and each decimal value has its own precision. The precision only affects computations, not stored objects, so you can adjust the precision for each step of a computation.

- IEEE754 hardware accelerated 32-bit and 64-bit binary floating point.

In line with RPL, there are many other object types, including arbitrary-precision integers (123 is 2 bytes, 100! is 68 bytes), symbolic expressions, programs, lists, and so on.

Also, were you aware of this tutorial: https://www.youtube.com/watch?v=rVWy4N0lBOI&list=PLz1qkflzAB...

1. What happens if I rotate binary pattern 1001 right by 3 positions on a 18-bit PDP-9?

  RPL code: 18 STWS 2#1001 3 RRC

  Result: #8001 in base 16, #1000 0000 0000 0001 in base 2.

  RPL code: 6 36 * STWS 2#1001 3 RRC

  Result: #20 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001

  Program: [[1 y]['2+x' b]] DET

  Answer: 'b-(x+2)·y' (shows graphically on calculator screen)

  Program: R1=4_kΩ R2=10_Ω V=100_V 'ROOT(ⒺVolt Divider;[V1];[1_V])' EVAL

  Result: [ V1=99.75 V ]

  Note that ⒺVolt Divider is a built-in equation, but you can of course put your own.

  Program: « 'exp(√ 163·Ⓒπ)'60 PRECISION →Num FractionalPart »
  Result: -7.50E⁻¹³, so no, not an integer, but really close

  Program: '(√(Ⓒε0·Ⓒμ0))⁻¹'  →Num 
  Result: 299 792 458.00 m/(F↑(¹/₂)·H↑(¹/₂))
  Convert to SI units: UBASE
  Result: 299 792 458. m/s
  Convert to feet per second: ³⁷⁴ ⁷⁴⁰ ⁵⁷² ⁵⁰⁰/₃₈₁ ft/s or 983 571 056.43 ft/s.

  (if you subtract the Ⓒc constant, you get -0.00031 11057 21 m/s)

  Program: « if dup 1 ≠ then if dup 2 mod then 3 × 1 + else 2 ÷ end Collatz end » 'Collatz' STO 989345275647 Collatz

  Result: 1 (conjecture is verified)

  Program: 20241107.000751_date 20241101.231527_date - 1_h convert UVAL →HMS
  Result: 120:52:24

Keystroke count and progressive computations.

Let me illustrate using an example from a YouTube video called "The hardest Exam Question : Only 6% of students solved it correctly" (https://www.youtube.com/watch?v=NfgEPsm9Jzw), which is about a simplified formulation for (sqrt(2)-1)^10.

The first remark is that a CAS-capable calculator like DB48x can help with the symbolic part of the computation shown in the video. However, to be fair, DB48x still lacks some of the relevant HP48 interactive equation manipulation features to be able to demonstrate that. So let's focus for now on the numerical part.

The author shows that (sqrt(2)-1)^10 is the same as 3363-2378*sqrt(2). Let's evaluate that using bc.

Attempt 1: bc, then (sqrt(2)-1)^10-(3363-2378*sqrt(2))

Result: -985. Er... What?

OK. What is the option for precision again? man bc. Search for precision. Mentions the @ operator. Does not seem to do it. 5 minutes of search later, find that precision is called scale, that I need the -S option. I could also presumably use the -l option, which experimentally seems to set the scale to 20. Starting to remember why I am not a big fan of bc ;-)

Trying again. bc -l

(sqrt(2)-1)^10-(3363-2378*sqrt(2)) now gives me:

-.00000000000000000402.

Counting "bc -l" and ENTER keys, that's I believe 42 keystrokes.

Trying again with db48x: I need 23 keys using the most naive RPN data entry. The result is -1.57861 99E⁻²⁰ with the default 24-digit precision.

I can also enter the same algebraic expression as in bc directly in the simulator using copy-paste. I get a nice graphical rendering of the expression, which I can check, and then just one key (EVAL/=) to get the numerical value.

As another example, let's try to check if the Ramanujan constant in an integer:

bc -l

e(sqrt(163)*pi(20))

262537412640768743.98947654935272888605

That does not look like an integer to me. And it's way more than the 20 digits I would expect from scale. What is weird is that it gives me a false sense of accuracy, all the digits after "43.9" are bogus, as shown by switching the scaling to 100:

bc -l -S100

e(sqrt(163)*pi(100))

262537412640768743.9999999999992500725971981856888793538563373369908\ 627075374103782106479101186073126534265238592035363

21 keystrokes, and a result that is a bit hard to interpret with the default precision (scaling). In other words, it's pretty easy to get bogus numerical results and not know it.

With DB48x, after selecting a precision of 100, 11 keystrokes including menu selection to get the pi constant, and I get: 262 537 412 640 768 743.99999 99999 99250 07259 71981 85688 87935 38563 37336 99086 27075 37410 37821 06479 10118 60730 76

> At least I can easily copy the results and the code to a document which avoids transcription errors.

This is also true with the DB48x simulator, which supports copy and paste both ways. This is how I copied the values above, or entered the exact same algebraic expression as in bc into the simulator.

Emulators are stuck in the past, since they need to rely on the HP ROMs. So all the nice new features in DB48x, like variable-precision decimal arithmetic, support for higher-resolution graphics and colour, tail-recursion optimization, object size optimizations, polar and rectangular complex numbers or vectors, or the extensive Markdown-based builtin help would all be impossible to implement.

> I wish there was a good HP50G emulator for iOS — there used to be one, but it was abandoned (contact me if you want to develop it and would like to get the source code, it was under the GPL and I got it from the author).

I have two pretty good emulators on my iPhone, one is iHP48, the other is i48. Both can emulate the HP50G if you load the correct ROM, IIRC.

That being said, I second the idea that if you got the source in GPL form, you should publish them on GitHub. Or share with me and I will do it, possibly restore it (I have vague plans to restore Emu71 as well, when I'm done with DB48x).