newRPL - build 1255 released! [updated to 1299]

[Claudio L.]

(12-07-2018 11:52 PM)compsystems Wrote:  The problem is that I have not read the entire manual, soo had tried some combinations and did not get any output, I deduced that it had not been incorporated.

Looking for other combinations. I only find the options between [M] and [Enter]

RS_hold + [spc] = ;
RS + [spc] = ,

LS_hold + [0] = INF ;
LS + [spc] = ¯inf,

OK, the wiki is not very good yet, so I forgive you
Many keys use hold-shift. Most of them are set to do the same for shift and shift-hold because when typing fast, sometimes you press the key before you release the shift, but many are doing different functions out of necessity.

[Claudio L.]

All ROMs and Android app updated to build 1140 at the usual place.

This rom has as a main feature the new symbolic rules engine, which will form the basis of most CAS commands, allowing to reach a much closer match to the original 50g.
Most old CAS commands should be able to be coded simply as applying a set of rules to the input.

The wiki now has a section explaining how to use the new rules engine.
The AUTOSIMPLIFY command is the only one for now that uses a few rules, more will come soon.
Here's a simple teaser experiment, implementing a function DER(f(u),u) that computes derivatives of polynomial functions:

Code:


{
'DER(.xU,.xU):→1'
'DER(-.xU,.xDU):→(-DER(.xU,.xDU))'
'DER(.xU+.XV,.xDU):→DER(.xU,.xDU)+DER(.XV,.xDU)'
'DER(.nK*.XU,.xDU):→.nK*DER(.XU,.xDU)'
'DER(.nK,.xDU):→0'
'DER(.xU^.in,.xDU):→.xU^(.in-1)*.in*DER(.xU,.xDU)'
}

Simply put your symbolic polynomial expression as 'DER(3*X^3-2*X^2+7*X+0,X)', place the list above in the stack and run RULEAPPLY.
You may need an AUTOSIMPLIFY at the end to do some additional cleanup.

Please test and report any issues you find on this new engine.

[The Shadow]

Very nice! I suppose if you wanted to expand DER to handle SIN and COS, you'd have to use RULEAPPLY1, right? Otherwise you'd get an infinite loop.

Also, to implement the chain rule on that version of DER, you'd need separate rules applying it to SIN of a function, COS of a function, and a function to a power, correct?

What rules does AUTOSIMPLIFY apply?

[Claudio L.]

(12-17-2018 05:13 PM)The Shadow Wrote:  Very nice! I suppose if you wanted to expand DER to handle SIN and COS, you'd have to use RULEAPPLY1, right? Otherwise you'd get an infinite loop.

Also, to implement the chain rule on that version of DER, you'd need separate rules applying it to SIN of a function, COS of a function, and a function to a power, correct?

What rules does AUTOSIMPLIFY apply?

You don't need to worry about infinite recursion, the rule would be:

Code:


'DER(SIN(.xU),.xDU):→COS(.xU)*DER(.xU,.xDU)'

Since the COS is not inside DER(...) anymore, there's no issue with recursion. You do need independent rules for SIN, COS, and many others (this was just a humble example of what's possible, wasn't meant to be a proper derivative implementation).
By including generic functions '.xU' in the rules, rather than individual variables, the chain rule is already implemented. The next pass of RULESAPPLY will operate on the new DER(...) term until you end up with DER(constant,x)=0 or DER(x,x)=1.
This simplified example is lacking some important things, for example I did not include a generic multiplication rule:

Code:


'DER(.xU*.XV,.xDW) = DER(.xU,.xDW)*.XV + .xU * DER(.XV,.xDW)'

in case the polynomial is factored, for example. This will take the first multiplicand ('.xU' would match one term in a multiplication, whatever subexpression it may contain) and isolate it from the rest of the expression ('.XV' will match all other multiplicands grouped together), and work its way recursively until all multiplicands have been separated.

[Claudio L.]

(12-17-2018 05:13 PM)The Shadow Wrote:  What rules does AUTOSIMPLIFY apply?

AUTOSIMPLIFY does first a numeric reduction (multiplies numbers together, adds fractions, etc.), then applies a series of rules. The idea is to have several sets of rules and a flag that sets the simplification level the user wants. For now I only created level1, the most basic things.
Quoted from lib-56.nrpl source code:

Code:


@#name lib56_autosimplify_level1
{
'0+.XX:→.XX'                                        @ REMOVE TERMS WITH ZERO
'INV(1):→1'                                         @ ELIMINATE OPERATION ON ONE
'1*.XX:→.XX'                                        @ REMOVE MULTIPLY BY ONE
'.XX^1:→.XX'                                        @ REMOVE EXPONENT OF 1
'√.XX:→.XX^INV(2)'                                  @ ELIMINATE SQUARE ROOT FOR OTHER RULES TO WORK
'.MN*.mX+.MM*.mX:→(.MN+.MM)*.mX'                    @ ASSOCIATE TO THE LEFT (NON-COMMUTATIVE)
'.mX*.MN+.mX*.MM:→.mX*(.MN+.MM)'                    @ ASSOCIATE TO THE RIGHT (NON-COMMUTATIVE)
'.NN*.xX^.Nexp+.NM*.xX^.Nexp:→(.NN+.NM)*.xX^.Nexp'  @ ADD TERMS IN THE SAME VARIABLE AS LONG AS THE REST IS NUMERIC
'.xX^.NN*INV(.xX^.NM):→.xX^(.NN-.NM)'               @ CANCEL OUT TERMS WITH EXPONENTS
'.xX^.NN*INV(.xX):→.xX^(.NN-1)'                     @ CANCEL OUT TERMS WITHOUT EXPONENT IN DENOMINATOR
'.xX*INV(.xX^.NM):→.xX^(1-.NM)'                     @ CANCEL OUT TERMS WITHOUT EXPONENT IN NUMERATOR
'.xX^.NN*.xX^.NM:→.xX^(.NN+.NM)'                    @ ADD EXPONENTS IN MULTIPLYING TERMS
'.mX*.mX^.NM:→.mX^(1+.NM)'                          @ ADD EXPONENTS WITH IMPLICIT EXPONENT 1
'.XX^INV(2):→√.XX'                                  @ BACK TO SQUARE ROOTS
}

Yes, all symbolic rules will be coded in RPL, so they are easy to maintain and improve by the community.

[The Shadow]

Ah! I get it now, thanks! A full derivative operator shouldn't be too hard to implement at that rate. And a symbolic complex number engine would be downright *easy*. (Though I'm not clear yet whether it would be faster than my matrix implementation - I'm guessing it would be.)

As an added bonus, my somewhat kludgey Boolean simplification program from oldRPL will be incredibly easy to make.

[cdmackay]

thanks for the new version.

quick question, please: when viewing command-completion suggestions with AL-DN, shouldn't they be in alphabetical order? They don't seem to be…

thanks.

[The Shadow]

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

It can't change '0*X' to 0, but I suppose that might be because X might be infinite or a matrix?

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.

[Claudio L.]

(12-17-2018 07:31 PM)cdmackay Wrote:  thanks for the new version.

quick question, please: when viewing command-completion suggestions with AL-DN, shouldn't they be in alphabetical order? They don't seem to be…

thanks.

Suggestions are in "library" order, so they are (loosely) grouped by functionality. This is for speed and zero-memory use reasons. To present sorted results, all results need to be obtained first, then sorted, then the user would be able to scroll through the list. This means there needs to be a list in memory somewhere.
The way it's implemented it simply asks the libraries for the next suggestion given the known first letters. If a library gives up, then it tries the next one. This way there's zero use of memory, and is extensible since new libraries will be queried as they are added (including user libraries!). The down side is that because there's no list of commands, you can't sort it.

[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).

[The Shadow]

I like the idea of groups rather than levels, though some of the groups will doubtless be equivalent to levels. I'm thinking of the oldRPL 'Rigorous' flag, which gets extra persnickety about absolute values.

I also like the idea of user-defined rules, though I hope they search upward the directory tree like usual. That way if there's a rule I want to always use, I can just put it in HOME.

[cdmackay]

(12-17-2018 09:47 PM)Claudio L. Wrote:  Suggestions are in "library" order, so they are (loosely) grouped by functionality…

thanks for the explanation, Claudio.

[The Shadow]

A further thought on groups... I think they should perhaps be organized by what the expected content of a variable is.

That is, a matrix variable should be treated differently than a real variable, which in turn is different from a complex variable. (I'm not sure what sort of variable should hold infinity, though, as it's not a real or complex number!)

