newRPL: Alpha demo 0.9 released [UPDATED 2017-10-25]

[Claudio L.]

(10-10-2017 10:20 AM)brickviking Wrote:  

(09-23-2017 12:27 AM)Claudio L. Wrote:  That's strange. I created the installer using the open source Excelsior installer, and tested it before uploading. It created a desktop icon, and inside the menu group there's the uninstaller and the actual program. I'm also using Windows 10 on this machine. Perhaps uninstall and try again?
If not then I'll have to perhaps start using a different installer creator software.

I struck the same issue as Eric did, that I merely have the uninstaller in the newRPL Start directory. The behaviour seems to be the same on a Vista-Home Premium SP2 too (simply doesn't create the desktop icon, nor put the executable into the Start->newRPL directory alongside the uninstaller), although thankfully the group doesn't get removed after first view, like some instances of Win10. Perhaps yet another reason to stay away from Win10.

Here are the steps I did to reproduce the problem:

Start installer. When asked, feed it with a path to install to: here, that's E:\newRPL Desktop. When asked for program group, provide this: HP-Emulators\newRPL Desktop 0.9aAlpha. The rest of the steps are (relatively) obvious.

For the current documentation, I'd also like to suggest a wiki link in the first post, as I missed the link until further down the thread. The first post would be a fantastic place to have this information alongside the links you've already provided, as the wiki provides several very important pieces of information such as the revamped menu interface (which I have a bug I want to post against that, or a misunderstanding). I'll post my thoughts on that menu thing tomorrow, as it's fantastically late here where I am at the moment.

Now, onto the desktop application you've helpfully provided. It's a great way of testing it all out without blowing a running HP50G's setup away, but I got stuck by one small issue. I needed to install a version of QT, as the version you released wouldn't work on my system without me running windeployqt.exe from my QT install. All that got installed on my system were: libgcc_s_dw2-1.dll, libstdc++-6.dll, libwinpthread-1.dll, QT5Core.dll, QT5GUI.dll and QT5Widgets.dll, newrpl-ui.exe, Uninstall.exe and platforms\qwindows.dll. When I tried executing newrpl-ui.exe, Windows barfed up and said this:

This application failed to start because it could not find or load the Qt platform plugin "windows" in "". Reinstalling the application may fix this problem.

I'm slowly getting used to newRPL, I don't feel confident enough to spring for another HP50G, but experimenting with it on the desktop feels "right" for me. Good luck, I can see this going a long way.

Cheers, brickviking (a.k.a. DrSmokey)

(Post 115)

Thanks for your input. It seems I need to do a few things:
a) Try a new installer creator completely.
b) Research what are those Qt plugins (??), in the 2 machines I tested it the installation failed to create the icons but the program ran fine with the installed DLLs (one machine had Qt installed, the other one didn't). I suspect the file platform/qwindows.dll is the file it couldn't find on your machine, but I have no idea what needs to be done for the application to find it.
c) Add a link to the wiki per your suggestion.

[brickviking]

(10-10-2017 12:58 PM)Claudio L. Wrote:  

(10-10-2017 08:58 PM)brickviking Wrote:  All that got installed on my system were: libgcc_s_dw2-1.dll (no version), libstdc++-6.dll (no version), libwinpthread-1.dll (1.0.0.0), QT5Core.dll (5.8.0.0), QT5GUI.dll (5.8.0.0) and QT5Widgets.dll (5.8.0.0), newrpl-ui.exe, Uninstall.exe and platforms\qwindows.dll (5.8.0.0).

Thanks for your input. It seems I need to do a few things:
b) Research what are those Qt plugins (??), in the 2 machines I tested it the installation failed to create the icons but the program ran fine with the installed DLLs (one machine had Qt installed, the other one didn't). I suspect the file platform/qwindows.dll is the file it couldn't find on your machine, but I have no idea what needs to be done for the application to find it.

I've stuck the versions I found into my post after about the ninth edit. Sorry about that, your post and my last edit crossed paths, it would seem. Do you want my install.log file? And I installed on 32-bit Vista.

(Post 116)

[The Shadow]

Found an issue with local variable assignments via the arrow. If you do:

<< 1 2 3 -> a b c << >> >>

It treats the a as 'a', but it just calls the variables for b and c. This is no problem in a standalone program, but if you call this routine from another that has assigned b or c, you get an error.

You can get around this with HIDELOCALS, but I don't think that should be necessary in this case. Or if it is, I don't see why a and b should be treated differently.

[Claudio L.]

(10-17-2017 06:23 PM)The Shadow Wrote:  Found an issue with local variable assignments via the arrow. If you do:

<< 1 2 3 -> a b c << >> >>

It treats the a as 'a', but it just calls the variables for b and c. This is no problem in a standalone program, but if you call this routine from another that has assigned b or c, you get an error.

You can get around this with HIDELOCALS, but I don't think that should be necessary in this case. Or if it is, I don't see why a and b should be treated differently.

Excellent catch! I need to see why it stops at the first variable when adding quotes, all of them are supposed to be 'quoted' during compilation. Will be fixed ASAP.
EDIT: Found it and fixed it.

By the way, for all the followers, I've gone quiet recently because things are cooking in newRPL. A lot of the matrix commands were implemented in the past couple of weeks, I also added the first numeric solver (PROOT, using Laguerre's method) and works great. The idea is to finish all the commands in the matrix module, that's a lot of algorithms that need to be implemented, some of them not-so-trivial so it's taking quite a bit of time.
On another subject, that means the number of implemented commands finally reached 50%!!! It's been a long road to get to 50%, and once the matrix module and numeric solvers are complete, most of the math power will be ready to use, as the vast majority of the commands yet to be implemented are UI related, plotting, etc. (which is a big topic, I admit).

