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

[Gilles59]

(08-19-2017 01:31 PM)Claudio L. Wrote:  

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

It's curious but my 128Mo SD card is OK for my HP50G and 49g+ but the flashing is impossible. I reformat the card on the HP with ON-F4 menu but with this the card is formated in FAT32 and it seems that the bootloader needs FAT16. Dont work again for the flashing. I format the SD with my W10 PC in FAT (no FAT16 option in W10 but I guess that FAT is FAT16 ?), the SD is well recognise (Read/Write with the HP50) but unable to flash again! The card is not recognise with the bootloader.
I tried also to format in FAT16 with SDFormatter : same bad result with the bootloader. It's not a problem of NewRPL. I get the same failure with the HP Official ROM. I never used a SD Card in the past to upgrade HP50/49 ROM but the USB connexion. I dont undertand what happen. I will try later with another small SD Card.

[Francois Lanciault]

Hi,

I have just upgraded to the latest firmware. First time since the new floating point algorithms. As I knew this particular upgrade would erase my memory I saved all programs with SDSTO first.

After the upgrade I was able to restore all programs without problems except one that did not recompiled correctly. I should have converted the programs to strings before saving to the SD card but I did not...

I appreciate the boosted performance in floating point function! I will now take more time to explore the latest additions.

Good job and thank you!

Francois

[Claudio L.]

(08-19-2017 09:24 PM)The Shadow Wrote:  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?

Not yet, it's been on the bug tracker for quite some time, always delayed to favor other things that take priority, but rest assured there will be a command to insert text directly into the command line.

[Claudio L.]

(08-20-2017 01:24 PM)Gilles59 Wrote:  I tried also to format in FAT16 with SDFormatter : same bad result with the bootloader. It's not a problem of NewRPL. I get the same failure with the HP Official ROM. I never used a SD Card in the past to upgrade HP50/49 ROM but the USB connexion. I dont undertand what happen. I will try later with another small SD Card.

The bootloader has a different driver than the actual ROM, so the fact it works with the Filer doesn't guarantee the bootloader can talk to the card.
Back in the day SD cards didn't really follow the standard. Some wanted extra power, some had timings way off specs, some had proper support for misaligned read/writes and some had not, were locked to 512 byte sectors without giving any explanation why. It was a mess.
Later they simplified the standard (SD 2.0) locking the 512 bytes sector, and more manufacturers fell "in line" with the specs.
I'd recommend you look for 1 GB and 2 GB standard SD cards (newRPL will happily accept SDHC cards, but the bootloader won't). Why 1 GB? because by the time manufacturers began offering those larger cards, the standards compliance had already improved and most cards worked without problems. You'll still have to format it to FAT16 for the bootloader, and perhaps just use a 256 MB partition, but it should give you less problems.

BTW: You can still use USB to flash newRPL, I never tried but should work fine.

[pier4r]

(08-21-2017 02:52 AM)Claudio L. Wrote:  BTW: You can still use USB to flash newRPL, I never tried but should work fine.

I confirm it, with 0.8 worked fine (from HP 2.15 rom to newRPL 0.8). To upgrade (from 0.8 to 0.9) then you need the SD card as far as I know.

[Claudio L.]

(08-21-2017 06:00 AM)pier4r Wrote:  

(08-21-2017 02:52 AM)Claudio L. Wrote:  BTW: You can still use USB to flash newRPL, I never tried but should work fine.

I confirm it, with 0.8 worked fine (from HP 2.15 rom to newRPL 0.8). To upgrade (from 0.8 to 0.9) then you need the SD card as far as I know.

Any flashing procedure is the same, regardless of which ROM version you move from/to, so upgrading from 0.8 to 0.9 should work the same as going from stock to 0.8 (this involves only the bootloader, not the actual ROM being updated). I don't have the USB cable here to test it, but when you press + and - simultaneously to enter the bootloader, select option 1 for USB and I get the "BEGIN UPDATE" message, so it should work fine.

[pier4r]

So you mean even from 0.8 to 0.9 (or viceversa) via USB should work? I should test it. nice input.

[The Shadow]

(08-20-2017 03:22 AM)Claudio L. Wrote:  I see. ->Q uses a simple algorithm of invert and take the fractional part.

That's the traditional way to do it, but you can get a significant speed-up with no loss of accuracy by rounding instead. Instead of FP, you do:

<< DUP 0 RND - >>

