Post Reply 
newRPL - build 1255 released! [updated to 1299]
12-06-2019, 09:25 AM
Post: #621
RE: newRPL - build 1255 released! [updated to 1299]
(11-14-2019 07:36 AM)jpcuzzourt Wrote:  
(11-11-2019 10:27 PM)Claudio L. Wrote:  That's actually an area where we could use some community effort. If somebody can come up with a printable overlay, I'd order a few myself! The keyboards I believe have physically the same geometry, so the same overlay would work for 50g, 40gs, 39gs, etc.
The best image I could find is what I used for newRPL Desktop, so if you have it installed just look in the program folder and copy the jpg from there. But I'm not sure it has enough quality for printing.

Thanks for this. I found newrpl-sources/bitmap/keyboard.png. It's useable when scaled in GIMP to 69x104mm* (261x393pixels), but it's a bit blurry and the shifted values are difficult to make out. I may work on it a little if I find some time.

Edit: I've started working on a clean newRPL keyboard layout graphic for us to use. I'll share when I have it in a useful state.

May be it usefull. I did began this drawing for my 39gs, but later bought "second hand" 49g+. This overlay not tested with print. In QCAD needs to move text symbols.


Attached File(s)
.txt  newrpl_overlay.dxf.txt (Size: 302.41 KB / Downloads: 17)
Find all posts by this user
Quote this message in a reply
12-12-2019, 06:54 AM (This post was last modified: 12-12-2019 06:55 AM by erazor.)
Post: #622
Interactive stack mode and a glitch.
Due to missing hardware I'm only using the Android (build 1315) and Linux (build 1317) versions of newrpl and these problems might not affect the actual firmwares.

Something that's not quite clear after reading the manual wiki:
In interactive stack mode it's possible to scroll half a line above and below the entries. Why is that so?

Also I found a glitch. I have the problem that the cursor in the command line stops blinking after about half a minute. After that, error messages are not vanishing automatically anymore and the mode indicators when pressing alpha are out of sync. Looks like some timer stops here.

Thanks for considering.
Find all posts by this user
Quote this message in a reply
12-12-2019, 11:20 PM
Post: #623
RE: newRPL - build 1255 released! [updated to 1299]
(12-12-2019 06:54 AM)erazor Wrote:  Due to missing hardware I'm only using the Android (build 1315) and Linux (build 1317) versions of newrpl and these problems might not affect the actual firmwares.

Something that's not quite clear after reading the manual wiki:
In interactive stack mode it's possible to scroll half a line above and below the entries. Why is that so?
When you need to paste a block of objects it's usually inserted where you have the cursor. That half step allows you to insert before the top element and after the last one.

(12-12-2019 06:54 AM)erazor Wrote:  Also I found a glitch. I have the problem that the cursor in the command line stops blinking after about half a minute. After that, error messages are not vanishing automatically anymore and the mode indicators when pressing alpha are out of sync. Looks like some timer stops here.

Thanks for considering.
That glitch only happens on Linux. For whatever reason, it seems Qt timers go crazy on Linux (they are used to simulate the timer of the calc and present a familiar hardware to newRPL). After a while either the timers go extremely slow, or extremely fast, or they stop altogether.
Slow: You can see the cursor stops blinking but key repeats still work, but take much longer than normal.
Fast: Pressing cursors left and right on a long line you'll see it go all the way left/right in milliseconds.
Stop: Key repeats stop working, also if you throw an error or use the inline help, the help stays forever on screen, covering your status area and the second menu.

These glitches are known, only happen to the PC version and only on Linux, and I have no idea how to resolve them, unfortunately. I'm doing nothing but starting a timer and counting ticks, I can't see anything wrong with that. I noticed the glitch on Qt 5.9, now we are up to 5.13 and it is still there.
Find all posts by this user
Quote this message in a reply
12-13-2019, 07:12 AM
Post: #624
How to participate?
Hi Claudio,
I'm sifting through your newrpl code base and found some smaller things like typos, delete instead of delete[] and so on.
Are you interested in me providing you some patches for improving? How do you want me to do it? Fork the sourceforge project and send pull requests so you can cherry-pick what you like? Or single patches you can apply? How to communicate these?
Find all posts by this user
Quote this message in a reply
12-19-2019, 11:43 PM (This post was last modified: 12-19-2019 11:45 PM by Claudio L..)
Post: #625
RE: newRPL - build 1255 released! [updated to 1299]
All ROMs updated to build 1320.

