WP43 Alternative key layout --> C43

[Jaymos]

... considering the two screenshots that I sent, I now prefer [->I] ... Also the arrow is in line with the existing longinteger<>shortinteger conversions that I already have in the HOME / UP menu (see below),
.
Clipboard38.png.
HOME / UP softmenu

Looking at this menu:

• ->I means a conversion/projection/rounding to a long integer
• Then SI<-<- means a double backwards conversion to a short integer, doesn't it?
• And ->->LI means a double conversion to a long integer, doesn't it?
• But I have absolutely no idea what ->LI<->SI shall mean.

Thanks in advance for enlightenment.

• ->I is clear
• SI<-<- is short for SI<-R<-L which means a Real will become a SI, and a L will become a R. Two presses will always end as SI.
• ->->LI is short for SI->R->LI which is clear from the above. Each press gets a step closer.
• ->LI<->SI toggles between LI and SI every time you press it, and if it starts on real it will first convert to R->LI, then start toggling.

I use these for testing functions. These were made at the same time and for similar reasons than your >DP and >SP, and they may also disappear if found not useful any more. They used to include SP and DP as well. It is useful to have these functions in a single HOME menu, with BASE and INTS also available from the softmenu instead of from the keyboard.

[Jaymos]

I have a simulator update and DM42 available, release 31, can be downloaded on my landing page:

Firstly, thanks for the participation to get the better f[Σ+] label I chose the [->I ] originating from RAPo, thanks!
.

R31a.png (51.47 KiB) Viewed 4871 times

.
Further,

The update contains a large number of behind the scenes updates from both 43S and a number of things only in the 43C. In particular, the following items changed behind the scenes and I would like some testing of the keys, arrows, backspace, long press function keys, sinc and x-th-root-of-y, R>P and P>R in complex and real pairs,

The details are:

1. 43S updated the FN keys using some brilliant code from Martin to also time out to NOP as the main keys do, but that was only for a short while and was removed again due to some conflicts. My Function key long press, double click and NOP time-outs code remain unaffected.
2. 43S also had the normal (non-FN) key reading and NOP timeout system improved and I integrated that.
3. I am bug-fixing a bug Nigel reported, that the first long press misses the g target. I improved some code on the underlining display but it is not as yet clear if the bug is squashed or not. Please let me know.
4. I re-adapted the eRPN functionality with the new ENTER code from (2) above. Working.
5. Bugfix: The X.FN / GRAPH Graph plot seemed to be dysfunctional using the demo sinx/x function. Either way, the bug was no bug - I tried the graph in DEG which obviously won’t work. So I fixed the graph demo program to auto change to RAD. Fixed.
6. I implemented the sinx/x function (sinc) in the 43S/43C in c code and this provides a 12% speed increase in the graph plot. The speed increase comes from cutting out the back and forth of register conversions using simulated RPN code of sinx/x. I mention this so you get an idea of the speed. (18 sec to 16 sec).
7. X-th-root-of-y on our keyboard needed a function long ago, as this was not yet available in 43S. Last year I wrote a simulated RPN function selectively calling the standard functions y^x, x^(½) and x^(⅓), as was appropriate. This week I re-wrote it and implemented this in c code for the 43S/43C. This seems to work well.
8. Bugfix: The CLX function display (prior to NOP, top left) did not work any more after importing the 43S key system. Fixed. Now displays BKSPC.
9. Improved the double tap BACKSP (DROP functionality), now displaying DROP as soon as you activate a double tap. This is further improved by DROP time-out to NOP if you keep pressing after the double press. More clarity as follows:
   
   • BKSPC press and release, displays BKSPC and does a CLX
   • BKSPC press, release and re-press within 0.5 seconds, displays DROP, and starts timeout cycle. Release while DROP is showing does the DROP, and keeping it in times out to the next step.
   • Keep BKSPC in for 1 sec (or keep BKSPC in after DROP is activated) then CLSTK appears, release while CLSTK is showing does CLSTK, or keep it in to timeout to NOP resulting with NONE of the actions above.