Basically, this groups together strings of 1's, saving many iterations. (The continued fraction of the golden ratio becomes { 2 -3 3 -3 3 -3...} )

There are some rare cases where this will be a bit slower - sqrt(2) is an example - because they don't have any 1's. But I find that a more than acceptable trade-off.

Do be aware that you can end up with both numerator and denominator negative with this method, but that's easy to fix at the end.

-----------

After doing a LOT of programming, I have found some oddities about typing:

Alpha mode seems to disable custom keys. I can't think of any good reason why this should be true.

Entering quotes automatically switches to alpha mode. This is no doubt intended to help, but it catches me off-guard every single time.

When you hold down alpha to enter some letters, the calc will not recognize left or right shift. So for example, you can't type a -> without releasing alpha, which is quite annoying, especially since I frequently name programs with an arrow in the middle.

-----------

Thank you from the bottom of my heart for SDARCHIVE and SDRESTORE. They've already saved me a good deal of grief.

Can I throw in a request for VISIT? I love it to pieces.

[The Shadow]

I just found a really bizarre bug. I'm not certain where it is, but it seems under some circumstances, a number consisting of multiple 0's can exist. For example, 000.

I spotted it while rewriting a program 'FXND' (meant to duplicate the oldRPL command of the same name) to take advantage of the new commands. Here's the code for it:

<< STKPUSH DUP TYPE -> t << CASE t 10 == THEN 1 END t 56 == THEN IF OBJ-> NIP { / } 1 GET SAME NOT THEN STKPOP 1 END END 24 DOERR END >> >>

If I do:

0.6 ->Q FXND IDIV2

I get:

00000000

3

This does not occur when I do:

'3/5' FXND IDIV2

So the problem must lie in ->Q somehow. But that may only be a symptom, because numbers consisting of multiple 0's probably shouldn't exist in the first place?

[Claudio L.]

(08-23-2017 05:19 PM)The Shadow Wrote:  I just found a really bizarre bug. I'm not certain where it is, but it seems under some circumstances, a number consisting of multiple 0's can exist. For example, 000.

I spotted it while rewriting a program 'FXND' (meant to duplicate the oldRPL command of the same name) to take advantage of the new commands. Here's the code for it:

<< STKPUSH DUP TYPE -> t << CASE t 10 == THEN 1 END t 56 == THEN IF OBJ-> NIP { / } 1 GET SAME NOT THEN STKPOP 1 END END 24 DOERR END >> >>

If I do:

0.6 ->Q FXND IDIV2

I get:

00000000

3

This does not occur when I do:

'3/5' FXND IDIV2

So the problem must lie in ->Q somehow. But that may only be a symptom, because numbers consisting of multiple 0's probably shouldn't exist in the first place?

I found it myself 2 days ago and fixed it, it was a denormalized zero that confused the text conversion.
Will come out in the next release.

[Claudio L.]

(08-22-2017 04:37 PM)The Shadow Wrote:  

(08-20-2017 03:22 AM)Claudio L. Wrote:  I see. ->Q uses a simple algorithm of invert and take the fractional part.

That's the traditional way to do it, but you can get a significant speed-up with no loss of accuracy by rounding instead. Instead of FP, you do:

<< DUP 0 RND - >>

Basically, this groups together strings of 1's, saving many iterations. (The continued fraction of the golden ratio becomes { 2 -3 3 -3 3 -3...} )

There are some rare cases where this will be a bit slower - sqrt(2) is an example - because they don't have any 1's. But I find that a more than acceptable trade-off.

Do be aware that you can end up with both numerator and denominator negative with this method, but that's easy to fix at the end.

-----------

I'll look into that optimization, thanks for the hint.

(08-22-2017 04:37 PM)The Shadow Wrote:  After doing a LOT of programming, I have found some oddities about typing:

Alpha mode seems to disable custom keys. I can't think of any good reason why this should be true.

I'll give you a simple one: It's a different keycode. You need to define your custom key explicitly for the alpha plane, even if the behavior is exactly the same as outside of it.

(08-22-2017 04:37 PM)The Shadow Wrote:  Entering quotes automatically switches to alpha mode. This is no doubt intended to help, but it catches me off-guard every single time.

When you hold down alpha to enter some letters, the calc will not recognize left or right shift. So for example, you can't type a -> without releasing alpha, which is quite annoying, especially since I frequently name programs with an arrow in the middle.

