newRPL - build 1255 released! [updated to 1299]

[pier4r]

Nice idea. It is so obvious that one thinks: why was it not done before?

[The Shadow]

(04-04-2018 03:38 PM)Claudio L. Wrote:  Right now I started on the Forms and UI but then it occurred to me that I needed a few things first:
* Variable properties: A variable can have properties now. I have a couple in mind that will be used by the Forms framework, for example a preferred unit for display.

So it will automatically try to convert to that unit? Nice. What other properties do you have in mind?

Quote:* An event framework to trigger something when a variable changes, which will help build applications more easily. The idea is that you create a variables, 'A', 'B', for example, and define a program that does for example C=A+B, triggered every time A or B change.

Then that idea mutated into automatic evaluation of a tree of those triggers.
Now you define 'A' with a value, 'B' with a value, and 'C' with the formula 'A+B', and the system will automatically recalculate C every time A or B change.

Hmm. So this will be an automatic feature of all variables? I have mixed feelings about that, depending on how it works.

Like, say C is 'A+B', and I store 1 in A and 2 in B. If I put C on the stack, what do I get, 'A+B' or 3? If the former, how is that different from now? If the latter, how do I edit C to be 'A-B'?

[Claudio L.]

(04-04-2018 07:38 PM)The Shadow Wrote:  Hmm. So this will be an automatic feature of all variables? I have mixed feelings about that, depending on how it works.

Like, say C is 'A+B', and I store 1 in A and 2 in B. If I put C on the stack, what do I get, 'A+B' or 3? If the former, how is that different from now? If the latter, how do I edit C to be 'A-B'?

Your example would be like this:
You store 1 in A and 2 in B
You store 'A+B' in the "definition" property of variable 'C'. Right now the syntax is ugly but I think it works well with the 50g keyboard:

Code:

'A+B' 'C...Defn' SPROP

The command SPROP will store the property 'Defn' of variable 'C', properties are separated by a triple dot so it doesn't happen accidentally.
Now variable 'C' will contain the value 3, automatically calculated by applying ->NUM to the 'Defn' property.
SPROP will also scan the formula 'A+B' (or a program, whatever you provide) and determine which global variables it depends on, in this case 'A' and 'B'. Then it will add 'C' to a property called 'Depn' (dependency) in 'A' and 'B'. This 'Depn' property will hold a list of all variables that depend on a given one, so if this variable change, all variables in the list will be recalculated.
A change to 'A' will check if the 'A...Depn' property exists, then go through the list running ->NUM in the 'Defn' propety of each variable. Each variable changed will also trigger other evaluations in the chain.

So the variable will hold the result, and the formula will go in a property, much like in a spreadsheet you have the result and the formula as 2 separate things.
For the units, I think the property 'Unit' will be a preferred display unit, when displaying in a Form it will attempt to convert to the preferred unit but the stored result will retain the unit in which it was calculated. But... I also included an attribute (did I mention now identifiers can have attributes? anyway...) that is simply a flag "force unit". If this attribute is set, the result will be hard-converted to the preferred unit after automatic evaluation of the formula.

You can also "tweak" intermediate values without removing the formula (this you cannot do in Excel, if you write a value, you lose the formula). On your example, if we add:

Code:

'C^2' 'D...Defn' SPROP

And then we do 5 'C' STO, we are tweaking the value of C, which is an intermediate value resulting from 'A+B' to the value 5, which would recalculate 'D'. This leaves the solution in an inconsistent state, since now 'C' is not 'A+B', but is quite useful when you know what you are doing.

All this means one thing: you don't have anything to worry about (un-mix your feelings and relax). If you don't define any 'Defn' properties, your variables will behave like good old 50g, and nothing automatic will ever happen.

Also, there will be a global system flag to disable automatic evaluation. And finally, I need to figure out a way to break out of infinite recursion in the evaluation (or this thing will loop ad-infinitum if you create a circular reference in your problem), but I'm close to a solution there.

[The Shadow]

Claudio,

Wow. That's really interesting, it's going to take me a bit to wrap my head around it.

So given that we stored 5 in C like you said, if we then changed B to 3, C would change to 4 and D to 16, right?

EDIT: How does one examine the properties of a variable?

And how do the attributes of identifiers differ from properties?

[The Shadow]

Another thing:

If C initially has a Defn of 'A+B' and I later change it to 'A+P', I assume the dependency is removed from B?

Does that mean the calculator first scans 'A+B' to determine what to remove, then scans 'A+P' to determine what to add? So A gets altered twice?

EDIT: Oh! Are tagged objects just going to be a property or attribute now?

Can the user create new properties, or are they all hard-coded?

[3298]

