CAS command question

[DrD]

CAS commands left() and right() are described to return the left or right side of an expression.
(With assurance I can say that these two CAS commands are bug free).

Going confidently forward :

Here is a list of string object expressions in L9, such that a polynomial is always on the left side, and a constant is always on the right side. For each of the expressions, using the CAS left() command results in list L8, the left side of each expression. Since the CAS left() and right() commands operate correctly, the program result, L8, assuredly, contains the polynomials that are on the left, right?
(using the CAS right() works equally well.)

Snippet: L9:={"x+y=4", "x+y>4","x+y>=4","x+y<4","x+y<=4"};
Left side of L9 expressions (and don't bet your life on it ...): L8 ==> {x+y,x+y,x+y,4,4}

Discussion is welcome.

Code:


EXPORT lefty()
BEGIN
  L8:={};L9:={"x+y=4", "x+y>4","x+y>=4","x+y<4","x+y<=4"};
  //  Make a list of ->left side<- ONLY for expressions in L9
  FOR I FROM 1 TO SIZE(L9) DO
    L8(I):=CAS("left(CAS(L9(I)))");  
  END;   
END;

-Dale-

[Arno K]

As left is left and right is right this is a serious bug.
Arno

[parisse]

This is not a bug and has nothing to do with left and right, it's because evaluation rewrites inequation with >= or >. If you enter x<2, it is evaled as 2>x.

[Arno K]

So the command simply needs another name.

[DrD]

Parisse,

1. I probably don't understand the real purpose of those two CAS commands. Can you explain further? (ex: Compared to the similar commands in TI-Basic?)
http://tibasicdev.wikidot.com/68k:left

2. If the intent IS to return the indicated side of an expression or interval, why was it necessary to first evaluate the expression?

3. If it is NOT necessary to first evaluate the expression, would you consider changing that behavior for the next release?

4. Is there an alternative built in command that WILL return left or right sides, or even better, a list of the left and right sides of an expression?

Thank you.

-Dale-

[parisse]

Suppose you store your equation in a variable a:=(x+y=4), then you expect left(a) or right(a) not to error. The general rule is to eval arguments and leave the user quote himself if he requires, because once the system autoquote arguments, there is no way for the user to eval them.
According to the Prime online help, left and right return the left/right part of an equation or interval (Xcas documentation adds strings). Inequations are not cited. The only change I could make would be to error on inequations to prevent unadvertised users from being surprised, but I'm not sure everybody would like that (therefore I would do it for the Prime only).

[matthiaspaul]

(01-03-2017 07:24 AM)parisse Wrote:  it's because evaluation rewrites inequation with >= or >. If you enter x<2, it is evaled as 2>x.

Hm, but why is that? I see possible reasons for this from a programmer's point of view, but from a user's perspective I would find it counter-intuitive.

A possible solution for the above presented left() / right() issue could be to either not swap the sides here, or, if this can't be avoided, to set an internal flag which would "swap" the left() and right() functions as well, so that they would return what's intuitive from a user's perspective. If having functions with the currently implemented behaviour would be desirable to have as well, they could be introduced under less ambiguous function names (TBD).

Greetings,

Matthias

[compsystems]

What is the reason for "reverse" expression (transposing terms and reverse the operator)? (some help for the parser or interpreter of expressions), in my case I do not like as the hp-prime shows, books do not show this notation, is somewhat confusing for to read.
(x+y)< 4 →
4>(x+y)

Examples of how to use the command LEFT & RIGHT

PHP Code:

// simplify none
#cas
  
  testleftcas():=
  begin
   local expr1;
    //local expr1:='(x+y)<4';  =(
    expr1:='(x+y)<4'  
    return([ left(expr1), left(eval(expr1)) ]);
  end;
  // testleftcas() -> [ x+y, 4 ] // ok

  testleftcas2(expr2):=
  begin
    return [ left(expr2), left(eval(expr2)) ];
  end;
  // testleftcas2( '(x+y)<4' ) -> [ x+y, 4 ] // ok
  // testleftcas2( (x+y)<4 ) -> [ 4, 4 ]    // ok

  testcas( id0 ):=
  begin
    local id1:= id0;
    print; //print("");
    print( [ left(id1), right(id1) ] ); wait;
    return ( [ left(id1), right(id1) ] );
  end;
  // testcas( (x+y)^(1+1)-3 ) -> [(x+y)^2,-3] // ok
  // testcas( '(x+y)^(1+1)-3' ) -> [(x+y)^(1+1),-3] // ok

#end 


[parisse]

Symbolic expressions are rewritten with fewer operators during evaluation because after that it's easier to handle less operators. The same happens with substraction or division: if you enter c:=a-b or c:=a/b it is evaled to a+neg(b) or a*inv(b) : try c[1] (you won't see on the display because it is easy to check that. But it is impossible to do the same for inequations, since the user could have entered 2<x or x>2).
If you are playing with symbolic expressions, you must always keep this in mind. It may look like conter-intuitive, but once you know that, your programmer task will be easier, because you won't have to handle < or <= or binary - or /