Same explanation as above: being a different plane, there needs to be a definition for that key in the alpha plane. It wouldn't surprise me if I forgot to define some keys behavior within the alpha plane.
This is a good area for testers to work on: Please make a wish list of missing key bindings and I'll add them by default. Include all the planes the key should work on.

-----------

(08-22-2017 04:37 PM)The Shadow Wrote:  Thank you from the bottom of my heart for SDARCHIVE and SDRESTORE. They've already saved me a good deal of grief.

Can I throw in a request for VISIT? I love it to pieces.

You sure can, but that's more complicated to implement so it might be a while.
Thanks for the feedback.

[The Shadow]

(08-23-2017 06:45 PM)Claudio L. Wrote:  I'll look into that optimization, thanks for the hint.

Ironically enough, I first learned about it years ago from an HP forum post suggesting a change in the stock RPL ->Q. It's served me in good stead ever since.

Quote:I'll give you a simple one: It's a different keycode. You need to define your custom key explicitly for the alpha plane, even if the behavior is exactly the same as outside of it.

Oh my goodness, I feel like an idiot! Yes, of course.

I wonder if alpha mode should be a context rather than a plane? Because unlike left and right shift, alpha mode persists after pressing multiple keys.

For that matter, algebraic and program modes might make good contexts.

Quote:Same explanation as above: being a different plane, there needs to be a definition for that key in the alpha plane. It wouldn't surprise me if I forgot to define some keys behavior within the alpha plane.
This is a good area for testers to work on: Please make a wish list of missing key bindings and I'll add them by default. Include all the planes the key should work on.

Okay. Well, there's definitely the arrow. It needs to be bound to alpha-RS-0 and to AH-RS-0.

-----------

Quote:

(08-22-2017 04:37 PM)The Shadow Wrote:  Can I throw in a request for VISIT? I love it to pieces.

You sure can, but that's more complicated to implement so it might be a while.
Thanks for the feedback.

Huh. I've got a kludgey RPL version working already, though it fails pretty often, probably due to key timing.

[The Shadow]

Another bug, this time apparently in LN.

At 32 bit precision, LN x gives a number in excess of 9.89E9 when x < 0.1.

At 64 bit precision, the same problem happens when x < 0.01.

Interestingly, the PC emulator gives an entirely different wonky value, but it's still wonky.

EDIT: Out of curiosity, when the time comes to do RAND, what's your plan? I've implemented a simple 32 bit xorshift routine, which is good enough for most of my needs. But I know that better and faster things can be done natively in C.

It's a bit annoying that one can't set a 64 bit word size, but such is life.

[Claudio L.]

(08-23-2017 11:29 PM)The Shadow Wrote:  Another bug, this time apparently in LN.

At 32 bit precision, LN x gives a number in excess of 9.89E9 when x < 0.1.

At 64 bit precision, the same problem happens when x < 0.01.

Interestingly, the PC emulator gives an entirely different wonky value, but it's still wonky.

EDIT: Out of curiosity, when the time comes to do RAND, what's your plan? I've implemented a simple 32 bit xorshift routine, which is good enough for most of my needs. But I know that better and faster things can be done natively in C.

It's a bit annoying that one can't set a 64 bit word size, but such is life.

??? I could swear I tested LN across the entire range before moving on to something else. This is very critical, I'll have it fixed as soon as possible.

PS: For RAND, I think Namir has quite a few random generators, I'll have to do some research.

[Claudio L.]

(08-24-2017 12:05 AM)Claudio L. Wrote:  ??? I could swear I tested LN across the entire range before moving on to something else. This is very critical, I'll have it fixed as soon as possible.

All 3 ROMs have been updated.
They fix the bug in LN, plus other couple of bugs.
Also, they add the command DIGITS to extract certain digits off a real number, and STKPICK, to copy an element from any snapshot into the current stack.
It also binds the arrow to the alpha-hold +shift plane which was missing.

I discovered one bug that is not fixed in this release (more an annoyance than a bug):
When activating shift, then alpha-hold and a key, the shift will deactivate after the key is pressed, which is correct (alpha will remain until you release it).
However, if you press alpha-hold first, then a shift and then a key, the shift gets "stuck" until you press shift again to deactivate it. This is not as intended and will be fixed.

[Claudio L.]

(08-25-2017 02:40 AM)Claudio L. Wrote:  I discovered one bug that is not fixed in this release (more an annoyance than a bug):
When activating shift, then alpha-hold and a key, the shift will deactivate after the key is pressed, which is correct (alpha will remain until you release it).
However, if you press alpha-hold first, then a shift and then a key, the shift gets "stuck" until you press shift again to deactivate it. This is not as intended and will be fixed.

