newRPL - build 1255 released! [updated to 1299]

[JoJo1973]

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

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.

[Claudio L.]

(07-30-2019 06:06 PM)The Shadow Wrote:  That system looks good to me! Very intuitive. I like it better than the subscripts, in fact.

I'm not quite clear on what ASSCOMB does? Is it the ASSUME string for the result of the expression?

Something like that, yes. Basically, if you present an expression like 'X^2', ASSCOMB will COMBine the attributes of X (a real number) with the attributes of 2 (a positive even integer) through the operator ^. The internal logic will determine that a real number raised to a positive even power will result in a positive real, so it will return R>=0 to let you know that expression has a specific type and domain restriction.
It's already implemented internally, I just thought it can be useful to be made external for programs to make decisions. For example if you ask the user to input a positive number, you can use ASSCOMB to see if the system can tell you that whatever the user wrote was indeed positive, all this without ever evaluating the expression.

[The Shadow]

(07-30-2019 07:13 PM)JoJo1973 Wrote:  (matrix divided by scalar it's possible, scalar divided by matrix isn't)

It's possible if you interpret it as "multiply by the inverse".

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

Very much agreed.

Quote:On a side note, the subscript notation could be phased away and supported only at source code level to add new rules.

Agreed here also. The subscripts are cumbersome to use, this is much better.

[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?

[JoJo1973]

Then why don't create an inline "ASSUME" operator (leftward arrow? U+22A6?) to attach human readable attributes to an expression e.g.

'.mX*.mX^.NN:→.mX^(1+.NN) ⊦ .NN:Z≥0,.mX:E>0'
'X+2=1-Y ⊦ Y:R<0'

Attributes are always displayed in certain contexts (e.g. edit), but a flag controls visibility in remaining ones (e.g. stack).

The ASSUME command is even more useful this way, because it allows a quick change of attributes: a boon for debugging and try-and-see approach.

[Claudio L.]

(07-30-2019 09:14 PM)JoJo1973 Wrote:  Then why don't create an inline "ASSUME" operator (leftward arrow? U+22A6?) to attach human readable attributes to an expression e.g.

'.mX*.mX^.NN:→.mX^(1+.NN) ⊦ .NN:Z≥0,.mX:E>0'
'X+2=1-Y ⊦ Y:R<0'

Attributes are always displayed in certain contexts (e.g. edit), but a flag controls visibility in remaining ones (e.g. stack).

The ASSUME command is even more useful this way, because it allows a quick change of attributes: a boon for debugging and try-and-see approach.

Sounds good to me, but are you sure that's the correct symbol?

https://en.wikipedia.org/wiki/Turnstile_(symbol)

[JoJo1973]

(07-30-2019 10:07 PM)Claudio L. Wrote:  Sounds good to me, but are you sure that's the correct symbol?

https://en.wikipedia.org/wiki/Turnstile_(symbol)

To be honest, I just browsed the math code page and code the symbol with the most appropriate name for the function.

Wikipedia page mentions two code points for the turnstile symbol, the one I chose being one of them. Sincerely I can't tell why there's the need for two similar symbols - probably a legacy issue.

[JoJo1973]

Would it make sense to enforce assumptions at EVALuation?

Suppose I have this expression on the stack:

'X+1' whereas X:Z∞

Now I store 0.5 in X and EVAL the expression above. Should it error out with "Wrong Assumptions" or similar, or not?

[Claudio L.]

(07-31-2019 10:45 AM)JoJo1973 Wrote:  Would it make sense to enforce assumptions at EVALuation?

Suppose I have this expression on the stack:

'X+1' whereas X:Z∞

Now I store 0.5 in X and EVAL the expression above. Should it error out with "Wrong Assumptions" or similar, or not?

I think that would count as "nagging" :-). If I want to store 0.5 in X without rewriting my expression the last thing I want is the calc complaining that I have to do more work...
On the other hand, those "hints" are more for the symbolic manipulation of the expression than for evaluation, I see them as 2 completely different things.