[The Shadow]

Congrats on all the progress, Claudio! I'm really looking forward to the matrix commands. (Will you implement the Hermite and Smith normal forms at this time, or is that for later?)

Where does the forms engine fit in this roadmap? You've mentioned adding bits and pieces of it for some time.

Is there a new version added with the local variable arrow fix?

[The Shadow]

Found another bug. If you take the FLOOR of any number between -1 and 0, you get 1 instead of -1.

[Claudio L.]

(10-20-2017 09:35 AM)The Shadow Wrote:  Congrats on all the progress, Claudio! I'm really looking forward to the matrix commands. (Will you implement the Hermite and Smith normal forms at this time, or is that for later?)

Where does the forms engine fit in this roadmap? You've mentioned adding bits and pieces of it for some time.

Is there a new version added with the local variable arrow fix?

Not yet, since I was in the middle of the polynomial solver and didn't want to publish a half-working ROM. I'll push an update in a couple of days more.
Regarding the forms engine... I started but I'm not fully convinced that what I wanted to implement was the best idea, so I put it in the freezer while I rethink the whole concept. In the meanwhile I want to make progress in the numerical area, since I need it for work, more than the forms.

(10-20-2017 01:03 PM)The Shadow Wrote:  Found another bug. If you take the FLOOR of any number between -1 and 0, you get 1 instead of -1.

Fixed. Thank you!

[Gilles59]

I get a 'new' 500Mb SDCard.
NewRPL installed on a 50g. I will begin some tests ;D

[Gilles59]

While exploring the A028819 sequence https://oeis.org/A028819 I notice a different behavior between UserRPL and NewRPL about parallel processing with test.

This program shows if a number ( > 3) is part of the A028819 serie :

Code:

<< SQ ->STR UTF8-> ΔLIST 0 ≥  >>

It works fine (and quickly !) but in a different way than UserRPL :

{ 1 6 4 } 5 > returns { 0. 1. 0. } in UserRPL and 0 in newRPL
{ 7 8 9 } 5 > returns { 1. 1. 1. } in UserRPL and 1 in NewRPL

Is this by design or an anomaly ?

[Claudio L.]

(10-22-2017 08:41 AM)Gilles59 Wrote:  While exploring the A028819 sequence https://oeis.org/A028819 I notice a different behavior between UserRPL and NewRPL about parallel processing with test.

This program shows if a number ( > 3) is part of the A028819 serie :

Code:

<< SQ ->STR UTF8-> ΔLIST 0 ≥  >>

It works fine (and quickly !) but in a different way than UserRPL :

{ 1 6 4 } 5 > returns { 0. 1. 0. } in UserRPL and 0 in newRPL
{ 7 8 9 } 5 > returns { 1. 1. 1. } in UserRPL and 1 in NewRPL

Is this by design or an anomaly ?

This is a regression, unintendedly broken by the implementation of the new ISTRUE operator. Some special operators must return true or false, even for lists (only the SAME and ISTRUE operators will behave this way), but all the others weren't supposed to change!
I'll fix this ASAP. EDIT: Fixed, I'll see if I can push a new ROM out tomorrow. Thanks for the report!

[Gilles59]

I'm little lost with displaying and formating options.
What is the list of arguments to restore the default behavior with SETNFMT ?

[okkama]

Hello. Thank you for this powerful environment. When will the usb driver support appear? This is especially important for 39&40(save/load programs/data list).

[Claudio L.]

(10-23-2017 07:12 PM)Gilles59 Wrote:  I'm little lost with displaying and formating options.
What is the list of arguments to restore the default behavior with SETNFMT ?

Here it is:

Code:


{ 
"#.12#."
1E-12 "#.12#.E*"
1E12  "#.12#.E*"
}

In human words:
"normal size" numbers are displayed with 12 decimal figures (so they look the same as a stock 50g, even though the precision is 32 digits by default).
Numbers smaller than 1E-12 are displayed with 12 figures, but in SCI mode.
Numbers larger than 1E12 also use the same SCI mode with 12 digits.

The wiki explains every single detail, but it's a little hard to read, could use a few more examples.

(10-23-2017 07:28 PM)okkama Wrote:  Hello. Thank you for this powerful environment. When will the usb driver support appear? This is especially important for 39&40(save/load programs/data list).

