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

[The Shadow]

Okay, after quite a lot of programming and playing around, I have some more observations.

Most commands that take lists as input (ie, PURGE, LOCKVAR, etc.) leave an empty list on the stack after running. This probably has to do with the changes in how lists work - I'd recommend tweaking them to do a DROP at the end.

Likewise, if you EVAL a list from PATH, you get an empty list. Not sure how to fix this.

SDSTO and other commands that involve writing to the SD card fail most of the time. It isn't an issue with my card, as I can write to it on my oldRPL 50g and my computer with no trouble. The only partial pattern I've noted is that sometimes, when I have written to the card with another machine, then put it back in my newRPL 50g, it will work for a while. But not always.

A "SADD" command, that runs ADD on a variable and stores the result, is very useful - much more so than SINV or SCONJ. It's easy enough to code, but it might be worth building in. (You used to be able to do this with STO+, but obviously not any more.)

The command line has some quirks compared to the old 50g. You used to be able, for example, to type 1GET, without a space, and it would work. Now it puts 1 and GET on the stack.

Likewise, the program editor seems really persnickety about spaces at times, particularly if a space doesn't get left between commands and the delimiters.

All of that said, this is the first version of newRPL that I can really sink my teeth into. Great work!

[Claudio L.]

(08-18-2017 09:37 PM)The Shadow Wrote:  Okay, after quite a lot of programming and playing around, I have some more observations.

Most commands that take lists as input (ie, PURGE, LOCKVAR, etc.) leave an empty list on the stack after running. This probably has to do with the changes in how lists work - I'd recommend tweaking them to do a DROP at the end.

Likewise, if you EVAL a list from PATH, you get an empty list. Not sure how to fix this.

Self inflicted damage... this is a regression. These commands used to rely on EVAL to get rid of the empty list. But at some point I decided that EVAL should work element wise rather than explode the list for consistency, and I forgot about all other commands that rely on this behavior. It's a simple fix, I'll put it in the bug tracker.

(08-18-2017 09:37 PM)The Shadow Wrote:  SDSTO and other commands that involve writing to the SD card fail most of the time. It isn't an issue with my card, as I can write to it on my oldRPL 50g and my computer with no trouble. The only partial pattern I've noted is that sometimes, when I have written to the card with another machine, then put it back in my newRPL 50g, it will work for a while. But not always.

That's very strange, it works very well on both my calculators, with all the SD cards I could find here to test (4 of them). Would be nice to have your card to see what the problem is.

(08-18-2017 09:37 PM)The Shadow Wrote:  A "SADD" command, that runs ADD on a variable and stores the result, is very useful - much more so than SINV or SCONJ. It's easy enough to code, but it might be worth building in. (You used to be able to do this with STO+, but obviously not any more.)

Makes sense, perhaps should be STOADD for consistency with STO+, and to avoid the confusion with SREPL and other "S" commands.

(08-18-2017 09:37 PM)The Shadow Wrote:  The command line has some quirks compared to the old 50g. You used to be able, for example, to type 1GET, without a space, and it would work. Now it puts 1 and GET on the stack.

Likewise, the program editor seems really persnickety about spaces at times, particularly if a space doesn't get left between commands and the delimiters.

newRPL spaces are mandatory, save a few cases. Number+ident is accepted, can't recall exactly why this was necessary.
Some of the brackets also accept the lack of space but not all, I need to double check and make it consistent.

(08-18-2017 09:37 PM)The Shadow Wrote:  All of that said, this is the first version of newRPL that I can really sink my teeth into. Great work!

Sink your teeth in this: I just uploaded a version that fixes ->Q, and also implements SDARCHIVE/SDRESTORE. Just provide a file name and will store everything, including the stack.

[The Shadow]

(08-18-2017 10:41 PM)Claudio L. Wrote:  But at some point I decided that EVAL should work element wise rather than explode the list for consistency, and I forgot about all other commands that rely on this behavior. It's a simple fix, I'll put it in the bug tracker.

That's what I figured.

Quote:That's very strange, it works very well on both my calculators, with all the SD cards I could find here to test (4 of them). Would be nice to have your card to see what the problem is.

I was afraid you'd say that. I'll try with my other SD card.

Quote:Makes sense, perhaps should be STOADD for consistency with STO+, and to avoid the confusion with SREPL and other "S" commands.

