newRPL - build 1255 released! [updated to 1299]

[Claudio L.]

(02-17-2019 05:13 AM)The Shadow Wrote:  The rules system does indeed seem more robust, however 'X-X' causes a crash when EVAL'd, and 'X-2*X' gives '-X' twice for some reason. And 'X/X' still doesn't become '1', even though all other divisions simplify correctly when the flags allow for it.

I must've broken something, that was working before... I'll investigate, thanks for the report.

(02-17-2019 05:13 AM)The Shadow Wrote:  ALLROOTS doesn't work properly on square roots of negative numbers. For example, sqrt(-3) gives the same result as sqrt(3) when ALLROOTS is used on it. EDIT: On the other hand, it does a really nifty job on things like '(-1)^(1/3)'!

I'll check the rules, I think I need a separate rule to transform sqrt(-.xX) into i*sqrt(.xX).

(02-17-2019 05:13 AM)The Shadow Wrote:  The case-lists work beautifully. One oddity, though - they have the same extended type as regular lists. I'd suggest giving them an extension of their own.

That's a bug, they have a different library number, should report a different type. I'll check that as well, thanks!

(02-17-2019 05:13 AM)The Shadow Wrote:  Also, the 'case' property is perhaps a shade too fragile - it gets lost if you ADD two case-lists together, which seems like something worth doing. Likewise if you PUT something in one.

There's many existing commands that are not case-list aware yet. They do recognize a list but I need to updaste them to keep the type of the list given untouched.

(02-17-2019 05:13 AM)The Shadow Wrote:  It could be interesting to produce other list variants. One that immediately comes to mind is sets: Basically lists that can't have more than one of a given element. ADDing them would do union.

Once tagged objects are in, a Python-style 'dictionary' list might also be useful.

Yes, except I want them more flexible than Python. Lua tables are good examples, this would also make it simple too add a Lua2RPL library to allow people to code in Lua within the newRPL environment. That's a future improvement...

For future reference, the Cyrillic 'i' is Alpha-LS-7, and the Cyrillic 'j' is Alpha-LS-Hold-7. Adding a Cyrillic 'k' would be appreciated, so I can program in quaternions without them looking funny. (Though I suppose I could get away with just calling it 'i*j', or even 'ij'.)

Where is the constant library located? I haven't seen it yet.

P.S. Is there a 'plus or minus' symbol on the calculator? That'd be perfect for c{1 -1}.
[/quote]

(02-17-2019 04:53 PM)John Keith Wrote:  Enthusiastic yes to both!

I'm feeling the pressure now...

(02-17-2019 09:48 PM)The Shadow Wrote:  Oh, and now that we have symbolic imaginary units, it'd be nice to see RE and IM interact with them. They *kind of* do now, but you have to follow up with ->NUM.

Perhaps a flag could control whether Cyrillic 'i' or 'j' is used as the imaginary unit? It's a bit awkward having them both in play at the same time. And it's a similar sort of preference thing as, for example, which month/day/year format to use.

Many commands need to also be updated to better interact with constants as well. Adding a new type when there's 400 commands already implemented is hard...

Regarding the letter choice. I think:
* People who like I or j typically use them consistently
* Having i and j at the same equation is still useful for people who want to define rules on them to try to implement quaternions for example. As long as you don't use ->NUM, they are two different things.