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

[Claudio L.]

(08-26-2017 04:40 AM)The Shadow Wrote:  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.

I'd have to get 16 digits out of the 18, which is 2 groups of 8 (reals internally store 8 digit groups). That means a random 2000 digit number would need 120 calls to this RNG. It better be fast!

(08-26-2017 04:40 AM)The Shadow Wrote:  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.

This shouldn't happen, no matter what you do (nothing you do justifies data corruption). Can you try to find a sequence of events to reproduce it? I need your guidance to track it. The INVALID_COMMAND is the string the decompiler uses when an object is not valid. Most likely one of the commands you used wrote to an object that was moved during a garbage collection. If the command is not coded properly, the object moves, and some other object takes its place and will get corrupted. What commands were you trying when this happened?
To fix these things, turn the calc off and back on. The calculator runs MEMFIX every time it wakes up, scanning for invalid objects. If an invalid object is found, it will be replaced with the BINT zero (you'll lose the damaged object, but it won't be invalid anymore).

(08-26-2017 04:40 AM)The Shadow Wrote:  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.

It's been in the bug tracker for a while, to write a new command that marks any number as approximate, or as exact. Not too useful so it's sitting there.

(08-26-2017 04:40 AM)The Shadow Wrote:  By the way, some commands mark uncertainty when they shouldn't. For example, sqrt(4) gives 2. rather than 2

Numeric algorithms will always introduce rounding, even if they produce the exact result with 32 digits. The square root algorithm is no exception. The result might be the integer number 2, but after many iterations of numbers that weren't exact, so it can't be exact. In order to verify the result is exact, you'd have to take the rounded result, square it and compare with the original exact argument. This would slow things down a lot, just for an extra trailing dot...\

(08-26-2017 04:40 AM)The Shadow Wrote:  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).

Complex numbers require a lot of operations to produce a result, so there can (and will) be rounding errors. In this case, (1 1) 5 ^ is done through LN 5 * EXP, which is causing the rounding errors. I could detect the special case of an integer exponent and do it with multiplications to mitigate the effect, but in the general case this is normal and expected.
I could also increase the precision by 8 digits to reduce the rounding errors on the final results, paying a price in speed.