I know, it's essential on those machines. What I did so far is to find a raw HID USB library originally developed for the Teensy board project which I can try to port (it's for a completely different CPU, but the USB interaction logic is good). The library is self-contained, single file and BSD licensed, so it fits newRPL very well.
Unfortunately I haven't done much more than stare at the source code wondering where to start the surgery.
I can't give you any specific date, since USB drivers require me to have the physical calculator connected to a computer, and that doesn't fit my "code whenever I can on whatever device falls in my hands" style, but I can tell you it's in the pipeline and I'm well aware that's the only connection to the world for the 39 and 40, and will also be the only connection in a future port to the Prime, so it's very important to get it working.

[Gilles59]

(10-24-2017 03:08 AM)Claudio L. Wrote:  

(10-23-2017 07:12 PM)Gilles59 Wrote:  I'm little lost with displaying and formating options.
(...)

(...)
The wiki explains every single detail, but it's a little hard to read, could use a few more examples.

I agree about the interest of more examples. An example is sometimes more undesrtable that lot of words ;D

I also noticed that :

PI ( LS SPC ) NUM-> return "Undefined variable"
Stock HP50G returns 3.14....

[The Shadow]

(10-24-2017 04:57 PM)Gilles59 Wrote:  PI ( LS SPC ) NUM-> return "Undefined variable"
Stock HP50G returns 3.14....

At present, pi is implemented as a command pi0. (Greek letter pi followed by zero.) My understanding is that this will change at some point.

[Gilles59]

Difference between UserRPL an NewRPL :

In UserRPL :
1 { 2 2 + } IFT
returns 4

In NewRPL
1 {2 2 + } IFT
returns {2 2 +}

I guess its because UserRPL eval the list with IFT (wich doesnt seem very logic in fact...).

[Claudio L.]

(10-24-2017 05:57 PM)The Shadow Wrote:  

(10-24-2017 04:57 PM)Gilles59 Wrote:  PI ( LS SPC ) NUM-> return "Undefined variable"
Stock HP50G returns 3.14....

At present, pi is implemented as a command pi0. (Greek letter pi followed by zero.) My understanding is that this will change at some point.

Constants are not implemented yet (complex i, pi, e, and a few others). The implemented pi0 is not a constant, in the sense that it cannot be used in a symbolic expression. It's a command (temporary), which returns pi with twice the system precision.

(10-24-2017 11:38 PM)Gilles59 Wrote:  Difference between UserRPL an NewRPL :

In UserRPL :
1 { 2 2 + } IFT
returns 4

In NewRPL
1 {2 2 + } IFT
returns {2 2 +}

I guess its because UserRPL eval the list with IFT (wich doesnt seem very logic in fact...).

This is indeed a difference between newRPL and userRPL, and is deliberate. userRPL only has EVAL, so it does just that, but it has the bad habit of executing lists as programs. I don't agree with that, I think if you put a list on the stack is because you want to return a list, otherwise you would've put a program.
newRPL has 3 different evaluation functions: XEQ, EVAL and EVAL1. EVAL is for the most part identical to userRPL. EVAL does evaluation, and for lists it only makes sense to EVAL each element of the list (like all other operators, it is passed straight to the elements in the list). The behavior of executing the list as a program always seemed out of place to me.
EVAL1 is similar to EVAL but doesn't recurse the evaluation of symbolics. It only evaluates one level, allowing recursion formulas to work:

'X+1' 'X' STO

Then doing 'X' EVAL1 will return 'X+1', another EVAL1 will become 'X+2', etc. In this case, EVAL would complain of circular reference.

Finally, XEQ is short for execute. For most objects, XEQting them means they just push themselves to the stack. Programs of course get executed (this is the main purpose of XEQ) but other objects like lists and symbolics are left untouched.
As you may have guessed, IFT doesn't do EVAL but XEQ in newRPL, so a program will get executed, but lists/symbolics remain as they are in the stack.
Depending on what you are doing, you may need to add an EVAL after IFT if you are porting code from userRPL.
For example:

'X+1' 'X<4' 'X*2' 'X^2' IFTE +

On userRPL, IFTE would EVAL 'X*2' or 'X^2', so if X is 3, it would return 'X+1+6'.
On newRPL, IFTE would do ISTRUE('X<4') and then XEQ('X*2') so in the same case it would return 'X+1+X*2'. It's not better or worse, just different.

[Gilles59]

Thank You Claudio for those detailled explanations. It makes sense

[Gilles59]

Hi Claudio, did you think about the possibilty to introduce EXIT and BREAK instructions in NewRPL?

[The Shadow]

The one benefit of lists being evaluated as programs was that such programs were easy to alter on the fly. However, it certainly isn't hard to use strings to change programs to lists and vice versa, and I currently have a newRPL program that does just that. (Also one to change regular programs to immediate ones.)

Not having to constantly type << EVAL >> MAP, on the other hand, to say nothing of AXL << EVAL >> MAP AXL, may have saved me from carpal tunnel.