[DrD]

(01-04-2017 07:07 AM)parisse Wrote:  It may look like conter-intuitive, but once you know that, your programmer task will be easier, because you won't have to handle < or <= or binary - or /

Personally, I think that it is counter-intuitive, and that it is not easier as a programmer. My reasoning is that, intuitively, a programmer expects the left() command to always return the left side of an expression, ditto, the right().

For example, I recently created a routine to strip coefficients from an expression, needed for a coefficient matrix. A list of expressions, represented as string objects, was provided. The coeff() command was used, which required the expressions be separated into their left and right components. Counter-intuitively, this routine did not work when the inequality signs reversed. Worse than that, one might choose the wrong side command, during program testing, IF there were only "<" elements in the provided list used for input. This would typically be the case for optimality maximizing, as an example. The reason would be that the left() command would return the right side!

I hope other users will weigh in on this topic, since Parisse and I disagree on this; but who am I to effect change? This is the reason for my initial post, and could serve as an example of how user consensus might work for future improvements/enhancements for this product.

Please respond, letting us know the pros and cons from your own perspective!

-Dale-

[compsystems]

Hello Mr. Parisse

c:=a-b; [enter] Internally is a+neg(b) // ok

It's new to my, extracting parts of the expression using []
c[1]; -> +
c[2]; -> a
c[3]; -> b

Please explain, the correspondence of the position or numeral to extract the parts. thanks