What you want is more in line with the "given that" operator |.
We could use the same operator and have 2 different uses:
'X+1 | X:→4' would enforce X=4. This fixed substitution would take place before any of EVAL, RULEAPPLY, or AUTOSIMPLIFY (notice that X:→4 is nothing but a rule being applied prior to any other manipulation) so X would automatically be treated as an even positive integer number and would match all the rules for numbers.
After EVAL, RULEAPPLY or AUTOSIMPLIFY, the rule X:→4 and the operator | will be removed from the expression, since the substitution will have been done.
'X+1 | X:Z∞' would simply add hints to variable X without providing a specific value. Hints work only during symbolic manipulation, if a global variable X exists during evaluation, it will be replaced and there's no reason to enforce the hints.
After EVAL, RULEAPPLY or AUTOSIMPLIFY, the hints will still be there, rules will be gone (already applied).


EDIT: Actually, the operator | should have 3 different uses: enforcing rules, applying hints and providing constraints (equalities, inequalities, etc.), like 'X+Y+1 | X+Y>4'
I think inequalities can be handled with variable substitution:
A>B means A-B>0 (here A and B are arbitrary expressions, not variables), so we can substitute a=A-B (here 'a' is a variable) and therefore apply a rule A:→a+B
Then we can hint a:R>0 so the rules engine knows all the information the inequality provided.
Finally, after all is done (RULEAPPLY, AUTOSIMPLIFY, whatever), apply the inverse substitution: a:→A-B

[JoJo1973]

(07-31-2019 02:15 PM)Claudio L. Wrote:  EDIT: Actually, the operator | should have 3 different uses: enforcing rules, applying hints and providing constraints (equalities, inequalities, etc.), like 'X+Y+1 | X+Y>4'
I think inequalities can be handled with variable substitution:
A>B means A-B>0 (here A and B are arbitrary expressions, not variables), so we can substitute a=A-B (here 'a' is a variable) and therefore apply a rule A:→a+B
Then we can hint a:R>0 so the rules engine knows all the information the inequality provided.
Finally, after all is done (RULEAPPLY, AUTOSIMPLIFY, whatever), apply the inverse substitution: a:→A-B

Yes, the "given" operator fits perfectly the role. The issue of inequalities is an interesting one, especially for hyperbolic functions such as LN and EXP where constraining the argument about 1 rather than 0 is often seeked.

[The Shadow]

(07-31-2019 06:07 PM)JoJo1973 Wrote:  Yes, the "given" operator fits perfectly the role. The issue of inequalities is an interesting one, especially for hyperbolic functions such as LN and EXP where constraining the argument about 1 rather than 0 is often seeked.

Not really an issue, unless I'm missing something:

'LN(X) | X>1' is the same as 'LN(X) | X-1>0'. For that matter, it's the same as:

'LN(X+1) | X>0'

[Claudio L.]

(07-31-2019 07:08 PM)The Shadow Wrote:  Not really an issue, unless I'm missing something:

'LN(X) | X>1' is the same as 'LN(X) | X-1>0'. For that matter, it's the same as:

'LN(X+1) | X>0'

That's exactly what I had in mind, you simplified in 2 lines what took me a couple paragraphs to describe... you could probably code newRPL in half the size!
The thing is, if the system does an internal (transparent) variable substitution as you and I described, the current framework (which has only hints that can be >0 =0 or <0) works without modification, hence little additional effort for me to code it.
Following your example, the user provides 'LN(X) | X>1', the system internally converts it to 'LN(X+1) | X:R>0' and now the rules engine can use those hints to infer for example that the result of X+1 if X is R>0 is another R>0, therefore its LN(R>0) is Real otherwise the result would have to be assumed complex. The rules engine is not smart enough to know if (X+1)>1 (which could help refine the scope of LN() by saying if the result is R>=0 or R<0, because that requires to actually compute the expression X+1 or simplify the expression (X+1)-1, neither of them can be done from within the rules engine.

[root07]

Do you plan to port this firmware to HP 39gii?

[Claudio L.]

(08-02-2019 11:03 AM)root07 Wrote:  Do you plan to port this firmware to HP 39gii?

Unfortunately, no. There's very few 39GIIs out there, it was a rare and quite short lived model. The hardware is very different from all other calculators so it would be just as hard as porting it to any other unknown platform (unlike the 50g hardware which was common to several models, with next to no effort I was able to support the 50g, 39gs and 40gs, as well as the 49g+ despite a current draw issue that's still unresolved).
The next target will be the HP Prime hardware, whether it will be G1 or G2 is still in flux, it seems G1 will be easier but it's already out of production (so it's no more alive than the 50g platform), and G2 apparently can't be done without hardware mods, which means even if newRPL gets released very, very few people will mod their calcs.
So for now all we can do is move forward with the hardware we have working, and plan for the next port if the opportunity arrives.

