newRPL - build 1255 released! [updated to 1299]

[Claudio L.]

(07-30-2019 07:13 PM)JoJo1973 Wrote:  I'm doing devil's advocate:

How would ASSCOMB work for more complicated expressions? For example if X is "R>=0" and Y is "O∞<0" then 'Y^2+SIN(X)' ASSCOMB gives what? I suppose there's an algorithmic way to solve this, but this would mean that internally each built-in function must provide its domain to the rules engine, not to mention the fact that some operations between sets are possible only in a certain order (matrix divided by scalar it's possible, scalar divided by matrix isn't)

Exciting feature, anyway!

P.S.: Using "Z" rather than "I" would be classy!

It's already implemented for the most common operators and functions. I had to do it, otherwise the rules engine would be too dumb to apply rules with subscripts. For instance, a rule that matches an arbitrary expression .XX using some subscripts requiring the expression to be real and positive need to match "any" expression that is known to be real and positive, not just a number or a single variable.
User defined functions or other more complicated functions simply trigger set the "unknown" type so the expression won't match if there's any requirements in the rule. In other words, if you require a real number match, the rules engine won't consider it a match unless it can be proven to be real. This is already done and just the way it works right now.

(07-30-2019 07:43 PM)JoJo1973 Wrote:  On a side note, the subscript notation could be phased away and supported only at source code level to add new rules. In this way subscripts could find a new life as valid identifier characters enabling the user to write expressions such as 'X1+X2' (imagine the subscripts, anyway!)

Devil's advocate part II - more ramblings (unfortunately I'm no Keanu Reeves...)

Subscripts are a bit cumbersome to use, and prone to errors. Moreover I can't imagine a valid rule where the same variable has different attributes: a situation that the subscript system allows but is avoided by design using the ASSUME command.

The only advantage I can see is that variables and attributes are compacted into single entities, and this is good when you have to quickly write many rules or manipulate them (using RULEAPPLY, for example, would become more complicated.)

I agree the subscripts are ugly, but remember the expression needs to retain all these properties when it's edited, and for speed, the rules engine needs to quickly get to the properties as soon as it reads an identifier, so it makes sense to keep the data where it's needed: at each identifier. I agree that different attributes for the same variable are not needed and are error prone, but so far I have no better way of doing it. If you have any idea how to preserve these flags during edit without using the subscripts I'm all ears.
Using ASSUME in a program might be more readable, but once the expression is an object by itself on the stack and you hit the down arrow to edit it... how do we present this?

(07-30-2019 07:43 PM)JoJo1973 Wrote:  If and when, in some future, the subscript system becomes an internal-only feature, I have a little suggestion: when in edit mode a reserved character should be attached to a variable (just like the subscripts, in fact) only to present a visual cue for the fact that some assumption on that variable has been made.

Exactly, but if it's only a visual cue, when the user hits "Enter", that information needs to be stored somewhere in the text, and it has to be practical to type and to read and use.
I guess for expressions could be something like:

Code:

'X^Y ASSUMING X→R∞<0 , Y→R'

The problem is, when I look at this expression on the stack all I want to see is 'X^Y', the rest is mental pollution.

If the above doesn't seem so bad, I guess it could extend to rules:

Code:


'.mX*.mX^.NN₃₂₁:→.mX^(1+.NN₃₂₁)'

would become:

'.mX*.mX^.NN:→.mX^(1+.NN) ASSUMING .NN→Z≥0'

How does this look?