I can't help but wonder: how is this system different from the stock firmware's less awkward way of storing the symbolic object 'A+B' into C? Do 'C' RCL, you get the symbolic back; Do 'C' RCL EVAL or simply C, you get the result of A B +.
For the forms, I'd just insert an EVAL into the decompile-for-display part (a message handler in SysRPL on the stock firmware, assuming "Forms framework" ~= "INFORM" or rather the SysRPL version "FPTR2 ^IfMain"), that should do what you describe; the preferred units can be done in there too. It just needs exposing to UserRPL. Am I missing something?

[pier4r]

as far as I understood the computation goes in another part of the variable.

Is like the variable is a structure that can hold several values, one of it would be the computed value over the other variables.

The advantage is not really seen with only 2 vars.

Say: A=5, B=6, C='A+B'
Then I can modify A (or/and B) and recall C to get the value.

But when I have:
A=5, B=6, C='A+B' , D='C*C' , E='D*D*D+A'

In userRPL I modify A (and/or B) then I need to recall C, store it somehow (say "bye" to the symbolic part). Then recall D, store it as a value, then recall E, store it as a value.
And the symbolic parts are lost unless I create programs.

The idea of claudio is way more handy in my opinion, especially building a sort of "live" equation library.

One point is, as Claudio partially wrote, that such system may become a burden, even without cycles. Unless the user is warned each time too many variables are interlinked, it can happen that tens/hundreds of other variables gets affected by each modification. I am not sure how quick newRPL can go through updating tens/hundreds of other variables.

[3298]