So, rather than having global flags, have the type set for each variable, and apply rules accordingly.

There would still be room for flags denoting degrees of rigor. Sometimes you don't care about eliminating poles or taking account of different square roots, but sometimes you do.

[The Shadow]

Also... Matrix powers aren't defined as an operator? I thought integer powers were, though certainly rational powers are exceedingly non-trivial, to say the least!

The square of a matrix seems perfectly well-defined, though?

[Claudio L.]

(12-18-2018 03:42 PM)The Shadow Wrote:  Also... Matrix powers aren't defined as an operator? I thought integer powers were, though certainly rational powers are exceedingly non-trivial, to say the least!

The square of a matrix seems perfectly well-defined, though?

Yeah, not sure what was in my head when I wrote that, just ignore the Alzheimer parts.

[Claudio L.]

(12-17-2018 10:32 PM)Claudio L. Wrote:  

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

I went ahead to add these "simple" rules and started digging deeper: The rules I put there are using .M matches so they would be universal rules that work with matrices too.
Here's the catch: When adding 'n*X+X' rule, it would be '(n+1)*X', except if 'n' is a matrix, it should really be (n+I)*X. The problem is that implicit 1 can be I or 1 depending on the type of 'n'.
First: I'd need to create a symbol I in newRPL that evaluates to an identity matrix of any size when operated upon. This symbol could evaluate to 1 when operating with numbers, but then formulas would look strange with this I showing up unexpectedly.

I could have the rules always add I, then another rule would replace I with 1 when added to a numeric expression '.NN+I:→.NN+1', but if the expression has some unknown variables (not purely numeric), the I would remain and the user would be extremely confused.

The details of a CAS are overwhelmingly complex...

[The Shadow]

I'm not clear on why you need a symbol for the identity matrix for those particular rules? Matrices can be multiplied by a scalar just fine. EDIT: In fact, in standard linear algebra you *can't* add the identity matrix to a scalar.

You might well need the identity matrix in other contexts, though.

EDIT: Where problems do arise is in the rule eliminating an added zero. For matrices, that would have to be the zero matrix. But since you're getting rid of it anyway, maybe it's not too much of a problem?

I wonder if we need a separate MATRIXSIMPLIFY command?

[Claudio L.]

(12-19-2018 08:36 AM)The Shadow Wrote:  I'm not clear on why you need a symbol for the identity matrix for those particular rules? Matrices can be multiplied by a scalar just fine. EDIT: In fact, in standard linear algebra you *can't* add the identity matrix to a scalar.

You might well need the identity matrix in other contexts, though.

EDIT: Where problems do arise is in the rule eliminating an added zero. For matrices, that would have to be the zero matrix. But since you're getting rid of it anyway, maybe it's not too much of a problem?

I wonder if we need a separate MATRIXSIMPLIFY command?

I didn't think as far as the zero matrix, will be needed for sure. The identity in the example perhaps wasn't clear because I used the letter n in n*X+X, but I was thinking what if n is a matrix (replace it with A for visual impact)
Now A*X+X will become (A+ I) *X. The special symbol I should match whatever size allows the addition to matrix A to proceed. The only special thing is that is a matrix of all sizes. The zero matrix also needs a special all-sizes symbol in case you decided to EVAL or ->NUM the expression eventually. The zero only gets simplified if added to something, if it's by itself you can't remove it.
X-X = 0 (matrix symbol zero) and that result needs to be shown to the user. Problem is... What if the user does ->NUM? What size matrix would it be?

[The Shadow]

Ah, I see. I'm wondering if it's too cumbersome to have a set of rules for both reals and matrices. Like I said before, maybe we should declare the types of variables so that the right rules are used for it. Like, maybe variables are real by default, so 'X' is assumed real; but 'X.MAT' is assumed matrix.

Alternatively, have a separate MATRIXSIMPLIFY command. AUTOSIMPLIFY would then assume that variables are real. Flipping a flag would then cause EVAL to MATRIXSIMPLIFY rather than AUTOSIMPLIFY when used on an algebraic object. (It would still use AUTOSIMPLIFY on the entries of a matrix.)

[The Shadow]

Also... Do we actually *need* to be able to handle matrix equations? OldRPL can't.