10. Cleaned up the main code base in jm.c, and
    
    • moved additional functions (.ms, fnToPolar2 & fnToRect2) to the new addon.c.
    • Moved the 5x complex constants (i, a, a², 0+0i, 1+0i) to addon.c.
    • Rewrote the code for the SI unit multipliers and moved it to addon.c.
11. I rewrote the replacement R>P and R<P functions and moved these functions to the new addons.c file. The new R<>P automatically works for a pair of reals, and for a complex number. If X contains a complex number, a mode change RECT to POLAR is done, otherwise the R<>P is done on X & Y as is usually done with all the normal type and number checks. (WP43S does not want this).
12. Added a timing test program in F.XN. PRIME_TEST will find the next 10 prime numbers and auto time stamps the operation. See X.FN, UP, PRMTEST. X is the starting number, and the next 10 primes found will be displayed and stored in R0-R9.
    
    Example:
    
    • On battery (slow operation), my DM42 does:

      Code: Select all

       1 PRMTEST in 967 ms, 1e4 PRMTEST in 1000 ms, 1e8 PRMTEST in 1276 ms, 1e12 in 1864, 1e16 in 2119, 1e20 in 2907, 1e24 in 3350, 1e28 in 3519, 1e32 in 6348, 1e36 in 5901, 1e40 in 8876, 1e44 in 9588 ms. 
      

    • Below is the record of my actions and the graph done with STAT.
      
      • Actions:
        

        Code: Select all

        g[CLΣ], clears the stats registers as well as the 400 point graph memory.
        12  f[10^X]  g[PRMTEST],  returns the time in X and last prime in Y. 
        12 [Σ+],  enter the previous exponent, enter into STATS
        

        I manually repeated this for 1 & 4, 8, 12, 16, … 44. I frequently used the [LISTXY] function (see below) to confirm that I had the correct results entered.
      • Pressed STAT / ST_GRF / PLOT to show the graph, plotting time taken for the next 10 primes, in ms, vs. the exponent of the primes tested.
      • Pressed STAT / ST_GRF / pALLr to print to file the register list, which holds the last 10 next primes larger than 1e44 that was determined: This is a snip from the TSV file:
        

        Code: Select all

        "R00"	"100000000000000000000000000000000000000000031"
        "R01"	"100000000000000000000000000000000000000000057"
        "R02"	"100000000000000000000000000000000000000000309"
        "R03"	"100000000000000000000000000000000000000000519"
        "R04"	"100000000000000000000000000000000000000000673"
        "R05"	"100000000000000000000000000000000000000000829"
        "R06"	"100000000000000000000000000000000000000000903"
        "R07"	"100000000000000000000000000000000000000000997"
        "R08"	"100000000000000000000000000000000000000001017"
        "R09"	"100000000000000000000000000000000000000001087"

      .

    • 

      20200428-00253246.png (1.64 KiB) Viewed 4871 times

      Last 10 samples entered, checked with LISTXY.
      .

    • 

      20200428-00255178.png (1.35 KiB) Viewed 4871 times

      PLOT of the STAT data, with the exponent of the 10 primes on X, and the time it took to run the 10 prime test on Y.
      .

Edited for a few typographical errors.

[Dani R.]

Top left, on the Layout1 (the new template) we currently have on f[Σ+] the function RND, which is short for ROUND and which rounds the real number in X to the current selected display setting say FIX 3, i.e. chops off all the decimals which are not visible in the X register. ROUND also sits both in f[EEX] (DISP) and in f[PARTS] (PARTS), both on f[FN2].

Testing the calculator a lot, I find that I much more often need to round a real number to an integer. Most importantly it converts it to a type long integer as well. This sits on f[3] (PARTS) and FN1.

Both functions fit in there, so neither is a misfit.

Any support for changing RND to IP ??

Regards
J

I see that when I suggested ROUND, I missed to explain why I came up with this function. If you convert decimal fractions to fractions and vice versa, it is quite possible that rounding errors may occur even on WP43. For the further processing of a result it can make a difference whether you continue with 5.5, 5.50001 or 5.49999. Therefore I thought ROUND directly on a key can be useful. I myself will not calculate with fractions. But it is true, ROUND is in the menu DISP.

[Walter]

If you convert decimal fractions to fractions and vice versa, it is quite possible that rounding errors may occur even on WP43.