I just typed your example into a 50g (well, technically x49gp since I'm also currently developing a patch series for it, but who cares), and found that my memory failed me: an unquoted variable does not automatically EVAL a contained symbolic.
On the other hand, EVALing the symbolic does recurse, i.e. 'E' RCL EVAL returns 1771566 (and it doesn't matter if A and B are reals or integers). If I store 1 into A, the result of 'E' RCL EVAL will be 117650. Nothing was stored back on the previous evaluation of E when A was still 5.
Even better, if I purge A, then 'E' RCL EVAL returns the symbolic 'A^6+36*A^5+540*A^4+4320*A^3+19440*A^2+46657*A+46656'. When this would be encountered in a form, it would be quite obvious from this that A is missing.
Circular references are detected too: I stored '5+E' into A and tried to do 'E' RCL EVAL. Result: "EVAL Error: Circular Reference"
(Edit: all of this was done on the stock firmware, but it's so basic that I would be surprised if newRPL was incompatible.)

I get the impression you're thinking of the new EVAL1, but EVAL is still there.

What I'm trying to say is this: There's no need to invent a new system, all the pieces are already there. In a solver form, show the result of <variable> EVAL instead of the variable itself (and preferably catch errors such as the circular reference one, giving them special treatment such as displaying the error text in place of the result). Job done.

[Claudio L.]

(04-05-2018 11:06 AM)3298 Wrote:  What I'm trying to say is this: There's no need to invent a new system, all the pieces are already there. In a solver form, show the result of <variable> EVAL instead of the variable itself (and preferably catch errors such as the circular reference one, giving them special treatment such as displaying the error text in place of the result). Job done.

All the things you mentioned from the 50g are already implemented and functioning fine on newRPL. But I don't think you quite got the concept of the automatic evaluation. It works like a spreadsheet, if you named each cell with a variable name. For physics and engineering it works quite well. I've been using it for years for example to calculate reinforcement bars on concrete sections.
On a separate directory you place the variables for the particular problem you are trying to solve, and without any interface other than the VARS menu, you can assign values to the variables and inspect the results instantly. There is not "hundreds" of variables, as each problem template is a separate group of variables, even for complex problems it will be in the tens of variables.
Imagine that you have a cannon, with an initial velocity 'V' and angle 'a' from the horizontal, you want to compute max. distance it reaches, total time of the flight, maximum height, etc.
You end up with several variables:
Vx=V*cos(a)
Vy=V*sin(a)
t=2*Vy/g
hmax=1/2*g*t^2
xmax=Vx*t

Just store them all as formulas, and each will be automatically computed, with proper units if you want, each time you change V or a you can instantly check hmax, xmax, etc.

[pier4r]

(04-05-2018 11:06 AM)3298 Wrote:  What I'm trying to say is this: There's no need to invent a new system, all the pieces are already there. In a solver form, show the result of <variable> EVAL instead of the variable itself (and preferably catch errors such as the circular reference one, giving them special treatment such as displaying the error text in place of the result). Job done.

Uh. All those years and I was mislead by few experiences I made. I just tested it myself and you are right . Somehow I completely forgot how symbolic holds. And yes the system goes through the variables as well. Amazing feature that I failed to see.

That for formulas or systems is awesome. Rpl never stops to amaze me.
And wonder if the Casio/ti do the same.

The only difference with the idea of Claudio is that you need to explicitly eval this or that variable, instead with Claudio's idea you get the computation immediately

[Claudio L.]

(04-04-2018 11:53 PM)The Shadow Wrote:  So given that we stored 5 in C like you said, if we then changed B to 3, C would change to 4 and D to 16, right?

Correct.

(04-04-2018 11:53 PM)The Shadow Wrote:  EDIT: How does one examine the properties of a variable?

Just RCL the name of the property:

Code:

'C...Defn' RCL

(04-04-2018 11:53 PM)The Shadow Wrote:  And how do the attributes of identifiers differ from properties?

Attributes are flags (on/off) that are stored with an identifier, not necessarily with a variable.
Properties are like hidden variables that can contain objects and are stored in the same directory as their "owner" variable. They are purged when the main variable is purged.
Attributes are part of the identifier object (a 32-bit word, so up to 32 flags). This will in the future be used for the CAS, for example to do REALASSUME on a variable in an expression, it is enough to set the attribute on every appearance of the identifier in the expression, so even though the variable may not exist, the CAS knows it's a real variable, and that knowledge is embedded in the symbolic expression. Another use may be for example a flag that marks a variable as a Matrix (within an expression), therefore the CAS can never use the commutative property of multiplication to simplify a formula, for instance INV(A)*B*A could be simplified as B unless you specifically set A attribute as a Matrix (EDIT: and B as a Matrix as well, if B is marked as real, then the CAS should simplify to B*I, but you get the idea) .

(04-05-2018 04:21 AM)The Shadow Wrote:  If C initially has a Defn of 'A+B' and I later change it to 'A+P', I assume the dependency is removed from B?

Correct.

(04-05-2018 04:21 AM)The Shadow Wrote:  Does that mean the calculator first scans 'A+B' to determine what to remove, then scans 'A+P' to determine what to add? So A gets altered twice?

No, they way I implemented (just finished that yesterday) there's a single modification of A. I exploded 2 lists of variables: the old dependencies and the new dependencies. I scan the old dependency list, get all items except the variable being removed, then check if the variable is also in the new dependency list, add it at the end and then store the new dependency. At this point the variable is removed from the new dependency list.
Then it goes over the new dependency list (or what's left of it) to take care of dependencies that are new.

(04-05-2018 04:21 AM)The Shadow Wrote:  EDIT: Oh! Are tagged objects just going to be a property or attribute now?

No, the tag hasn't been implemented yet, but will be similar/compatible with the 50g. Just an object that contains a tag and an object.

(04-05-2018 04:21 AM)The Shadow Wrote:  Can the user create new properties, or are they all hard-coded?

Yes, you are free to create any properties. A few names like 'Defn', 'Depn', 'Unit', and possibly others have a specific use by the system (you are still free to purge them and manually modify them at will, and at your own risk). The logic and use of them is up to the user.

(04-06-2018 06:00 AM)pier4r Wrote:  Uh. All those years and I was mislead by few experiences I made. I just tested it myself and you are right . Somehow I completely forgot how symbolic holds. And yes the system goes through the variables as well. Amazing feature that I failed to see.

That for formulas or systems is awesome. Rpl never stops to amaze me.
And wonder if the Casio/ti do the same.

Yes, there's nothing wrong with the old ways, and they will remain as-is on newRPL too. Nothing has or will change that, the user won't feel any difference unless they explicitly choose to store a formula as the 'Defn' property on a variable rather than the variable itself.

(04-06-2018 06:00 AM)pier4r Wrote:  The only difference with the idea of Claudio is that you need to explicitly eval this or that variable, instead with Claudio's idea you get the computation immediately

Exactly, the new method creates quick templates for repetitive problems, even from the VARS menu, you change a variable typing the new value and using Shift-[menu key] to store it, and instantly see the various results by pressing another menu key, really practical, one keystroke.

[David Hayden]

I agree with 3298: this is reinventing core functionality that already exists. It isn't hard to press EVAL after executing the symbolic function. If you don't want to press EVAL, then just define the variables as programs instead of symbolics.[/align]

[Claudio L.]

(04-05-2018 11:06 AM)3298 Wrote:  In a solver form, show the result of <variable> EVAL instead of the variable itself (and preferably catch errors such as the circular reference one, giving them special treatment such as displaying the error text in place of the result). Job done.

Problem is, to display an interactive form like that you'd have to cache the results somewhere, or you'd be re-evaluating the variables each time you redraw the form. The way I'm proposing minimizes evaluations, which happen only when input data is modified. The idea is that this eliminates the need for the Forms engine to do any evaluation or even caching, effectively separating the presentation/interaction engine from the computation engine.

[Claudio L.]

(04-06-2018 02:00 PM)David Hayden Wrote:  I agree with 3298: this is reinventing core functionality that already exists. It isn't hard to press EVAL after executing the symbolic function. If you don't want to press EVAL, then just define the variables as programs instead of symbolics.[/align]

It's not just pressing EVAL on each result you want to see, it's also storing that result for later use/display, so it's EVAL '...' STO, for each intermediate variable or result.
Spreadsheets wouldn't be so popular if you had to select each cell, evaluate manually every time, and memorize the result or write it down on paper because it's temporary. Even on the 50g (and the Prime as well) people always asked for spreadsheet functionality. This is it, just on a different presentation. I guess you could create a Form with rectangles, call each variable 'A1', 'A2', etc. and work like a spreadsheet. For now, this is the computation engine that drives it. The presentation will be done later.

[pier4r]

(04-06-2018 03:41 PM)Claudio L. Wrote:  It's not just pressing EVAL on each result you want to see, it's also storing that result for later use/display, so it's EVAL '...' STO, for each intermediate variable or result.

Yes, this is huge. I concur.

It is like I need a VARS EVAL in one dir every time I change something.

edit: no, TVARS picking only VARS that store symbolic/equation stuff.

[The Shadow]

I *really* like the identifier attributes, they seem quite elegant. How do you set them? Will all 32 be reserved for the system?

Also, what's the syntax of RULEMATCH and RULEAPPLY? Will rules be able to set attributes of results? If so, I think I see how to deal with, say, octonion math with relatively simple programming.

[Claudio L.]

(04-12-2018 11:28 PM)The Shadow Wrote:  I *really* like the identifier attributes, they seem quite elegant. How do you set them? Will all 32 be reserved for the system?

Also, what's the syntax of RULEMATCH and RULEAPPLY? Will rules be able to set attributes of results? If so, I think I see how to deal with, say, octonion math with relatively simple programming.

For now you don't set the attributes, the system will set them as needed (in the future, REALASSUME, and similar commands will change these attributes). Since there's no CAS yet, I don't know how many will be needed, if there's any extra, of course the user would be able to set them/clear them at will. For now I don't know, I'm slowly building the framework for the CAS, not the CAS itself yet.
There should be a thread on rules somewhere. But I never completed the algorithm, so it only does primitive replacements. Rules are symbolic expressions with a left part and right part, separated with the :-> operator (colon and right arrow).
They are meant to work as a search/replace pair
'X:->Z+1' will search for X and replace it with Z+1 when you APPLY the rule. That's done so far. The left expression can be more complex, and will do a match on the structure of the expression.
What's not done is the advanced stuff: using variables that start with a dot on the left expression would match a generic pattern and assign it to them, then the subexpression is replaced when you use the same dot variable on the right side.
For example:
'(.X+1)^2 :-> 2*(.X+1)*DERIV(.X)'

would find (Z/2+1)^2 and would replace it with 2*(Z/2+1)*DERIV(Z/2)

But alas, the algorithm as it is doesn't work, needs a complete rewrite.
At the time I thought of specifying constraints for the match in the name of the variable, for example to match only a numeric expression you would write '.X_N' or something like that. This would cause the engine to only match .X with a number. Now I think it could be attributes, but attributes are not visible so it becomes less readable.
Using attributes, you'd write the rule using '.X' and then use attribute commands to make '.X' a real number constant in the rule expression. But when you read the expression on the screen, you don't see the attributes so it's not immediately evident that the rule will only match numbers, so perhaps is not a good idea.
In any case, it will be a while before I get my hands on the CAS again.

[compsystems]

Hello, I am testing the converter examples, from natural notation to RPN, each string of characters to be evaluated should I write OBJ->, please Claudio add on the simulator a new submenu "Paste to level 1 and Evaluate"

Stack/Paste to level 1 > Paste to level 1 and Evaluate

Thanks

[Claudio L.]

(04-28-2018 02:04 PM)compsystems Wrote:  Hello, I am testing the converter examples, from natural notation to RPN, each string of characters to be evaluated should I write OBJ->, please Claudio add on the simulator a new submenu "Paste to level 1 and Evaluate"

Stack/Paste to level 1 > Paste to level 1 and Evaluate

Thanks

I don't think it's needed. If your clipboard contains text, you paste text, if it's objects, you get objects. If you want to convert text to objects, it's up to you to do it. Put << STR-> >> on a variable and keep it visible on the menus, one keystroke will do what you need.

[compsystems]

a solution is what you propose, put a function called STR-> but the idea is that it is generally available, it is very common to write RPL code in external text editors and then paste them on the stack or paste them and execute them.



As the virtual keyboard is not yet functional, then please include the CATALOG sub-function to quickly locate the commands

Thanks.