Most important changes in this update:
* New command MMAP, similar to MAP but for matrices/vectors. It takes a program or a symbolic and applies it to all elements. It defines variables i,j for the program to know the position of wach item, as well as Aij for the symbolic to know the existing element. For example:
[ 10 20 30 ] 'Aij+j' MMAP ---> [ '10+1' '20+2' '30+3' ]

* Various improvements to the assembly-like opcodes, the wiki was updated to reflect the latest changes already. It adds AND, OR and XOR and better flag management to improve the ability to code complex logic for IF style statements (see the examples in the wiki).

* Encoding of attributes for variables is now user-readable. Syntax is similar to what was described in this post, but added as a postfix-tag to the ident. For example, 'X*0' EVAL won't autosimplify to 0, because X could be infinite. To indicate the system that X is finite, real and positive, use 'X*0' 'X:R≥0:' ASSUME, then EVAL or AUTOSIMPLIFY will apply the proper simplification and return 0.

* New operator "given-that" symbol '|' is not implemented. It applies a mix of hints or rules to an expression: 'X+3|X:→4' EVAL will return 7, regardless of the value of X. You can apply more than one rule/hint by using parenthesis and the argument separator:
'X^2/Y|(X:→Y^2,Y:R: )' will replace X with Y^2 and then hint that Y is real and finite.
EDIT: I had to edit the formula above to prevent the : and the ) from forming an emoticon. There should be no space after :.

That's it for now, please review and report bugs.

PS: The PROOT infinite loop reported in a recent post is due to numerical instability of the solution for higher grade polynomials, I'm still looking for a way to let the algorithm adapt and use more precision if needed.
Find all posts by this user
Quote this message in a reply
12-20-2019, 03:40 AM (This post was last modified: 12-20-2019 03:44 AM by _nmr_.)
Post: #626
RE: newRPL - build 1255 released! [updated to 1299]
(12-19-2019 11:43 PM)Claudio L. Wrote:  PS: The PROOT infinite loop reported in a recent post is due to numerical instability of the solution for higher grade polynomials, I'm still looking for a way to let the algorithm adapt and use more precision if needed.

Hi.
If 20 changed to other number 19, 21 or 20.0 , PROOT working good.
Pic. 1 - command input;
Pic.2 - after enter key pressed;
Pic.3 - result of evaluating.


Attached File(s) Thumbnail(s)
           
Find all posts by this user
Quote this message in a reply
12-20-2019, 05:18 PM
Post: #627
RE: newRPL - build 1255 released! [updated to 1299]
(12-20-2019 03:40 AM)_nmr_ Wrote:  
(12-19-2019 11:43 PM)Claudio L. Wrote:  PS: The PROOT infinite loop reported in a recent post is due to numerical instability of the solution for higher grade polynomials, I'm still looking for a way to let the algorithm adapt and use more precision if needed.

Hi.
If 20 changed to other number 19, 21 or 20.0 , PROOT working good.
Pic. 1 - command input;
Pic.2 - after enter key pressed;
Pic.3 - result of evaluating.

Yes, in most cases the algorithm works fine, I have tested in the past up to degree 20 and worked great. However, there's no guarantee that a specific set of coefficients can be harder on the algorithm and cause problems. The good part is you provided a test case that fails 100% of the time, so I was able to reproduce it and start testing.
It will be fixed on the next update.
Find all posts by this user
Quote this message in a reply
12-20-2019, 09:42 PM
Post: #628
RE: newRPL - build 1255 released! [updated to 1299]
(12-19-2019 11:43 PM)Claudio L. Wrote:  * New command MMAP, similar to MAP but for matrices/vectors. It takes a program or a symbolic and applies it to all elements. It defines variables i,j for the program to know the position of wach item, as well as Aij for the symbolic to know the existing element.


Oh my goodness this is nice! I actually wouldn't mind seeing 'i' and 'Ai' added to regular old MAP - though I suppose one could always do AXL << foo bar >> MMAP AXL. (It would act weird for lists of lists, but you're basically asking for it at that point!)

