newRPL - build 1255 released! [updated to 1299]

[Claudio L.]

(12-17-2018 09:38 PM)The Shadow Wrote:  Hmm. AUTOSIMPLIFY needs some work yet. It doesn't yet know how to multiply singleton variables. ie, it can't change 'X^3*X' to 'X^4'. It also can't change 'X+X' to '2*X'.

You are right (which is not unusual for you). The rules I have cover X^n*X^m but I need to add X^n*X (seems trivial now!). Same thing for addition, it requires additional rules because X^1 is not the same as X.
I need to add those rules as level 1.

(12-17-2018 09:38 PM)The Shadow Wrote:  It can't change '0*X' to 0, but I suppose that might be because X might be infinite?

Right again, we can't start eliminating things unless we somehow tell the CAS that X is not infinite. We could include this on a higher level (say level 5), in which simplifications are very aggressive and not necessarily strict mathematically speaking. This would be controlled by a flag, but each level needs to be very clearly documented, the user should not have any doubt about what's simplified.

(12-17-2018 09:38 PM)The Shadow Wrote:  It also can't handle powers of powers, but I suppose that's probably because of the headaches involving even powers? ie, sqrt(X^2) should strictly speaking be abs(X), not X.

Yes, I need to add that too, I'm just starting to make sense of this in my head so bear with me.
I need some help to come up with all the simplifications, then we need to group them in levels so the user can control them using flags. Perhaps they shouldn't even be levels, they should be groups, and the user should have perhaps 8 flags to individually enable/disable each of the 8 groups of rules.
For example, simplifying X*X = X^2 is very basic, but undesirable if X is a matrix, where powers aren't even defined as an operator. So I'd like the user to be able to disable that, but still keep other basic simplifications on matrix expressions (like 3*A+2*A=(3+2)*A). Same thing if you are writing Boolean expressions, you need to disable some simplifications that can mess them up.
Also, simplifications that assume commutative multiplication need to be grouped separate, so they can be disabled, (I don't want A*B+B*A to become 2*A*B on a matrix expression).
Then we can have a group that could be only enabled for matrix expressions, where A*INV(A) = I, rather than the number 1 for example, or defining proper behavior for boolean algebra.
Even for regular algebraic expressions, simplifying for example .xV/.xV:->1 is not good, as it removes a discontinuity.
So let's come up with a plan to do the simplifications, then we'll move on to other commands that are simpler (most commands in the old CAS are quite simple, just one or 2 rules and that's it, the complicated ones are the ones to compute derivatives and integrals).

One idea is for most CAS commands that operate on rules, to look for a variable in the current directory called 'COMMAND.RULES' where the user can add rules of their own. For example, AUTOSIMPLIFY would look for 'AUTOSIMPLIFY.RULES' and apply the user rules after the standard ones. Same thing for other commands like COLLECT, even derivatives and integration could look for user rules. Instead of posting in a forum "newRPL cannot integrate this...", you can simply store the missing rules on your calc and problem solved forever (or until your next memory loss).