Makes sense, but then you have to decide whether to keep SINV and SCONJ for legacy purposes, or change them to STOINV and STOCONJ for consistency.

I was going to say I doubt anyone uses them, but now that I'm getting used to programming with local variables, I can actually see myself using SCONJ a fair bit.

Quote: Sink your teeth in this: I just uploaded a version that fixes ->Q, and also implements SDARCHIVE/SDRESTORE. Just provide a file name and will store everything, including the stack.

Oh wow! Right when I've written enough programs to make it worth it, too! In fact, I was just in the midst of coding a quick way to save a directory on the card so I won't lose my work - guess I won't need it!

I'm curious what the problem was with ->Q?

Also, you'll be pleased to hear this - I coded a quick and dirty brute-force algorithm to factor numbers, no optimization at all, and have been using it to make lists of divisors... And it's regularly faster than the built-in oldRPL DIVIS command, sometimes stunningly so, even though it takes the time to sort the list while DIVIS doesn't!

[The Shadow]

Claudio,

Did you see the bug in SETNFMT I mentioned last page?

Also, I downloaded the file and installed it on my 50g, but ->Q is still broken and there are no new SD commands. The file was modified today, though, so perhaps you uploaded the wrong one by accident?

[Claudio L.]

(08-18-2017 03:47 AM)The Shadow Wrote:  I found another bug, in SETNFMT this time.

I set my number format to "#.A#", then tried to change it back to this:

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

But when I do SETNFMT, the third item doesn't change, it remains "#.A#".

In order to change it properly, I first have to do: "#.12#S.E*" SETNFMT then the list above and SETNFMT.