[The Shadow]

What sort of hardware mod to the Prime G2 would be necessary? It's getting more and more expensive to get 50g's.

[The Shadow]

Claudio, it might be worth looking at the PDQ algorithm as a replacement for the ->Q algorithm currently in use. Not only will it fix the "overshooting" problem I mentioned a while back, but it has other desirable properties. (Naturally for use in ->Q the tolerance would be taken from the system settings and one wouldn't bother calculating the error. But the full-blown PDQ might make a worthy command in its own right.)

[Claudio L.]

(08-02-2019 07:57 PM)The Shadow Wrote:  Claudio, it might be worth looking at the PDQ algorithm as a replacement for the ->Q algorithm currently in use. Not only will it fix the "overshooting" problem I mentioned a while back, but it has other desirable properties. (Naturally for use in ->Q the tolerance would be taken from the system settings and one wouldn't bother calculating the error. But the full-blown PDQ might make a worthy command in its own right.)

I like it! I hope Joe doesn't mind if his algorithm ends up being ported to newRPL, I'll make sure to provide proper attribution for the algorithm in the source code.

[JoJo1973]

(08-03-2019 12:13 AM)Claudio L. Wrote:  

(08-02-2019 07:57 PM)The Shadow Wrote:  Claudio, it might be worth looking at the PDQ algorithm as a replacement for the ->Q algorithm currently in use. Not only will it fix the "overshooting" problem I mentioned a while back, but it has other desirable properties. (Naturally for use in ->Q the tolerance would be taken from the system settings and one wouldn't bother calculating the error. But the full-blown PDQ might make a worthy command in its own right.)

I like it! I hope Joe doesn't mind if his algorithm ends up being ported to newRPL, I'll make sure to provide proper attribution for the algorithm in the source code.

Well, nothing prevents from having the best of both worlds: a full-blown PDQ and a ->Q command which is just a wrapper around PDQ, accepting a real number and returning a fraction.

[Francois Lanciault]

(08-02-2019 02:29 PM)Claudio L. Wrote:  The next target will be the HP Prime hardware, whether it will be G1 or G2 is still in flux, it seems G1 will be easier but it's already out of production (so it's no more alive than the 50g platform), and G2 apparently can't be done without hardware mods, which means even if newRPL gets released very, very few people will mod their calcs.

I would :-)

François

[The Shadow]

(08-03-2019 12:13 AM)Claudio L. Wrote:  

(08-02-2019 07:57 PM)The Shadow Wrote:  Claudio, it might be worth looking at the PDQ algorithm as a replacement for the ->Q algorithm currently in use. Not only will it fix the "overshooting" problem I mentioned a while back, but it has other desirable properties. (Naturally for use in ->Q the tolerance would be taken from the system settings and one wouldn't bother calculating the error. But the full-blown PDQ might make a worthy command in its own right.)

I like it! I hope Joe doesn't mind if his algorithm ends up being ported to newRPL, I'll make sure to provide proper attribution for the algorithm in the source code.

Great! Also, please consider exposing the "ISQR" and "CF~I2" commands to the user, they are of considerable interest. Though I'd recommend having the latter output a symbolic fraction rather than a pair of integers (and therefore changing its name to something like "QXCF".) The former might be more clear if named "ISQRT" too.