DB48X: HP48-like RPL implementation for DM42

[nickapos]

(11-17-2023 10:51 AM)n3mmr Wrote:  I looked into the git repo and the various .md files there.
I noticed a line or two mentioning the HP Prime G1 as one of the target HW devices.
Is that really true for DB48X?
That would be really nice, given I have a useless G1 in my desk which is in dire need of a new raison d'etre.

If G1 is supported I am also interested.

[c3d]

(11-17-2023 10:51 AM)n3mmr Wrote:  I looked into the git repo and the various .md files there.
I noticed a line or two mentioning the HP Prime G1 as one of the target HW devices.
Is that really true for DB48X?
That would be really nice, given I have a useless G1 in my desk which is in dire need of a new raison d'etre.

I don't have a G1 available at the moment, only a G2. I recently acquired an HP50G, which may allow me to do a port there at some later time.

In any case, I will finish the DM42 / DM32 1.0 version first, I think.

Graphics routines have been tested on a prime emulator (using newRPL as a basis). That's about it.

[n3mmr]

(11-20-2023 05:35 PM)c3d Wrote:  

(11-17-2023 10:51 AM)n3mmr Wrote:  I looked into the git repo and the various .md files there.
I noticed a line or two mentioning the HP Prime G1 as one of the target HW devices.
Is that really true for DB48X?
That would be really nice, given I have a useless G1 in my desk which is in dire need of a new raison d'etre.

I don't have a G1 available at the moment, only a G2. I recently acquired an HP50G, which may allow me to do a port there at some later time.

In any case, I will finish the DM42 / DM32 1.0 version first, I think.

Graphics routines have been tested on a prime emulator (using newRPL as a basis). That's about it.

That sounds great! Take your time!
P. S. The G1 keyboard seems not to be a terribly good match for the requirements of an RPL machine.

[spiff72]

(11-20-2023 07:12 PM)n3mmr Wrote:  P. S. The G1 keyboard seems not to be a terribly good match for the requirements of an RPL machine.

An overlay (or more specifically) a keylabel set would be a challenge, I think. The key spacing on the Prime is very tight vertically, leaving very little to no useable space for a background overlay with labels above or below keys. And it would be necessary to map the soft/function keys to the array of 10 keys surrounding the D-pad.

[n3mmr]

(11-20-2023 07:49 PM)spiff72 Wrote:  ]
And it would be necessary to map the soft/function keys to the array of 10 keys surrounding the D-pad.

OTOH the G1 has a touch screen so soft function keys can be handled with touch plus a system for focused menu lines, i e select one of N displayed menu lines for focus, display that line a bit larger than the others and display the other lines noticably smaller and limit selection to just the line in focus. Or use a magnifier as in text entry on Android to ease selection accuracy.

[johnb]

(10-27-2023 12:31 AM)rprosperi Wrote:  If you do decide to get rid of them, I'd be more than happy to take them off your hands; I'll happily pay shipping to NY. Once in hand, I'll fix them and get them to people that would like to use them...

