newRPL - build 1255 released! [updated to 1299]

[erazor]

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.

[Claudio L.]

(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.

[erazor]

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?

[Claudio L.]

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.

[_nmr_]

(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.

[Claudio L.]

(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.

[The Shadow]

(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.

[Claudio L.]

(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

[The Shadow]

(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".

[_nmr_]

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.

[erazor]

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.

[Claudio L.]

(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...

[Claudio L.]

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).

[The Shadow]

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.

[Claudio L.]

(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.

[Claudio L.]

(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...

[Klaus]

Hello community,
I have written several extensive programs in UserRPL for the 50g. I want to take advantage of the higher speed and accuracy of NewRPL. Is there a way to transfer them to the NewRPL-HP50 after some necessary modifications? It would be a "slave labour" to type this manuel one.
Greeting Klaus

[compsystems]

In previous post it is mentioned that the library or graphic module of NewRPL is in development, I think it is a good idea to give some compatibility with names and argument of the MatPlotLib et Turtle library

CASIO, TEXAS INSTRUMENTS are working in this library, and XCAS in compatibility

Code:

from turtle import *

def koch(n,l):
  if n==0:
    forward(l)
  else:
    koch(n-1,l/3)
    left(60)
    koch(n-1,l/3)
    right(120)
    koch(n-1,l/3)
    left(60)
    koch(n-1,l/3)

pencolor("blue")
penup()
goto(-180,-50)
pendown()
koch(4,360)

Source
https://www.planet-casio.com/Fr/forums/l...p?id=16154

[3298]

(02-04-2020 07:24 PM)compsystems Wrote:  In previous post it is mentioned that the library or graphic module of NewRPL is in development, I think it is a good idea to give some compatibility with names and argument of the MatPlotLib et Turtle library

You seem to have forgotten (again!) that these commands are extremely unlikely to be builtin due to their utter lack of usefulness to the general programmer and engineer (which the 50g has always been made for), instead requiring you to implement them. That also means YOU get to choose what their names are.
In short: Claudio's work on such compatibility is done already, and it has been since user programs could be written and named (i.e. for several years).

---

Since you seem to be incapable of actually implementing something rather than merely tossing ridiculous suggestions for your wanted builtin commands around, let me show you some code that demonstrates how trivial implementing your turtle commands in RPL really is.
For this I'm using for the most part very basic RPL functionality (stack juggling, global variables, IF ... THEN ... END, a little bit of trig and arithmetic operators, units to work with angle modes), the command LINE from old UserRPL (i.e. a single really elementary graphics command), and a little bit of complex numbers which LINE uses for coordinates. This means that as soon as LINE is implemented in newRPL, this should all just work.

Let's start with "goto". The purpose of "goto" is to update the stored position of the cursor (a.k.a. the turtle) to the given coordinates, and draw a line between the previous and new position if drawing is enabled (a.k.a. the pen is down), right? If so, try this:

Code:

« i * + IF turtlepen THEN turtlepos OVER LINE END 'turtlepos' STO »

Then, "forward" should be the same as a "goto" to a position calculated as the current position plus a given offset in a previously stored direction, correct? Let's use some trig to translate the offset into Cartesian coordinates, followed by a call to the "goto" program:

Code:

« turtledir COS OVER * turtlepos RE + turtledir SIN ROT * turtlepos IM + goto »

"left" should be as simple as updating the direction. Let's make sure angle mode changes between invocations don't affect it by always converting the input to degrees first (if you want the input to always be interpreted as degrees regardless of mode, use →UNIT in place of CONVERT):

Code:

« 1._° CONVERT turtledir + 'turtledir' STO »

"pendown" just sets the boolean flag read by the "goto" program:

Code:

« 1. 'turtlepen' STO »

I'm skipping pencolor because it's pointless on a monochrome screen. You can make it an alias for DROP (to get its single parameter off the stack) if you really need it.

Now, for your home assignment: Implement "right" and "penup" yourself. You can use "left" and "pendown" as templates. Also, implement an initialization program that sets the global variables used in this set of programs (turtlepos, turtledir, turtlepen) to some sane defaults and turns off obstructions like axes and their labels.

With these commands, the RPL version (because newRPL is obviously all about RPL) of that example you lazily grabbed off the internet becomes:

Code:

«
  IF OVER 0. ==
  THEN NIP forward
  ELSE
    OVER 1. - OVER 3. / koch
    60. left
    OVER 1. - OVER 3. / koch
    120. right
    OVER 1. - OVER 3. / koch
    60. left
    SWAP 1. - SWAP 3. / koch
  END
» 'koch' STO
penup
-180. -50. goto
pendown
4 360 koch

Is that enough hand-holding for you, or do I need to provide a solution for the home assignment too?

[Claudio L.]

I haven't posted in a while here so here's an update on what's going on with newRPL:
Currently the project is undergoing some necessary cleanup and reorganization in the code, that's why there's silence and no new features are coming out.
Soon there will be an update that fixes a few bugs, and makes the firmware update procedure much more stable on all platforms.
It adds more consistency in some operators, adds more universal support for units on most commands. As far as numeric solvers, the only new thing is the QR decomposition was implemented and the roots of polynomials now manages the tolerances better so it doesn't stop at high degree polynomials.
Regarding the graphics engine: It's on hold for the time being. No, it does NOT have a tortoise (or any other lettuce-eating reptile).
Graphics commands actually get compiled in a very tight format and create plot objects. Plot objects are vector graphics, so you can plot a function once, then zoom in and out of that plot object without seeing pixelation. Of course at some point if you zoom in you'll have to re-plot the area increasing the point density to get an accurate plot. But the idea is that:
a) Plot objects aren't limited by the screen size, or the screen resolution. They even support color as they are implemented.
b) Plot objects can be rendered to different "surfaces", for instance you could render the same object to the 50g screen, or to a PNG file on an SD card, or to a bitmap (grob), or even exported to other vector formats like svg.
Right now plot objects are implemented and working. Rendering a plot object to a is bitmap is the part that's still not implemented completely (I got stuck at rendereing bezier curves when I decided to spend more time on other areas of the project).

And the best part, here's the plan for 2020 (and beyond, I'm not saying all this will be done in 2020):
* Continue the code cleanup and reorganization.
* Add a complete graphics library that can draw in color and grayscale. This library will also be the basis of the renderer for plot objects and for the UI.
* Reorganize the UI to be flexible (to use different screen resolutions and color as well). This will allow newRPL Desktop to take advantage of the PC screen and not be limited to the simulated 50g grayscale screen.
* Add support for touch in the UI, so the PC and Android ports can use touch devices if available for the UI, not just on the simulated keyboard.
* Attempt an HP Prime port of newRPL. Once newRPL supports touch and color and better screens, it's the logical next step to make it run on Prime G1 hardware (G2 hardware is out of question at the moment due to the need for hardware mods).
* Implement the long awaited INFORM replacement, so people can start creating full applications in newRPL.

It's a long road ahead, but I'm feeling optimistic this year. Stay tuned!