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

[The Shadow]

(08-26-2017 07:04 PM)Claudio L. Wrote:  

(08-26-2017 07:01 PM)The Shadow Wrote:  Now that you mention it, those aren't really all that necessary except for pi and the line feed and possibly the comma. You're right, the brackets and so on have no real reason to hold alpha for.

Talking about Pi, I think alpha-hold+shift could/should be the greek letters and symbols.

That's not a bad idea. (Just out of curiosity, why 'pi0' instead of just 'pi'?)

By the way, I accidentally discovered that half-space or whatever it's called on AH-SPC. It's very nice-looking when used as a digit separator in SETLOCALE! Much better than the comma, and takes up less space too. It has tripped me up a couple times when programming, though. It looks close enough to a space that it's not an obvious issue.

Quote: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...\

I see your point. Never mind.

Quote: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.

Again, I see your point. I may just do all my Gaussian integer stuff in matrix representations, I sometimes have to do that anyway.

Quote: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).

Thinking back, both times this happened, the variable was being used in the test part of a WHILE loop.

Like, in the more recent case I had:

WHILE n p / <blah> REPEAT <blah> 'n' STO <blah> END

The n in both places got changed to INVALID_COMMAND. When I tried to retype in the n's, I got an 'Invalid word' error.

Both times, it happened in a long program, multiple flow structures deep, and only on the innermost structure. (Which, as mentioned, was a WHILE in both cases.)