LOL, I hereby volunteer to be the recipient of ANY refurbished SwissMicros machine (DM42, 41, or 32 in particular, but I'm not picky). It doesn't even need to be free! (i won't turn my nose up at "economical!")

:-D

[c3d]

(11-20-2023 09:16 PM)n3mmr Wrote:  

(11-20-2023 07:49 PM)spiff72 Wrote:  ]
And it would be necessary to map the soft/function keys to the array of 10 keys surrounding the D-pad.

OTOH the G1 has a touch screen so soft function keys can be handled with touch plus a system for focused menu lines, i e select one of N displayed menu lines for focus, display that line a bit larger than the others and display the other lines noticably smaller and limit selection to just the line in focus. Or use a magnifier as in text entry on Android to ease selection accuracy.

The touch screen is precisely what I don't like using the Prime. Don't get me wrong, having the option to touch is fine. Being forced to touch is bad, because there is no tactile feedback, and it's generally slower to navigate. When showing real menus, you can navigate using the number keys. But that does not work for softkeys.

newRPL took the approach of repurposing 6 keys as softkeys, and if I port DB48X to the Prime, I would most likely do the same.

[c3d]

DB48X v0.5.1 is out.

This release focuses on rounding up various useful RPL commands and bringing RPL a bit closer to feature-complete.

New features:
* Portable bit pattern generation commands, `gray` and `rgb` (#617)
* Add support for packed bitmaps (#555)
* Implement RPL `case` statement, extended with `case when` (#374)
* `Beep` command (#50)
* `List→` command (#573)
* `Size` command (#588)
* `Str→` command (#590)
* `Obj→` command (#596)
* Add flag to control if `0^0` returns `1` or undefined behaviour (#598)
* Unicode-based `Num` and `Chr` commands, `Text→Code` and `Code→Text` (#597)
* `IP` and `FP` commands (#601)
* Percentage operations `%`, `%CH` and `%T` (#602)
* `Min` and `Max` operations (#603)
* `Floor` and `Ceil` operations (#605)
* `Get` with a name argument (#609)
* `Put` command (#610)
* `Head` and `Tail` commands (#614)
* `Map`, `Reduce` and `Filter` commands (#613)

Bug fixes:
* Ensure rounded rectangles stay within their boundaries (#618)
* Prevent auto-power-off for long-running programs (#587)
* Fix old-style RPL shortcuts for `FS?C` and the like
* Add `FF` shortcut for `FlipFlag`
* Fix rendering of `<`, `>`, etc in old-style RPL compatibility mode (#595)
* Update various menus
* Evaluate program arguments in `IFT` and `IFTE` (#592)
* Evaluate algebraic expressions in `if`, `while` and `case` (#593)
* Load variables from state file in correct order (#591)
* Avoid truncation of state file when ASCII conversions occur (#589)
* Clear debugging state more completely after `kill` (#600)
* `Wait` no longer makes it harder to stop a program (#619)
* `mod` no longer gives wrong result for negative fractions and bignums (#606)
* No longer strip tags in non-numeric arithmetic operations (#607)

Improvements:
* Small updates to demo file
* A long `Wait` command allows the calculator to switch off (#620)
* Centering of variable names in `VariablesMenu` (#610)
* Makefile `check-ids` target to check if commands are in help or menus (#615)

[John Keith]

(11-26-2023 11:26 PM)c3d Wrote:  ...
* `Map`, `Reduce` and `Filter` commands (#613)
...

Nice to see how DB48X is progressing.

I do however take issue with the name Reduce. I would prefer either STREAM (from HP 48G) or Fold (from Haskell and GoferLists) rather than adding yet another name for the same function on RPL calculators.

[Doug (NYC)]

(11-27-2023 09:01 PM)John Keith Wrote:  Reduce ... prefer either Stream (from HP 48G) or Fold (from Haskell and GoferLists)

Another (mostly irrelevant) point: I don't mind the name; I usually think of reduce/fold as synonyms (although Haskell has both left and right folds). Clojure used map/reduce instead of map/fold, for example.

Either way, as a functional programmer, I prefer reduce/fold to Stream regardless of the 48G connection!

[John Keith]

Actually I would prefer the full suite (foldl/foldl1/foldr/foldr1 and scanl/scanl1/scanr/scanr1) though it may make the menus rather busy.

[mapleleafsa]

I am simply amazed by this project. My old 28s just died, so I just bought a DM42 just to be able to have a DB48X.

I have installed v0.5.1 and I have one bug report and one request:

1- Bug:
Solver>Root struggles to find the root of the following input:
'x^3-125'
'x'
'2'
returns "-error: No solution? and x:5.265

2. Request:
Is there any plan for a multi variable single equation solver? The ideal would something like the HP48's ("SOLVR"?) environment. There is a clever implementation in the video below (at around 0:55) where an equation on the stack is saved to the 'EQ' variable and the HP48 enters the SOLVR environment.





EDIT:
A solution to the solver problem was quickly posted by c3d on Github.

[n3mmr]

Is it at all possible for DB48x ( or DB50X ) to support a CAS system and or an equation writer of the types seen in the HP48 to HP50 calculators?

[c3d]

(11-27-2023 09:01 PM)John Keith Wrote:  

(11-26-2023 11:26 PM)c3d Wrote:  ...
* `Map`, `Reduce` and `Filter` commands (#613)
...

Nice to see how DB48X is progressing.

I do however take issue with the name Reduce. I would prefer either STREAM (from HP 48G) or Fold (from Haskell and GoferLists) rather than adding yet another name for the same function on RPL calculators.

The `Stream` alias exists for `Reduce`. In practice, this means that if you select "new" spelling, the instruction displays as "Reduce", if you select "old" spelling, it displays as "Stream". You can type both spellings in both modes.

(Same principle as "STO" vs "Store" or "Dup" vs "Duplicate").

[c3d]

(11-28-2023 09:09 PM)mapleleafsa Wrote:  I am simply amazed by this project. My old 28s just died, so I just bought a DM42 just to be able to have a DB48X.

I have installed v0.5.1 and I have one bug report and one request:

1- Bug:
Solver>Root struggles to find the root of the following input:
'x^3-125'
'x'
'2'
returns "-error: No solution? and x:5.265

Thanks for the bug report. Fixed in 0.5.2, posted today. It is broken in 0.6.0 for a different reason (some aspects of the solver are not updated for variable-precision decimals yet).

Quote:2. Request:
Is there any plan for a multi variable single equation solver? The ideal would something like the HP48's ("SOLVR"?) environment. There is a clever implementation in the video below (at around 0:55) where an equation on the stack is saved to the 'EQ' variable and the HP48 enters the SOLVR environment.

Plans, yes. A timeline... not really ;-)

Quote:EDIT:
A solution to the solver problem was quickly posted by c3d on Github.

The problem was wrong defaults for the solver settings.

[c3d]

(12-04-2023 12:59 PM)n3mmr Wrote:  Is it at all possible for DB48x ( or DB50X ) to support a CAS system and or an equation writer of the types seen in the HP48 to HP50 calculators?

It is possible and planned for this to happen.

At the moment, what works is algebraic expressions, a basic numerical solver, and a 'Rewrite' command that roughly mimics the functionality in `↑MATCH` but differs in the details.

These particular deviations are not intentional, and this is one case where I will change the current implementation to match what the HP48 does. For some reason, I had not found that general expressions rewrite feature when I searched for it, and assumed incorrectly it was not exposed as a user command.

As for equation rendering in graphic form, there are also some foundations for it (there is a graphical rendering mode for the stack) but it does not work for most objects yet. It shows graphics objects in graphic form, that's about it ;-)

[c3d]

https://github.com/c3d/DB48X-on-DM42/rel...tag/v0.6.2

The focus of this release was to complete the transition to the variable-precision decimal code. The full regression test suite was restored, with only two tests still failing (complex `asin` and `asinh`). The two missing functions, `Gamma` and `LogGamma`, were implemented. This also exposed many bugs that were fixed.

New features:

* `NumberedVariables` setting to allow `0 STO` to ease RPN transcoding (#690)
* `ClearStack` (CLEAR) command
* Variable-precision `gamma` and `lgamma` functions (#710)

Bug fixes:

* Do not leave bad expression on stack after error (#663)
* Reject unit conversion between undefined units (#664)
* Accept names of menus on the command line (#669)
* tests: CLEAR clears stack and errors (#672)
* The `:` characters now starts a tag on empty command line (#673)
* Do not evaluate tagged objects too early (#674)
* test: Entry and editing of equations (#677)
* test: `type` returns negative values in "detailed" mode (#678)
* Run loop end pointer not GC-adjusted for last allocated object (#679)
* Do not erase alpha indicator when clearing busy cursor (#680)
* Do not emit trailing space when rounding `1.999` to `2.` (#687)
* Allow expression rewrites to deal with `pow` (#694)
* Reject `«` character in symbols and commands (#695)
* Rendering of spacing for decimal numbers (#699)
* Improve precision of `atan` function
* Rendering of `+` and `-` operators in compatibility modes (#700)
* Rounding of decimal numbers no longer generates bad characters (#702)
* No longer error out rendering symbolic complex (#703)
* Parse complex numbers correctly inside equations (#704)
* Ensure `sqrt(-1)` has a zero real part (#705)
* Do not drop last digit of decimal subtraction (#706)
* Evaluate expressions during expression pattern matching (#708)
* `LastMenu` executes immediately while editing (#711)
* Add back missing angle glyphs in font (#712)
* Return correct angle quadrant for `atan2` (#715)
* `Get` no longer rejects arrays as index values (#718)
* `Get` returns correct error for bad argument types (#718)

Improvements:

* Update `.gitignore` entry
* Automated testing of setting flags (#657)
* Automated testing of non-flag settings (#670)
* Test fixed-base based numbers using HP-compatible lowercase notation (#675)
* Test fraction rendering using fancy digits (#676)
* Add test for "compatible" variant of `type` command (#678)
* test: Recover from error during data entry (#681)
* Increase default `MaxNumberBits` to 4096 (#686)
* tests: Add test for cube root of -8 (#685)
* tests: Data entry for `Σ`, `∏` and `∆` (#689)
* Restrict `STO` to names, natural numbers and specific IDs (#688)
* doc: Document flas file access for `STO` and `RCL` (#691)
* list: Optimize iterators to avoid copies (#692)
* tests: spacing-independent testing of structure rendering (#693)
* tests: adjust test suite for variable-precision decimals (#696)
* tests: Automatically exit if `-T` option is given (#697)
* tests: Check we don't accept `.` as meaning `0.` for RPL compatibility
* Add `modulus` alias back for `abs` (#707)
* Improve convergence speed and accuracy for logarithms
* Add `decimal::make` to minimize risk of sign errors
* Display stack level at top of stack level, not bottom (#709)
* Improve complex `sqrt` accuracy on real axis (#714)
* tests: Test decimal functions at full 34 digits precision (#716)
* Complex `sqrt` and `cbrt` with full precision (#717)
* tests: Take into account additional expression simplifications

Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>

[c3d]

https://github.com/c3d/DB48X-on-DM42/rel...tag/v0.6.3

The focus of this release was to reactivate the test suite and fix the problems that were found activating it.





### New features:

* HMS and DMS operations
* unit: Rendering of `dms` and `hms` units
* Allow `·` as a multiplication sign in equations
* ui: Display 'E' cursor inside parentheses
* graphics: Accept based integers as position for `DrawText`
* complex: Add setting to switch between `2+3i` and `2+i3`.

### Bug fixes:

* decimal: Fix precision loss for addition with carry
* Base: limit range of bases to 2-36
* files: Do not add a trailing zero when reading a text file
* decimal: Adjust `MinimumSignificantDigits` behaviour
* units: Do not auto-simplify `1.0` during conversion
* decimal: Normalize parsed numbers
* solver: Fix sign error in epsilon exponent for solve/integrate
* parser: Accept `x!` as input
* simulator: Avoid faulty break-through in switch statement
* complex: Make tag higher-priority than complex
* editor: Adjust cursor and select correctly during replace
* decimal: Fix display of 0.2 in NoTrailingDecimal mode
* complex: Save `this` in a GC pointer when it can move
* arithmetic: Do not fail because of surrounding error
* decimal: Clamp int32 conversions from decimal
* commands: Parse `exp10` correctly in expressions
* decimal: Avoid infinite loop computing `expm1`
* ids: Do not allow parsing of structures
* dmcp: Make sure the tests don't block on `wait_for_key`
* decimal: Use correct angle unit for negative gamma values

### Improvements:

* settings: Add classes that save/restore a given setting
* Add `XSHIFT` to shift to XSHIFT state directly
* Add NOSHIFT constant to simplify test writing
* ui: Add a variant of `close_editor` without trailing zero
* decimal: Cache gamma_ck values (accelerate gamma and lgamma)
* Replace magic constant `-1` with `EXIT_PGM`
* doc: Record performance data for 1000 iterations of SumTest
* decimal: Add tracing for gamma / lgamma function

### New tests:

* Add tests for arithmetic truncation on short bitsizes
* Add tests for on-line help
* Add test for plotting flags
* Add test for Unicode to text conversions
* Add test for rectangular complex display options
* Add tests for plot scaling functions
* Add tests for the sorting functions
* Add test for parsing text with quotes inside
* Add test for file-based `STO` and `RCL`
* Add test for 2^256 computation (buf #460)
* Fix indentation of `[PASS]` or `[FAIL]` for UTF8 characters
* Add tests for units and conversions
* Add a keyboard test checking the single-colon insert in text
* Add test for i*i=-1 auto-simplification
* Add basic test for numerical integration
* Add test for fraction formats
* Add solver test
* Add missing tests
* Add test for immediate `STO` (#390)
* Add tests for the `Cycle` command
* Add test for catalog feature
* Add test for "smart" keyboard shortcuts introduced in 0.4.6
* Add regression test for #371
* Add tests for editor operations
* Test stack operations
* Add test for `GXor`, `GOr` and `GAnd`
* Add test for `ResetModes`
* Add plotting test for every decimal function
* Add image checking for graphical tests
* Add tests for graphic and text drawing commands
* Make it possible to individually run tests.
* Add plotting tests
* Add test parsing the various spellings for commands

[Nigel (UK)]

I've built and run the simulator for v0.63. I've noticed that logs for numbers between 0 and 1 are generally incorrect. For example, 0.002 LN returns -5.4947879... whereas the real answer is -6.2146080...

Numbers greater than 1 don't seem to show this problem.

Nigel (UK)

Edit: I've just noticed that logs to base 10 don't show this problem: 0.002 LOG is correct in all displayed digits.

[c3d]

(01-26-2024 12:01 AM)Nigel (UK) Wrote:  I've built and run the simulator for v0.63. I've noticed that logs for numbers between 0 and 1 are generally incorrect. For example, 0.002 LN returns -5.4947879... whereas the real answer is -6.2146080...

Numbers greater than 1 don't seem to show this problem.

Nigel (UK)

Edit: I've just noticed that logs to base 10 don't show this problem: 0.002 LOG is correct in all displayed digits.

Darn. You are perfectly correct. And I just released 0.6.4 without fixing that bug. I'll have to do a 0.6.5 quickly.