newRPL - build 1255 released! [updated to 1299]

[pier4r]

(01-06-2018 08:34 PM)Claudio L. Wrote:  I wish I had more manpower to move the project forward and at the same time keep up with the docs.

I agree with Barry, would be cool to clone you multiple times!

Anyway I tried to search in the newRPL code by myself, but I did not find precise parts were a command was defined.

I was assuming there was a filename.h with all the main commands or several filename.h with commands collected by topic, but I failed in seeing the pattern.

To fix this one has to find the main function and then follow from there, but I did not had (nor I have yet) the time to do it.

We could extract and put in the wiki the functionality of the commands if we there are clear pointers in the C code for those. I know you said that much may change, but I assume many commands would be stable for long time, aside from bug fixing.

[Gilles59]

(01-06-2018 08:59 PM)Claudio L. Wrote:  

(01-06-2018 07:28 PM)Gilles59 Wrote:  This one is very strange bug...
You must find 2849 solutions ( SIZE of the returned list).
Sometimes its OK, sometimes I get only 2848 solutions (I notice one time when it was wrong that the 176nth solution 127135473142018 was missing, but it seems its not always the same)

It seems one of the commands is having trouble with garbage collection, I need to review the code on each and every command your code uses inside the loop to see which one has the bug. If you add GARBAGE to the start of the loop (so the GC doesn't happen while other commands are executing) you'll see everything works. Now the bug hunt begins. As soon as I find it and squash it, you'll be the first to know.
Thanks for the report.

I suspect the ADD command... I noticed that if I just count the solutions there is no problem.

Thank you again for your great work with NewRPL. It s really impressive. Sometime with the simulator on a PC it 's quicker than Python !

The same program on a PC with the HPPrime simulator takes 228 secondes, 35 times slower

[Claudio L.]

(01-06-2018 08:52 PM)BarryMead Wrote:  I scanned through the list of commands in this document, and noticed that none of
the USB.... , or SD... commands are shown there, even though several are implemented.

They are all there, but new commands are added to the bottom, so don't expect the list to be sorted in any way.
Since you cloned the repository, just go to the newrpl/docs folder and open it with LibreOffice, you can use the auto filters in the columns to select only certain topics, or use the Implemented column, as all new commands have a "New" in that column.

[pier4r]

(01-06-2018 11:27 PM)Gilles59 Wrote:  Thank you again for your great work with NewRPL. It s really impressive. Sometime with the simulator on a PC it 's quicker than Python !

The same program on a PC with the HPPrime simulator takes 228 secondes, 35 times slower

woah, really? impressive! (the part vs HP prime.)

[BarryMead]

Claudio: I have a question. Why does the square root function return an "Approximate" value when the root is a whole number like 9 √ yelds 3. , but the
Xth root of Y function returns an "Exact" value? 9 2 XROOT yields 3 ? I would expect BOTH functions to return "Exact" 3 with these inputs, but they are inconsistent, why?

To make this puzzle more curious, the square root of 25 returns an "Exact" value 5 , with no decimal point. All other perfect integer squares between 1 and 12 return an "Approximate" value.
1 √ yelds 1.
4 √ yields 2.
9 √ yields 3.
16 √ yields 4.
25 √ yields 5 <-- Note: No Decimal point!
36 √ yields 6.
49 √ yields 7.
64 √ yields 8.
81 √ yields 9.
100 √ yields 10.
121 √ yields 11.
144 √ yields 12.
I confirmed that the XROOT function with the X value of 2 in all of these cases returns the "Exact" value as expected. 16 2 XROOT yields 4 for instance.

i also discovered that only powers of 5 squared will return an exact result if you take the square root of that squared number.
.5 SQ √ yields .5 exact
5 SQ √ yields 5 exact
50 SQ √ yields 50 exact
500 SQ √ yields 500 exact etc.

I realize that the "Exact" and "Approximate" distinction is small, but I think it is strange, and anomalous behavior never the less.

[Claudio L.]

(01-08-2018 05:37 AM)BarryMead Wrote:  Claudio: I have a question. Why does the square root function return an "Approximate" value when the root is a whole number like 9 √ yelds 3. , but the
Xth root of Y function returns an "Exact" value? 9 2 XROOT yields 3 ? I would expect BOTH functions to return "Exact" 3 with these inputs, but they are inconsistent, why?

To make this puzzle more curious, the square root of 25 returns an "Exact" value 5 , with no decimal point. All other perfect integer squares between 1 and 12 return an "Approximate" value.
1 √ yelds 1.
4 √ yields 2.
9 √ yields 3.
16 √ yields 4.
25 √ yields 5 <-- Note: No Decimal point!
36 √ yields 6.
49 √ yields 7.
64 √ yields 8.
81 √ yields 9.
100 √ yields 10.
121 √ yields 11.
144 √ yields 12.
I confirmed that the XROOT function with the X value of 2 in all of these cases returns the "Exact" value as expected. 16 2 XROOT yields 4 for instance.

i also discovered that only powers of 5 squared will return an exact result if you take the square root of that squared number.
.5 SQ √ yields .5 exact
5 SQ √ yields 5 exact
50 SQ √ yields 50 exact
500 SQ √ yields 500 exact etc.

I realize that the "Exact" and "Approximate" distinction is small, but I think it is strange, and anomalous behavior never the less.

It uses an approximated method, so they should all be approximated. But sometimes the numerical method might converge exactly to the value after some iterations. Since the iterations use divisions, any number that has factors of 2 and 5 can be represented exactly. I didn't check in detail every iteration, but if the method has all exact divisions for a certain number it's final result will be exact.

[BarryMead]

(01-09-2018 03:49 PM)Claudio L. Wrote:  It uses an approximated method, so they should all be approximated. But sometimes the numerical method might converge exactly to the value after some iterations. Since the iterations use divisions, any number that has factors of 2 and 5 can be represented exactly. I didn't check in detail every iteration, but if the method has all exact divisions for a certain number it's final result will be exact.

That explains the behavior of the square root function, but why does the XROOT function return better more accurate answers? If the square root function were implemented as a call to XROOT with the second parameter fixed at 2 it would behave as expected. I wrote my own SQRT function like this that works better than the built-in one.
« 2 XROOT » 'SQRT' STO

[Claudio L.]

(01-09-2018 04:27 PM)BarryMead Wrote:  That explains the behavior of the square root function, but why does the XROOT function return better more accurate answers? If the square root function were implemented as a call to XROOT with the second parameter fixed at 2 it would behave as expected. I wrote my own SQRT function like this that works better than the included one.
« DUP 2 XROOT » 'SQRT' STO

I had to look at the source code to answer this one! XROOT is an overloaded operator, and therefore each object type has its own implementation. In that context, each object type tries to preserve the type of the result.
Since both arguments were integer numbers, I included a trap that if the result (after rounding to the required precision) was actually an integer, an integer object type would be created and pushed to the stack, rather than a foreign object (real). It's a tiny performance penalty in a slow function like XROOT. As a side effect, results look better when you are working with integers.

There's an inconsistency, though. If you take an exact number that's not an integer, for example 0.36 2 XROOT will still produce 0.6. (approximated). The only way to check if the result is exact is by actually performing the operation 0.6^2 to see if it exactly matches the given argument. This is getting expensive so I'm not currently doing it (just for the luxury of getting the exact bit right).
I could add the same inconsistency to the square root, and test if the result is an integer, but I'm not sure it clarifies much.
If we had a faster CPU perhaps I wouldn't care much about speed and would certainly want that dot to be perfect each time.

EDIT: I'm open to ideas to implement this bit in a better way without doing expensive operations.

[BarryMead]

Claudio: Is there a command line option that allows one to automatically load an nrpb file (sqrt.nrpb for example) into the newRPL emulator when launching it? The real calculator preserves the
programs that you have "STO"ed into it, but the emulator always starts empty. All of the other desktop calculator emulators I have used save the state of the calculator in a "State", or "Memory" file
that gets reloaded at startup to simulate the continuous memory of a real calculator.

[Claudio L.]

(01-09-2018 06:50 PM)BarryMead Wrote:  Claudio: Is there a command line option that allows one to automatically load an nrpb file (sqrt.nrpb for example) into the newRPL emulator when launching it? The real calculator preserves the
programs that you have "STO"ed into it, but the emulator always starts empty. All of the other desktop calculator emulators I have used save the state of the calculator in a "State", or "Memory" file
that gets reloaded at startup to simulate the continuous memory of a real calculator.

Not yet, there's no "settings" being saved for the simulator. It's annoying I know, I need to research a way to do that in a platform-independent way.

[Claudio L.]

(01-09-2018 06:50 PM)BarryMead Wrote:  Claudio: Is there a command line option that allows one to automatically load an nrpb file (sqrt.nrpb for example) into the newRPL emulator when launching it? The real calculator preserves the
programs that you have "STO"ed into it, but the emulator always starts empty. All of the other desktop calculator emulators I have used save the state of the calculator in a "State", or "Memory" file
that gets reloaded at startup to simulate the continuous memory of a real calculator.

Barry, do a git pull and rebuild your simulator. I added persistence of the last file you opened, it needs more testing before I show it to the open public but you can get a head start since you do your own builds.
Let me know if you find any problems.

[BarryMead]

(01-13-2018 07:46 PM)Claudio L. Wrote:  Barry, do a git pull and rebuild your simulator. I added persistence of the last file you opened, it needs more testing before I show it to the open public but you can get a head start since you do your own builds.
Let me know if you find any problems.

Claudio: I compiled the new version (Release Build) and it does indeed preserve the state of loaded programs (Thank You)! I did notice one strange behavior in my Ubuntu Linux build, however. When you try to exit the program, it never actually shuts down the primary "newrpl-ui" program thread. It stays running and you have to kill it by typing Ctrl-C from the terminal where you ran the program, or use the kill command if you launch the program from a desktop icon. I don't think this is too much of an issue, but it is a little bit annoying. When the program is run from a terminal, after you try to exit the program the error message: "QThread: Destroyed while thread is still running" is displayed. I suspect this is a useful clue as to why the program will not terminate normally.

[Claudio L.]

(01-13-2018 08:53 PM)BarryMead Wrote:  

(01-13-2018 07:46 PM)Claudio L. Wrote:  Barry, do a git pull and rebuild your simulator. I added persistence of the last file you opened, it needs more testing before I show it to the open public but you can get a head start since you do your own builds.
Let me know if you find any problems.

Claudio: I compiled the new version (Release Build) and it does indeed preserve the state of loaded programs (Thank You)! I did notice one strange behavior in my Ubuntu Linux build, however. When you try to exit the program, it never actually shuts down the primary "newrpl-ui" program thread. It stays running and you have to kill it by typing Ctrl-C from the terminal where you ran the program, or use the kill command if you launch the program from a desktop icon. I don't think this is too much of an issue, but it is a little bit annoying. When the program is run from a terminal, after you try to exit the program the error message: "QThread: Destroyed while thread is still running" is displayed. I suspect this is a useful clue as to why the program will not terminate normally.

Thanks for the report. Indeed that's a new bug, after saving the state it restarts the simulator, and I should stop it again if the save is caused by the user closing the application.

[Claudio L.]

All 3 ROMs were updated in the unofficial channel on hpgcc3.org (see first post). We are now up to build 1027, which is mainly a bugfix release, but recommended for everyone.

* Fixes Gilles mysterious bug (in the POS command, where I least expected it)

The rest were improvements to the simulator, which is not being released yet but people building their own can easily update to this latest release.

* Adds persistence to the simulator: it saves the currently open file when exiting, and automatically opens the last file when starting.

PS: Barry, this version fixes an important bug with respect to the one I asked you to test last. Previously if you tried to close the simulator when the calculator wasn't idle (with a long running program), there was a race condition that wouldn't allow you to close the simulator until the RPL program ended, and it wouldn't allow to use On+A+C to stop the running program. Right now it stops the program cold, saves the file and exits immediately.

[BarryMead]

(01-17-2018 04:22 AM)Claudio L. Wrote:  PS: Barry, this version fixes an important bug with respect to the one I asked you to test last. Previously if you tried to close the simulator when the calculator wasn't idle (with a long running program), there was a race condition that wouldn't allow you to close the simulator until the RPL program ended, and it wouldn't allow to use On+A+C to stop the running program. Right now it stops the program cold, saves the file and exits immediately.

Thanks Claudio. I just compiled the latest simulator. Seems to work great! I love the persistence, it makes the simulator behave much more like the real calculator.

[BarryMead]

(01-17-2018 04:22 AM)Claudio L. Wrote:  All 3 ROMs were updated in the unofficial channel on hpgcc3.org (see first post). We are now up to build 1027, which is mainly a bugfix release, but recommended for everyone.

* Fixes Gilles mysterious bug (in the POS command, where I least expected it)

Claudio: I downloaded the HP-50G version 1027 of newrplfw.bin from the first post in this thread, and put it onto a 2G flashcard with the appropriate update.scp file and flashed it into my HP-50G. To my surprise, it did not work. The 50G got stuck in a strange prompt that says "Update Needed press 1 USB 2 Card"
The calculator would not even turn off without removing the battery. I put the older 1016 version of the newrplfw.bin on the flash card and it flashed the calculator back to full function. I thought you would like to know. Take Care, Barry

[compsystems]

Hello,

Idea:
so that third-party developers can for example create applications that "communicate" with the simulator, please Claudio can create a program similar to DDE48

http://hp.giesselink.com/Emu48/DDE48.ZIP

http://hp.giesselink.com/emu48.htm

Quote:Command line program to demonstrate the data transfer from and to Emu48 over DDE. It allows the data exchange between Stack Level 1 and a file. This program is especially made for developers which are using a customize editor and want to transfer the output file easily to Emu48 and for developers which are looking for a sample to add the interface into own applications. Source code included.

[Claudio L.]

(01-17-2018 07:05 AM)BarryMead Wrote:  

(01-17-2018 04:22 AM)Claudio L. Wrote:  All 3 ROMs were updated in the unofficial channel on hpgcc3.org (see first post). We are now up to build 1027, which is mainly a bugfix release, but recommended for everyone.

* Fixes Gilles mysterious bug (in the POS command, where I least expected it)

Claudio: I downloaded the HP-50G version 1027 of newrplfw.bin from the first post in this thread, and put it onto a 2G flashcard with the appropriate update.scp file and flashed it into my HP-50G. To my surprise, it did not work. The 50G got stuck in a strange prompt that says "Update Needed press 1 USB 2 Card"
The calculator would not even turn off without removing the battery. I put the older 1016 version of the newrplfw.bin on the flash card and it flashed the calculator back to full function. I thought you would like to know. Take Care, Barry

Ouch, sorry about that. I built them using a different machine where I had been doing some experiments to flash the firmware through the simulator in the future. I forgot to remove an experimental thing that messed up the ROMs. It's fixed, build #1029 can be downloaded now (this didn't affect the simulator).