for DrD
If you enter the expression in quotation marks, the LEFT or RIGHT command works as it should, the problem is that the user should always enter the parameters between ' ' =(

My question for Parisse: how is it done within a program to convert the input inside a quotation mark?

I try the following, but it does not work

PHP Code:

#cas
  helpquote( id0 ):=
  begin
    local id1;
    id1 := quote(id0); // -> 'id0' =(
    print; print(id1);

    print( [ left(id1), right(id1) ] ); wait;

    return ( [ left(id1), right(id1) ] );
  end;
  // helpquote( (x+y)^(1+1)-3 ) -> [(x+y)^(1+1),-3] //  This would be the expected output.
  // helpquote( 4/2 ) -> [4 2] // This would be the expected output.
#end 


so we would need a new CAS command called RECALL

PHP Code:

id1 := quote( RECALL (id0) ); 


Another solution would be to interpret as a QUOTE EXPRESSION, if the arguments are within quotes,

PHP Code:

helpquote( 'id0' ):=
  begin ... 


[Han]

(01-04-2017 11:19 AM)DrD Wrote:  

(01-04-2017 07:07 AM)parisse Wrote:  It may look like conter-intuitive, but once you know that, your programmer task will be easier, because you won't have to handle < or <= or binary - or /

Personally, I think that it is counter-intuitive,

Only when you are not aware of how the objects are stored internally. This would have been the same case with RPL.

Quote:and that it is not easier as a programmer.

Generally speaking, when you remove half of the cases to test, I would consider that easier. In terms of syntax, a<b is different from b>a. But mathematically, a<b is the same as b>a. By storing inequalities in a specific form (b>a rather than a<b), we reduce the syntax complexity.

Quote:My reasoning is that, intuitively, a programmer expects the left() command to always return the left side of an expression, ditto, the right().

Well, the documentation for these commands specify equalities or intervals. That they happen to not complain about other input should be the reason for complaint. Again, many examples of such behavior also exist in RPL, too (i.e. using commands to do things that were not originally considered). It just takes time to adjust to them.

Quote:For example, I recently created a routine to strip coefficients from an expression, needed for a coefficient matrix. A list of expressions, represented as string objects, was provided. The coeff() command was used, which required the expressions be separated into their left and right components. Counter-intuitively, this routine did not work when the inequality signs reversed. Worse than that, one might choose the wrong side command, during program testing, IF there were only "<" elements in the provided list used for input. This would typically be the case for optimality maximizing, as an example. The reason would be that the left() command would return the right side!

I would imagine that such code would necessarily have to detect whether the inequality was > or < and then branch accordingly. Wouldn't the complexity of your code increase as a result? If nothing else, you have more cases to handle, with the extra case(s) being very similar to existing cases.

[DrD]

(01-04-2017 12:56 PM)compsystems Wrote:  for DrD
If you enter the expression in quotation marks, the LEFT or RIGHT command works as it should ...

"Quotation marks" is ambiguous: there are single and double quotation marks. Each has it's object type, and means of handling. My example used string objects, (double quotes). However, as Arno K described, "left is left, and right is right."

left('x+y<4'); ==> x+y
left(CAS("x+y<4")); ==> 4

Referring back to my original post:

Un-intuitively, for a program, given a (perhaps random) list of expressions, those with a "<" inequality would need an exception handler. Requiring the list to be in a specific format is not user friendly. Real world expressions are unlikely to use single quotes, and further requiring them to be re-written in the specific inequality representation where the left side is always > than right side is just not practical.

Then there is the definition of the term "left" and "right," fundamentally. The similar command in Texas Instruments TI-Basic, as described here: http://tibasicdev.wikidot.com/68k:left seems better designed

Yes, Parisse explained the why of it, but as for "intuitively," I'm not so sure. What do you think?

[Han]

(01-03-2017 11:33 AM)DrD Wrote:  2. If the intent IS to return the indicated side of an expression or interval, why was it necessary to first evaluate the expression?

3. If it is NOT necessary to first evaluate the expression, would you consider changing that behavior for the next release?

Regarding 2, this has always been the behavior. A literal (symbolic) expression requires quotation (single quotes). These are left unevaluated. Otherwise, it is "evaluated" as is normally done when entering commands on the command line. Simple example:

x:=t;
x+y // returns t+y
'x+y' // returns x+y

EDIT:

Quote:left('x+y<4'); ==> x+y
left(CAS("x+y<4")); ==> 4

The second case uses evaluation. left(CAS(" 'x+y<4' ")) will return x+y

[DrD]

Hi Han!

Thanks for your insight.

First point, would you think that the internal representation is known by the typical prime programmer, or that it even should be an important factor for a relatively high level language programming environment?

Second point, I understand your thinking here. However, when the need arises, especially after some time has elapsed, a program designed to gather expressions just as they are encountered seems more practical. So requiring them to be re-written to accommodate an inequality sign 'convention' is needless extra work, and one more place for user inputs to go wrong. Not to mention that a user's mindset is probably more focused on problem solving, and simplifying the solution task is important.

Third point, It's true, inequalities are omitted, specifically. However the command set is not rich in this area, and apparently giac does further extend those commands to strings, (I used strings in the example). More than once I have needed to separate expression relations for further activities, so a command that would be able to do that has value.

Your last point IS the issue. You've identified the fact that the current command set DOES complicate programs using this technique. I think the prime could be improved by restructuring the left() and right() commands, returning the left or right side of any expression, without performing an evaluation first. A (possible) exception might be, IF the expressions are strictly numerical: 2+2 < 5., but why?

-Dale-

[DrD]

(01-04-2017 03:06 PM)Han Wrote:  

(01-03-2017 11:33 AM)DrD Wrote:  2. If the intent IS to return the indicated side of an expression or interval, why was it necessary to first evaluate the expression?

3. If it is NOT necessary to first evaluate the expression, would you consider changing that behavior for the next release?

Regarding 2, this has always been the behavior. A literal (symbolic) expression requires quotation (single quotes). These are left unevaluated. Otherwise, it is "evaluated" as is normally done when entering commands on the command line. Simple example:

x:=t;
x+y // returns t+y
'x+y' // returns x+y

EDIT:

Quote:left('x+y<4'); ==> x+y
left(CAS("x+y<4")); ==> 4

The second case uses evaluation. left(CAS(" 'x+y<4' ")) will return x+y

Whenever I hear something corporate like, "we've always done it this way," etc., it's often a good time to re-visit the issue. Is there a better way? Minimize cost, maximize profit are typical measures. In this case, Arno K's very efficient point makes a better case for the cost of evaluation when using either of these two commands.

The second case is a necessary step to reveal the enclosed expression. It runs through a program without any distinction regarding the relation's symbols. That is a distinction WITH a difference, as compared to what happens when the expression is, itself, evaluated, resulting in the left/right handedness being exchanged.

[Han]

(01-04-2017 12:56 PM)compsystems Wrote:  Hello Mr. Parisse

c:=a-b; [enter] Internally is a+neg(b) // ok

It's new to my, extracting parts of the expression using []
c[1]; -> +
c[2]; -> a
c[3]; -> b

Please explain, the correspondence of the position or numeral to extract the parts. thanks

Parisse might have more to add, but the expression[index] format is just a "list" starting with an operator followed by the arguments. For example:

eq1:=t^2+2*t-cos(t)/sin(2*t);

eq1[1]; -> '+' (operator)
eq1[2]; -> 't^2' (argument 1)
eq1[3]; -> '2*t' (argument 2)
eq1[4]; -> '-cos(t)/sin(2*t)' (argument 3)

Each argument can also be an expression that is stored similarly.

eq1[2,1]; -> '^' (seems the Prime doesn't display this; but copy it to the command line and you see an exponent)
eq1[2,2]; -> 't'
eq1[2,3]; -> 2

[Han]

(01-04-2017 03:46 PM)DrD Wrote:  

(01-04-2017 03:06 PM)Han Wrote:  Regarding 2, this has always been the behavior. A literal (symbolic) expression requires quotation (single quotes). These are left unevaluated. Otherwise, it is "evaluated" as is normally done when entering commands on the command line. Simple example:

x:=t;
x+y // returns t+y
'x+y' // returns x+y

EDIT:


The second case uses evaluation. left(CAS(" 'x+y<4' ")) will return x+y

Whenever I hear something corporate like, "we've always done it this way," etc., it's often a good time to re-visit the issue. Is there a better way? Minimize cost, maximize profit are typical measures. In this case, Arno K's very efficient point makes a better case for the cost of evaluation when using either of these two commands.

The second case is a necessary step to reveal the enclosed expression. It runs through a program without any distinction regarding the relation's symbols. That is a distinction WITH a difference, as compared to what happens when the expression is, itself, evaluated, resulting in the left/right handedness being exchanged.

My point was simply that it should not come as a surprise that the argument to any function is evaluated unless specifically quoted because that was how the system was set up. (I am not making any subjective comment about which setup is better.) On the other hand, asking for a change in the behavior of specific functions would thereby cause a "surprise" in that it would no longer conform to the rest of the system. As for why it was originally set up that way, I can only guess that they probably tried it both ways (evaluation vs non-evaluation having priority) and made their decision based the pros and cons of each case.

Regarding your comment on the second case... I'm not sure I follow. The example I gave shows how to use strings and still not have it evaluate anything -- just add ' to the start and end of the string.

EDIT: I'm not sure to which of Arno K's comment you are referring, but if you are referring to his request to rename the commands, that would seem appropriate. The commands left and right behave more like "head" and "tail" (first and last arguments of an expression) for non-unary operators.

[compsystems]

I'm sad =(, if the input list contains objects between QUOTES (L9:={ 'x+y=4', 'x+y>4', 'x+y>=4', 'x+y<4', 'x+y<=4' }; ), they should not be rewritten

THE FUNCTION 'QUOTES' IS TO MAINTAIN THE ORIGINAL EXPRESSION, AS WHICH WAS WRITTEN. OTHERWISE 'QUOTES' DOES NOT HAVE UTILITY.

PHP Code:

#cas
    lefty():=
    begin
             print; //print("");
      L8:={};
      L9:={ 'x+y = 4', 'x+y > 4', 'x+y ≥ 4', 'x+y<4', QUOTE(x+y ≤ 4) };
             print(L9); wait();
             //L9:={ x+y = 4, x+y > 4, x+y ≥ 4, x+y<4, x+y ≤ 4 };
      //  Make a list of ->left side<- only for expressions in L9
      for I from 1 to size(L9) do
        L8(I):=left(L9(I));  
      end; 
      return(L8);
      //return [L8, L9];
    end;
#end 


with L9:={ x+y = 4, x+y > 4, x+y ≥ 4, x+y<4, x+y ≤ 4 };
lefty(); => { x+y, x+y, x+y, 4, 4} // ok but no with

L9:={ 'x+y = 4', 'x+y > 4', 'x+y ≥ 4', 'x+y<4', 'x+y ≤ 4' };
lefty(); => { x+y, x+y, x+y, 4, 4} // =(
=> { x+y, x+y, x+y, x+y, x+y}

[parisse]

When you write L9:={ 'x+y = 4', 'x+y > 4', 'x+y ≥ 4', 'x+y<4', QUOTE(x+y ≤ 4) }; the right side of := is evaled, since all expressions are quoted, it will set L9 to { x+y = 4, x+y > 4, x+y ≥ 4, x+y<4, x+y ≤ 4 }, without quotes. If expressions inside the definition of L9 were not quoted, then x, y and inequations would have been evaled themselve, here they are not.
If you are writing L8(I):=left(L9(I)); then L9(I) is evaled, but this time nothing is quoted anymore and x,y and operators are evaled. You would have to double-quote the original input to avoid evaluation at this step.
DrD: you can not make something useful with a command that does not eval arguments except for a few exceptions (:= is an exemple of exception, it does not eval it's left argument). On the example above, left(L9(I)) would not do anything because L9(I) would not be replaced by the I-th element of L9.

This thread make me realize that there is probably a need to make a small FAQ about CAS expressions and evaluation (something I teach to some of my students). Unless there is already something good enough on the net, perhaps Han you know some interesting ressource? (wikipedia seems a little bit too short, Fateman's paper too long)