With respect to WP 43S, please tell me where. A concrete example will be appreciated. Thanks in advance.

[Dani R.]

If you convert decimal fractions to fractions and vice versa, it is quite possible that rounding errors may occur even on WP43.

With respect to WP 43S, please tell me where. A concrete example will be appreciated. Thanks in advance.

Then I throw myself into the dust and apologize for suspecting that conversions from fractions to decimal fractions can lead to rounding errors back and forth. This must have been an age-old observation.

7
1/X
1/X
7
-
Leads to -2.x10 up -33.
This is then a deviation to 0, which is not necessarily to be named a rounding error.

7
1/X
1/X
ROUND
7
-
Leads to 0.

[Walter]

If you convert decimal fractions to fractions and vice versa, it is quite possible that rounding errors may occur even on WP43.

With respect to WP 43S, please tell me where. A concrete example will be appreciated. Thanks in advance.

Then I throw myself into the dust and apologize for suspecting that conversions from fractions to decimal fractions can lead to rounding errors back and forth. This must have been an age-old observation.

7
1/X
1/X
7
-
Leads to -2.x10 up -33.
This is then a deviation to 0, which is not necessarily to be named a rounding error.

No need for throwing yourself in the dust (and especially not into) - it won't improve thinking.

As long as the maximum allowed denominator of fractions on the 43S is 9999, I don't expect rounding errors showing up in fraction-to-decimal conversions back and forth. Simple reasoning: we're many orders of magnitude away from the precision limits of the calculator.

Yes, the -2x10^(-33) are correct, and they are the most precise result you can achieve using a 34-digit calculator in this case. Such is life. But you will never see something like this in a fraction on the 43S. So don't be afraid, get up and clean your clothes - and don't forget washing hands.

[Dani R.]

I have to ask again, I'm a little too lazy to think right now. I must have swallowed too much dust despite my N95/R95/P95 mask. Shouldn't really be possible.

'->' is short for 'ROUNDI', right? ROUNDI' can also be found in the DISP...
So I think now that neither 'ROUND' nor 'ROUNDI' deserves a place on f[Σ+]. But this is only my opinion.

Is there any other (often used) function which deserves a place on f[Σ+] in the environment of conversions?
'->->LI' ?
'SI<-<-' ?

With 'Sigma+ ASN' it is planned to be able to assign 'USER', 'Σ+', 'CC', 'PRGM', 'MyMenu', 'Alpha' to 'Σ+ in non-USER mode. To avoid losing 'Σ+' you could set 'Σ+' to f[Σ+] .

Or, in addition to 'Σ+ ASN', you could also store a user-assigned function on f[Σ+], independent of the USER mode. Yes, the clarity is lost once again. And I have no shortcut for this second programmable key.

We must have missed some important function. Or not.



This is just for fun: TIMER on f[Σ+] (this should be a symbol) and the print menu on g[0]. Just kidding.

[Jaymos]

'->' is short for 'ROUNDI', right? ROUNDI' can also be found in the DISP...
So I think now that neither 'ROUND' nor 'ROUNDI' deserves a place on f[Σ+]. But this is only my opinion.

'->I' is [ROUNDI] and is currently on f[Σ+].

Is there any other (often used) function which deserves a place on f[Σ+] in the environment of conversions?
'->->LI' ?
'SI<-<-' ?

This is an option, but then I would rather prefer [->LI<>SI] and this could be abbreviated to [->I] any way, because it not only does a ROUNDI, it swaps back and forth between SI and LI every time you press it. So this is not a bad suggestion, and the label stays [->I]. How does that sound?

Both the KEYS packages [UΣ CC] or [U^ CC] change (in USER mode) the f[Σ+] to [SI<-<-] and g[Σ+] to [->->LI], while [Σ+] is changed to either CC or MyMenu.

With 'Sigma+ ASN' it is planned to be able to assign 'USER', 'Σ+', 'CC', 'PRGM', 'MyMenu', 'Alpha' to 'Σ+ in non-USER mode. To avoid losing 'Σ+' you could set 'Σ+' to f[Σ+] .