Quote:* Encoding of attributes for variables is now user-readable. Syntax is similar to what was described in this post, but added as a postfix-tag to the ident. For example, 'X*0' EVAL won't autosimplify to 0, because X could be infinite. To indicate the system that X is finite, real and positive, use 'X*0' 'X:R≥0:' ASSUME, then EVAL or AUTOSIMPLIFY will apply the proper simplification and return 0.


I like the changes, but I'm still dubious of having variables be 'possibly infinite' by default. My gut says it makes more sense for them to be finite by default, but no doubt there may be something I'm missing, as so often in the past.

Is this something worth having a flag for?

Quote:* New operator "given-that" symbol '|' is not implemented. It applies a mix of hints or rules to an expression: 'X+3|X:→4' EVAL will return 7, regardless of the value of X. You can apply more than one rule/hint by using parenthesis and the argument separator:
'X^2/Y|(X:→Y^2,Y:R: )' will replace X with Y^2 and then hint that Y is real and finite.
EDIT: I had to edit the formula above to prevent the : and the ) from forming an emoticon. There should be no space after :.


Looks fun, I'll try it out.

Sorry I've been scarce lately, btw. That pesky "real life" thing has been distracting.
Find all posts by this user
Quote this message in a reply
12-20-2019, 10:36 PM
Post: #629
RE: newRPL - build 1255 released! [updated to 1299]
(12-20-2019 09:42 PM)The Shadow Wrote:  
(12-19-2019 11:43 PM)Claudio L. Wrote:  * New command MMAP, similar to MAP but for matrices/vectors. It takes a program or a symbolic and applies it to all elements. It defines variables i,j for the program to know the position of wach item, as well as Aij for the symbolic to know the existing element.


Oh my goodness this is nice! I actually wouldn't mind seeing 'i' and 'Ai' added to regular old MAP - though I suppose one could always do AXL << foo bar >> MMAP AXL. (It would act weird for lists of lists, but you're basically asking for it at that point!)

Yes, one of the reasons I decided to split the matrix functionality from MAP is because lists are more complicated, they can be nested within each other, and may contain absolutely any object.
With a vector/matrix object, having a pair of (i,j) is actually useful, and using a symbolic in place of a program is an idea I (cough) stole (cough) from MAKEMAT() on the Prime.
Since MMAP works on an existing matrix, you'd have to create one with CON then apply MMAP to get the equivalent of MAKEMAT().