It's fixed. I already uploaded a ROM with this fix.
I hear proposals for key assignments on those weird key planes.
I propose for example:
AL-HOLD and * to insert double quotes "
AL_HOLD and - to insert _

[The Shadow]

Hey, DIGITS is kind of neat. It'll save effort in doing anything involving the date or time, that's for sure!

I've been doing research on pseudo-random number generators the last couple days, and this thing takes the cake: http://xoroshiro.di.unimi.it/xoroshiro128plus.c

It's fast, small, and amazingly robust. I'm kind of amazed how much has been done in this area the last few years.

The arrow keybinding doesn't seem to have worked.

Other missing keybindings on alpha-hold:

Brackets (LS-*), quotes (RS-*), parentheses (LS--), underscore (RS--), braces (LS-+), program delimiters (RS-+), pi (LS-SPC), comma (RS-SPC), colon (LS-DT), and line feed (RS-DT).

[Claudio L.]

(08-25-2017 11:50 PM)The Shadow Wrote:  The arrow keybinding doesn't seem to have worked.

Download and flash again. A few minutes after I posted I realized the key binding wasn't committed (I worked at 2 different computers and forgot to either commit, push or pull the repo, not sure). You must've downloaded in the few minutes it took me to rebuild and upload.

(08-25-2017 11:50 PM)The Shadow Wrote:  Other missing keybindings on alpha-hold:

Brackets (LS-*), quotes (RS-*), parentheses (LS--), underscore (RS--), braces (LS-+), program delimiters (RS-+), pi (LS-SPC), comma (RS-SPC), colon (LS-DT), and line feed (RS-DT).

Yes, I'll add those. I can't see why you would want to hold alpha for those but it's OK. I can see why you wanted that for the arrow, though, makes perfect sense as it's part of the name but even if you are typing a formula you press alpha only for the name, then you can type the symbols without alpha.

[Claudio L.]

(08-25-2017 11:50 PM)The Shadow Wrote:  I've been doing research on pseudo-random number generators the last couple days, and this thing takes the cake: http://xoroshiro.di.unimi.it/xoroshiro128plus.c

It's fast, small, and amazingly robust. I'm kind of amazed how much has been done in this area the last few years.

I looked at the algorithm. It produces a 64-bit integer. Even if presented as a 0.0 to 1.0 range, it has a granularity of 5e-20 (actually 2^-64). I wonder if it's enough for newRPL with a default precision of 32 digits? In other words, if it provides 18 random digits, what do we fill the other 14 with?

[The Shadow]

(08-26-2017 01:31 AM)Claudio L. Wrote:  I looked at the algorithm. It produces a 64-bit integer. Even if presented as a 0.0 to 1.0 range, it has a granularity of 5e-20 (actually 2^-64). I wonder if it's enough for newRPL with a default precision of 32 digits? In other words, if it provides 18 random digits, what do we fill the other 14 with?

Simple. You generate as many sets of 18 digits as you need to fit the precision and stick them together. (In my RPL implementation, I've just been adding them together as strings.) Any excess gets rounded off as usual. The only thing you have to watch out for is to pad the front of a set of 18 with leading 0's if necessary.

Incidentally, I've been encountering some oddities with the editor. It seems that when programs get past a certain size, you get weird errors. Like, a variable I've been using all along suddenly gets changed to 'INVALID_COMMAND', or I suddenly get an error of 'Invalid word' when I try to exit. I haven't done anything I know of to justify these things.

EDIT: Oh, and I coded a quick version of what we called ->NFMT above (though I called it ->NFS to emphasize it produces a string) and it is very useful. It's especially nice for getting all the digits of a number, and to shed those pesky dots marking uncertainty. In fact I've got a little program XDOT that does nothing except get rid of dots. (It's just << "#.A#" ->NFS STR-> >>) Might make a useful command, similar to oldRPL R->I, though working on non-integers. Even better, it works on lists of numbers all at once.

By the way, some commands mark uncertainty when they shouldn't. For example, sqrt(4) gives 2. rather than 2

EDIT: Just found some oddities with complex arithmetic. If at 32 digits of precision you do:

(16 16) (1 1) 5 ^ /

You get (-4 1.25E-31) instead of (-4 0).