[Claudio L.]

(01-17-2018 04:25 PM)compsystems Wrote:  Idea:
so that third-party developers can for example create applications that "communicate" with the simulator, please Claudio can create a program similar to DDE48

Well, DDE is Windows only, so it would ruin the portability of the newRPL Desktop application. DDE is also very old and probably obsolete, maybe a TCP or UDP socket would be more adequate nowadays. It's far reaching but not a bad idea. Won't be implemented any time soon, though.

[tcab]

(12-23-2017 10:16 AM)pier4r Wrote:  

(12-23-2017 06:49 AM)BarryMead Wrote:  I have a question about the "Desktop" windows version of newRPL. I downloaded the 1001 version and installed it on my Windows 7 partition, and it does indeed come up on the screen. I can type some numbers on the numpad and Enter, and operators like * + - /, but when I try to use the mouse to click on the graphical representation of the HP-50G keyboard next to the display window nothing happens.

As far as I remember, they should not "click". I use the real pc keyboard (of which the mapping is not yet well documented but it is ok).

In practice you have the commands reachable by letter (for example pressing 'y' is like pressing '1/x' unless alpha is activated and then 'y' shows) Then you have the numbers that are like 1,2,3,4,5,6,7,8,9,0 on the keyboard. The dot is dot. Space is space. Enter is enter. *,-,+ should be equal on the keyboard (I do not remember correctly) while division is 'z'.