I don't see why I couldn't add a local variable tracking an index for the regular MAP (other than slowing down the entire process, it doesn't cause any problems), much like the NSUB/ENDSUB commands do for DOSUBS. The variable 'Ai' wouldn't make sense, since MAP does not accept a symbolic, only a program, and the program receives the element in the stack. Same thing with MMAP, Aij does not exist when you use a program, only for symbolics.

(12-20-2019 09:42 PM)The Shadow Wrote:  I like the changes, but I'm still dubious of having variables be 'possibly infinite' by default. My gut says it makes more sense for them to be finite by default, but no doubt there may be something I'm missing, as so often in the past.

Is this something worth having a flag for?

The way I saw it originally is that simplifying for example A*0 with 0 is completely wrong unless you have certain knowledge about the variable A (in this case, you know A cannot be infinite). So the system should act on the safe side and leave it alone unless the user explicitly provides that knowledge.
On the other hand, when actually using it, it quickly gets annoying that all these trivial things don't get simplified: A/A, 0*A, A^0, etc. so I'd say a flag controlling the default assumptions is completely warranted (and I hate flags):
Flags for default assumptions:
* Force REAL: All variables assumed real (when no hint is given) regardless of Complex mode enabled or not. The default is variables assumed complex in complex mode, real otherwise.
* Force COMPLEX: All variables assumed complex (when no hint is given) regardless of Complex mode.
* Force FINITE: All variables assumed finite
Find all posts by this user
Quote this message in a reply
12-21-2019, 12:45 AM (This post was last modified: 12-22-2019 06:18 AM by The Shadow.)
Post: #630
RE: newRPL - build 1255 released! [updated to 1299]
(12-20-2019 10:36 PM)Claudio L. Wrote:  With a vector/matrix object, having a pair of (i,j) is actually useful, and using a symbolic in place of a program is an idea I (cough) stole (cough) from MAKEMAT() on the Prime.


"Good authors borrow. Great authors steal."

Quote:I don't see why I couldn't add a local variable tracking an index for the regular MAP (other than slowing down the entire process, it doesn't cause any problems), much like the NSUB/ENDSUB commands do for DOSUBS.


I'd be down, as long as the slowdown isn't too extreme - and I can't see why it would be.

Quote:The variable 'Ai' wouldn't make sense, since MAP does not accept a symbolic, only a program, and the program receives the element in the stack. Same thing with MMAP, Aij does not exist when you use a program, only for symbolics.


Good to know about Aij not existing for programs. Can a program just refer to i and j, or do you need something like << -> i j << >> >>?

Quote:The way I saw it originally is that simplifying for example A*0 with 0 is completely wrong unless you have certain knowledge about the variable A (in this case, you know A cannot be infinite). So the system should act on the safe side and leave it alone unless the user explicitly provides that knowledge.


See, I'm approaching it from the point of view that no real or complex number is infinite. You have to deliberately extend the real number line or complex plane to allow for infinite numbers, and there's multiple ways to do it.

Quote:On the other hand, when actually using it, it quickly gets annoying that all these trivial things don't get simplified: A/A, 0*A, A^0, etc. so I'd say a flag controlling the default assumptions is completely warranted (and I hate flags):


This too. Your default flags are probably a good compromise (I'd probably use 'Force FINITE' constantly, the others seldom), but even they won't handle A/A or A^0. Do we need to add 'Force NONZERO' too?

EDIT: It's definitely riskier, since of course zero IS a real and complex number. And assuming things nonzero is a classic way to miss solutions. But:

1. OldRPL does it that way.

2. Most of the time, if you've got a situation where something can be zero, you're not going to be dividing by it anyway. (Famous last words, I know.)

3. The annoyance factor you mentioned above. 'X^2/X' not being the same as 'X' is technically correct but in a practical sense often wrong - it obscures rather than illuminating an expression.

OldRPL made a similar design choice regarding absolute values - relegating most uses of them in simplification to "rigorous mode".
Find all posts by this user
Quote this message in a reply
12-21-2019, 02:52 PM
Post: #631
RE: newRPL - build 1255 released! [updated to 1299]
About PROOT.
Symmetric vectors hangs calculator.
[ 1 2 3 4 5 4 3 2 1] needs longer time to evaluate roots.
[1 2 3 4 5 6 5 4 3 2 1] hangs up the calculator.
[1 2 3 4 5 6 7 6 5 4 3 2 1] hangs up the calculator.
Find all posts by this user
Quote this message in a reply
12-21-2019, 05:08 PM
Post: #632
RE: newRPL - build 1255 released! [updated to 1299]
I'm in the process of creating a printable newRPL keyboard layout for my 39gs. It's a vectorized graphic with the right proportions. I'm not quite done but attached is my current process.

I'm asking the community to tell me which keyboard labels I should add and how the colors should be changed before finalizing it. Also I'm not sure if the scale is 100% perfect and what font to use. Most labels still have artefacts from vectorizing.

The file is created with Inkscape and is organized in layers with cut contours defined for the final sticker.

With another color scheme, exported as bitmap graphic and prettied up it might be used as keyboard graphic for the desktop and Android versions.

Have fun with it.


Attached File(s)
.txt  newRPL_v1.svg.txt (Size: 118.88 KB / Downloads: 28)
Find all posts by this user
Quote this message in a reply
12-22-2019, 03:44 PM
Post: #633
RE: newRPL - build 1255 released! [updated to 1299]
(12-21-2019 02:52 PM)_nmr_ Wrote:  About PROOT.
Symmetric vectors hangs calculator.
[ 1 2 3 4 5 4 3 2 1] needs longer time to evaluate roots.
[1 2 3 4 5 6 5 4 3 2 1] hangs up the calculator.
[1 2 3 4 5 6 7 6 5 4 3 2 1] hangs up the calculator.
Thanks, I need some time to get into this algorithm. It seems to be a weakness of the algorithm for certain polynomials, it's going to take me some time to figure this out, there's nothing wrong with the way it's coded, which makes it worse for me...
Find all posts by this user
Quote this message in a reply
12-27-2019, 05:32 PM
Post: #634
RE: newRPL - build 1255 released! [updated to 1299]
I updated all ROMs to build 1323.
It fixes a few bugs and introduces 2 new assembly-like commands:
SGET and SPUT (as in Stack GET and Stack PUT).

Playing with the N-queens benchmark I realized access to the stack was always in hard-coded terms (using the pseudo registers S1..S7) and there was no indexed access to the stack.
SGET/SPUT use the stack as a vector of objects:

SGET.lvl --> Reads the stack at level lvl, where 'lvl' can be a register, a literal or a stack reference to an index number.
SPUT.lvl.A --> Stores A into stack level 'lvl'. Both A and 'lvl' can be anything.

With these 2 commands, indirect access to the stack is provided.

I used it to code one more example:
Code:

«
:CLR.A.8
:PUSH.A.8

:CMP.B.8
:LOOP.NE
::
    :B+=1
    :SPUT.B.8
    :CMP.2.1
    :LOOP.NE
    ::
        :A+=1
        :C=B
        :CMP.C.1
        :LOOP.GT
        ::
            :C-=1
            :D=SGET.B
            :D-=SGET.C
            :CMP.D.0
            :E=CHK.EQ
            :F=B-C
            :G=ABS.D
            :CMP.G.F
            :F=CHK.EQ
            :OR.E.F
            :SKIP.EQ
            ::
                :C=0
    
                :F=SGET.B
                :F-=1
                :SPUT.B.F
    
                :CMP.F.0
                :LOOP.EQ
                ::
                    :B-=1
                    :F=SGET.B
                    :F-=1
                    :SPUT.B.F
                    :CMP.F.0
                ;
            ;
            :CMP.C.1
        ;
    ;
    :CMP.B.8
;

:POP.1.7
:S1=A

»

The code above is the N-queens benchmark, verbatim translation of the Pascal sample code.
Interestingly enough (and sort-of expected), the RPL solution using stackrobatics is slightly faster than this one (106 ms vs. 114 ms).
Find all posts by this user
Quote this message in a reply
01-02-2020, 07:32 PM
Post: #635
RE: newRPL - build 1255 released! [updated to 1299]
A thought I had: What if you could include key definitions in a menu/directory, that would be active only while that menu was visible? So for example, if the menu or directory deals with commands involving quaternions, you could have the * key do quaternion multiplication.

Or is this more the province of the fabled Forms engine?

Thinking about it some more, you could get this behavior in directories by having a global key definition that calls a program variable. But it still wouldn't work in temporary menus.
Find all posts by this user
Quote this message in a reply
01-02-2020, 08:35 PM
Post: #636
RE: newRPL - build 1255 released! [updated to 1299]
(01-02-2020 07:32 PM)The Shadow Wrote:  A thought I had: What if you could include key definitions in a menu/directory, that would be active only while that menu was visible? So for example, if the menu or directory deals with commands involving quaternions, you could have the * key do quaternion multiplication.

Or is this more the province of the fabled Forms engine?

Thinking about it some more, you could get this behavior in directories by having a global key definition that calls a program variable. But it still wouldn't work in temporary menus.

Interesting.
What is possible right now and would work quite well is to override the key globally. The handler would check the active menu number (with RCLMENU) and provide the new behavior only if the proper menu is active, otherwise chain to the previous handler.
Find all posts by this user
Quote this message in a reply
01-02-2020, 08:44 PM
Post: #637
RE: newRPL - build 1255 released! [updated to 1299]
(12-21-2019 02:52 PM)_nmr_ Wrote:  About PROOT.
Symmetric vectors hangs calculator.
[ 1 2 3 4 5 4 3 2 1] needs longer time to evaluate roots.
[1 2 3 4 5 6 5 4 3 2 1] hangs up the calculator.
[1 2 3 4 5 6 7 6 5 4 3 2 1] hangs up the calculator.

I fixed this issue, it will come up on the next update.
Turns out the problem was with root multiplicity (which happens on all those symmetric coeff. vectors), the small rounding errors were not detecting multiplicity properly. I now require the result of the polynomial to be zero with a precision of 7/8 of the current system precision. In other words, for 32 digits I allow errors of up to 32/8 = last 4 digits. Before I was allowing for rounding error on the last digit only, and this was not enough for higher degree polynomials.
Once the algorithm missed a multiple root it would loop forever...
Find all posts by this user
Quote this message in a reply
Post Reply 




User(s) browsing this thread: 3 Guest(s)