I can't reproduce this. I did copy/paste of your list above, STR-> and SETNFMT and it worked well. GETNFMT shows the third item changed to the correct string on all 3 parts.
I also looked at the code and didn't find anything that could explain what you saw.
Perhaps the numbers were both 1E-12?
Please test again and report back, I need more info to catch this bug (if it's there).

(08-19-2017 01:47 AM)The Shadow Wrote:  I'm curious what the problem was with ->Q?

The algorithm uses numerator and denominator < 2^63 (integers), and there was an overflow that was improperly detected (some rare cases failed to detect overflow). This was the case with pi0 0 +, that overflow was throwing the fraction off.

(08-19-2017 02:16 AM)The Shadow Wrote:  Claudio,

Did you see the bug in SETNFMT I mentioned last page?

I did now.

(08-19-2017 02:16 AM)The Shadow Wrote:  Also, I downloaded the file and installed it on my 50g, but ->Q is still broken and there are no new SD commands. The file was modified today, though, so perhaps you uploaded the wrong one by accident?

I just SSH'd to the server and the 3 files are correct. Perhaps there's caching going on somewhere between you and the server? Also, my browser renames the new downloaded files to "newrplfw (1).bin" if there's an existing file with that name. Perhaps it did that to you? Running VERSION should be build 879, and typing SDARCHIVE or SDRESTORE should show them in autocomplete, they should also be visible on the SD Card menu.

[Claudio L.]

(08-17-2017 09:26 PM)Gilles59 Wrote:  Hi Claudio,

[With the PC application how to do to enter text ?
I can use the keyboard to enter numbers and use the shifted functions but i'm unable to activate the ALPHA key ].
EDIT : OK !! I miss the TAB key to toggle ALPHA mode

Neither I can use the mouse on the virtual keyboard.

EDIT 2 : woo ! I do some tests : It's great !! I will install this on a 50g tomorrow...

Gilles

Glad you like it. Sorry the simulator isn't better documented. We'll add a section to the wiki showing how the keys are mapped.
Also, the on-screen keyboard is just a visual aid, doesn't really work as a keyboard (at least for now). It's mainly for me to remember that I need to press N for EVAL, or that the numeral # is at the number 3, but nothing more.

[Gilles59]

Thanks for your reply.
How to exit "interactive stack" with the PC simulator ? What is the key for "ON" ?

[The Shadow]

Finally got the new files, and they're lovely! And I think I've figured out what's wrong with the SD commands - I think the contacts in my ancient 50g are starting to go.

I noticed that KEYEVAL made it in at some point. Is there any way to make it ignore user-assigned keys? It used to be that one would just use a negative number, but that doesn't work with the current key codes.

[Gilles59]

Do we need a SD card of _exactly_ 2Gb to install newrpl ? I try with a old 128Mb SD card in FAT16 but i get a SD card error message.
By the way, i can access the files on the 50G using th FILES menu

I follow the instruction here :
https://newrpl.wiki.hpgcc3.org/doku.php?...stallation

[Claudio L.]

(08-19-2017 10:08 AM)Gilles59 Wrote:  Do we need a SD card of _exactly_ 2Gb to install newrpl ? I try with a old 128Mb SD card in FAT16 but i get a SD card error message.
By the way, i can access the files on the 50G using th FILES menu

I follow the instruction here :
https://newrpl.wiki.hpgcc3.org/doku.php?...stallation

I use an old 128 MB card too. The flashing is done by the bootloader, not by newRPL so there's no difference with a stock calculator. Any SD card should work in theory.
Make sure there's no issue with the file name you chose for the file, it has to be an 8.3 name as the bootloader doesn't work with long names.

[Claudio L.]

(08-19-2017 09:17 AM)Gilles59 Wrote:  Thanks for your reply.
How to exit "interactive stack" with the PC simulator ? What is the key for "ON" ?

It's the ESC key. I did notice that sometimes on Windows for some reason the ESC key stops working. I still haven't figured out which widget is stealing the key press. When it happens you just restart the application (the only workaround for now).
I haven't noticed this on Linux, where ESC works consistently.

[pier4r]

(08-19-2017 01:39 PM)Claudio L. Wrote:  It's the ESC key. I did notice that sometimes on Windows for some reason the ESC key stops working.

I "throw" a suggestion: maybe using something like ctrl+esc ? That would be less likely to be captured.

[Claudio L.]

(08-19-2017 09:26 AM)The Shadow Wrote:  Finally got the new files, and they're lovely! And I think I've figured out what's wrong with the SD commands - I think the contacts in my ancient 50g are starting to go.

I noticed that KEYEVAL made it in at some point. Is there any way to make it ignore user-assigned keys? It used to be that one would just use a negative number, but that doesn't work with the current key codes.

Also check your batteries. One of my cards starts giving read errors when the batteries are low (when the battery icon just flashes briefly) , apparently is current hungry.

Regarding KEYEVAL, it works very differently than in classic RPL. It doesn't EVAL the object but simulates the key press. For this reason the only way to disable custom keys is to temporarily set flag -4 (FL_NOCUSTOMKEYS if you look at the sources), call KEYEVAL, then restore the original flag.

[The Shadow]

(08-19-2017 02:07 PM)Claudio L. Wrote:  Regarding KEYEVAL, it works very differently than in classic RPL. It doesn't EVAL the object but simulates the key press. For this reason the only way to disable custom keys is to temporarily set flag -4 (FL_NOCUSTOMKEYS if you look at the sources), call KEYEVAL, then restore the original flag.

Gotcha. The wiki could use a list of flags.

I've been playing around with continued fractions, and I'm curious what algorithm you're using for ->Q. It's really fast, but also seems to be 'overshooting' in terms of precision - the last six to ten terms or so of the continued fractions of irrational numbers are consistently gobbledegook.

I've coded a version of ->Q that stops when it gets beyond the set precision, but it's 6 times slower than the built-in version.

[Claudio L.]

(08-19-2017 02:00 PM)pier4r Wrote:  I "throw" a suggestion: maybe using something like ctrl+esc ? That would be less likely to be captured.

I'll probably add a second key to do On, but Crtl-ESC is a really bad choice (sorry), as it's a reserved OS key in Windows, you can't capture that. Perhaps HOME, or INSERT are good candidates. I like ESC because it comes natural to want to exit something pressing ESC.

[pier4r]

(08-19-2017 06:41 PM)Claudio L. Wrote:  OS key in Windows

Uh, I did not know that. Time for google. Thanks for the hint.

[Claudio L.]

(08-19-2017 05:36 PM)The Shadow Wrote:  

(08-19-2017 02:07 PM)Claudio L. Wrote:  Regarding KEYEVAL, it works very differently than in classic RPL. It doesn't EVAL the object but simulates the key press. For this reason the only way to disable custom keys is to temporarily set flag -4 (FL_NOCUSTOMKEYS if you look at the sources), call KEYEVAL, then restore the original flag.

Gotcha. The wiki could use a list of flags.

I've been playing around with continued fractions, and I'm curious what algorithm you're using for ->Q. It's really fast, but also seems to be 'overshooting' in terms of precision - the last six to ten terms or so of the continued fractions of irrational numbers are consistently gobbledegook.

I've coded a version of ->Q that stops when it gets beyond the set precision, but it's 6 times slower than the built-in version.

I don't understand what you mean by "overshooting". ->Q will use signed 64-bit integers for the numerator and denominator to approximate the number as good as possible. The limited precision will show when you try to convert small numbers (smaller than 1E-18), since the smallest fraction that can be represented is 1/max_denom = 2^-63.
More precision doesn't make much sense: if you need more than 18 digits to represent the denominator, you are probably better off working with the real number. Too much precision will hurt the algorithm when trying to find simple fractions

[The Shadow]

(08-19-2017 06:58 PM)Claudio L. Wrote:  

(08-19-2017 05:36 PM)The Shadow Wrote:  I've been playing around with continued fractions, and I'm curious what algorithm you're using for ->Q. It's really fast, but also seems to be 'overshooting' in terms of precision - the last six to ten terms or so of the continued fractions of irrational numbers are consistently gobbledegook.

I've coded a version of ->Q that stops when it gets beyond the set precision, but it's 6 times slower than the built-in version.

I don't understand what you mean by "overshooting". ->Q will use signed 64-bit integers for the numerator and denominator to approximate the number as good as possible. The limited precision will show when you try to convert small numbers (smaller than 1E-18), since the smallest fraction that can be represented is 1/max_denom = 2^-63.
More precision doesn't make much sense: if you need more than 18 digits to represent the denominator, you are probably better off working with the real number. Too much precision will hurt the algorithm when trying to find simple fractions

I can see I'm explaining myself badly. Perhaps an example would illustrate what I mean better:

When I run ->Q on the golden ratio, I get (leaving out a lot of digits for brevity):

'1.349E19/8.335E18'

When I run my version on the golden ratio, I get:

'5.528E15/3.416E15'

It turns out those two values are equally precise, but yours has much higher values for the numerator and denominator - hence it is not an actual convergent, which translates into extraneous digits in the continued fraction.

When I expand those two answers into continued fractions, mine consists of 76 1's, just as it should. Yours is 84 entries long, and ends in { 2 5 1 2 1 1 5 1 3 2 }.

Nor is the golden ratio an isolated case. I get similar results with every number I've tried so far; it's just easier to check the golden ratio because it has such a simple expansion.

(I should add that it would in principle be possible to get even smaller numerators and denominators at the expense of the continued fraction expansion by walking the Stern-Brocot tree. But that would likely be slow, and for some unfortunate cases VERY slow.)

[The Shadow]

In the process of messing with continued fractions, I've also discovered a bug in IDIV2. Apologies for the long numbers, this is the only case I've found thus far.

4552566248534562374

5410247448489135735

IDIV2 yields:

1

-3073682928196717772

I'm guessing the issue is that the sum of those two numbers exceeds 2^63.

EDIT:

On a completely unrelated topic, I was wondering if there is any way for a user-defined menu to insert more than one command into the editor as a typing aid?

[Claudio L.]

(08-19-2017 09:10 PM)The Shadow Wrote:  When I run ->Q on the golden ratio, I get (leaving out a lot of digits for brevity):

'1.349E19/8.335E18'

When I run my version on the golden ratio, I get:

'5.528E15/3.416E15'

It turns out those two values are equally precise, but yours has much higher values for the numerator and denominator - hence it is not an actual convergent, which translates into extraneous digits in the continued fraction.

I see. ->Q uses a simple algorithm of invert and take the fractional part. When the algorithm in ->Q doesn't find a good fraction, it keeps going with higher denominators until is reaches 2^63 limit, then exit with whatever fraction was working on at the moment. By your account, I think we could've ended the search a couple of steps earlier, when the fraction already represented the number exactly at the given precision. I'll investigate why it keeps going (that's what you meant by "overshooting"!! now I get it).

BTW, I fixed the overflow issue in IDIV2 (also affected IQUOT and MOD), will come out in the next update. Thanks for the report! (keep them coming).