Or, in addition to [Σ+ ASN], you could also store a user-assigned function on f[Σ+], independent of the USER mode. Yes, the clarity is lost once again. And I have no shortcut for this second programmable key.

Interesting points, let me recap the f[Σ+] (before you lose it ).

The menu [Σ+ ASN] does the non-user mode re-assignments on [Σ+] as you state: 'USER', 'Σ+', 'CC', 'PRGM', 'MyMenu', 'Alpha'.

In addition, there are KEYS mini-packages available for the above functions (red box below), which automatically assign functions simultaneously to [Σ+] in BOTH the user mode and non-user mode.
.

Clipboard01b.png (23.13 KiB) Viewed 4728 times

KEYS menu, showing the packages, as well as the [Σ+ ASN] menu button.

We must have missed some important function. Or not.

Maybe [->LI<>SI] is the one we missed on that location. I must just fix it to first do a ROUNDI not IP which it currently does.

[Dani R.]

The menu [Σ+ ASN] does the non-user mode re-assignments on [Σ+] as you state: 'USER', 'Σ+', 'CC', 'PRGM', 'MyMenu', 'Alpha'.

In addition, there are KEYS mini-packages available for the above functions (red box below), which automatically assign functions simultaneously to [Σ+] in BOTH the user mode and non-user mode.

Okay, I missed the KEYS mini-packages.

Is there any other (often used) function which deserves a place on f[Σ+] in the environment of conversions?
'->->LI' ?
'SI<-<-' ?

This is an option, but then I would rather prefer [->LI<>SI] and this could be abbreviated to [->I] any way, because it not only does a ROUNDI, it swaps back and forth between SI and LI every time you press it. So this is not a bad suggestion, and the label stays [->I]. How does that sound?

...

Maybe [->LI<>SI] is the one we missed on that location. I must just fix it to first do a ROUNDI not IP which it currently does.

Yes, even though I will probably use this function rarely, I think that the revised function [->LI<>SI] makes sense to find it here. And the shortcut seems to fit.

[Jaymos]

Exactly as the doctor ordered, Jaymos!

Is where a way to let the HOME menus be defined by configuration files?

That way all users could have their own favourite setup. And might the HOME menus also be used as custom layouts from programs (replacing the original ones as long as the program is running)?

It is not impossible and similar to the coming MyMenu in 43S. I like the idea though of a file based config which would allow multiple setups to be managed from the disk.
...

I thought a lot about Haakon’s suggestion above and got to the following workable solution:

I don’t like the idea of changing the Home menu (dynamic changes will interfere with my existing HOME menu dynamic allocations from the keyboard). I also won’t like to change MyMenu as it will interfere with the future 43S storing and editing MyMenu content. I’d rather keep both the HOME and MyMenu systems as designed and see if I can wedge in additional functionality.

Adding a user defined softmenu called XEQM that is configured using a text file called XEQMENU.TSV is quite feasible. It seems like a good solution. I started with a normal menu below, with labels which will get dynamically replaced with those from the text file, see example file below.
.

Clipboard111.png (1.15 KiB) Viewed 4173 times

Menu with 18 spots for user FN buttons.

XEQM would be an entry in the HOME menu, as well as in the X.FN menu. I am also thinking to add a KEYS package that would put XEQM on the XEQ button, in both USER and NORMAL modes, with a double tap to access the original XEQ function. The XEQM function keys would then be defined in a user text file XEQMENU.TSV on the flashdrive, containing label definitions and simple RPN definitions for each button.

After the text file below would load, the menu would change to:

Clipboard112.png (20.33 KiB) Viewed 4173 times

Code: Select all

X_P2 CLSTK  //Example of any arbitrary command stuck to the FN2 primary.//
CLSTK
RETURN

X_P5 PRIMEX  //Example of generating a large prime number (Mersenne Prime) and timing it in seconds.//
TICKS 
"2" EXIT 
"2203" 
Y^X 
"1" - 
PRIME? 
X<>Y 
TICKS 
X<>Y - 
“10.0” / 
RETURN

X_P6 XEQ  //Example of placing a copy of the original XEQ command on FN6, directly above the XEQ key.//
XEQ
RETURN

Other ideas?
Like it?
Or not?
Haakon, more or less what you had in mind?