alpha, right and left shift should be shift, ctrl, tab or a combination of those.

Unfortunately the newrpl desktop version now does not run anymore on XP so I cannot test on my thinclient and I am lazy to open win10pro.

I tried running the PC simulator and also found that the image of the HP50G keyboard seems to be a non functional decoration. The only keys that initially seemed to work were 0-9 and *+-/ ENTER. Since I cannot find any documentation on how to use the emulator, and can't find a wiki, (not referred to on http://hpgcc3.org/projects/newrpl), I experimented and here is what I found.

O enters ''
TAB enters alpha mode
CAPSLOCK left shift
CTRL right shift
S SIN() and CAPLOCK S GIVES ASIN()
DELETE drops 1

After that it gets confusing. hitting 'd' key emits 'a', hitting 'f' makes some menu change, but I don't know how to select from that menu. 'q' key emits '^' the 'w' emits + or - alternately (its different every time). 'r' emit square root, 't' emits '()'. 'Y' emits INV and 'u' emits TAN().'p' and 'd' make a menu appear but again, not sure how to select operations.

How do I enter << and { and [ ?
Can I enter programs and edit them in the PC simulator? Is there a simple example/tutorial for doing this?
What is the PC simulator for newRPL meant for - can I use it like a 50G with all the features or just for some limited features, or just running RPL?