Negate an equation:

[DrD]

A program is presented a list of equations: L0:={"x+y<=3","y<=9","c=-x-y"};

It is desired to change the signs of each of the terms in the third (string) element: L0(3) ==> "c=-x-y" which needs to become "-c=x+y"

How would you go about it?

[compsystems]

eqs:={"x+y<=3","y<=9","c=-x-y"};
expr("neg("+eqs[3]+")"); returns -( c == (-x-y) ) this is a bug?

I do not know why change = to ==, Alters the expression, and becomes a comparison, affecting the logic of an algorithm,
simplify(Ans); returns 0 (false)

should be
eqs:={"x+y<=3","y<=9","c=-x-y"};
expr("neg("+eqs[3]+")"); returns -( c = (-x-y) )
simplify(Ans);
-c = -(-x-y)
-c = (x+y)

[DrD]

compsystems, thanks for trying. Unfortunately, your procedure doesn't meet the objective: "-c=x+y"

In general, I was hoping to find a more direct way to convert between a string object version of a function, and the function object, (and retain the result as a string object). For example, this works as specified, but is quite cumbersome:

STRING(-CAS("left(CAS(L0(3)))")=simplify(-CAS("right(CAS(L0(3)))")));

Better ways and means probably exist, and I just haven't stumbled upon them so far. Somehow, it seems like there would be a built in command for interacting with functions as string objects. I would appreciate other ideas, since I seem to encounter this problem quite a bit. Working with a "string function" can be a way to get around problems resulting from undesired evaluation steps; in programs, for example.

[Didier Lachieze]

Have you tried: STRING(-expr(L0(3))) ?

Edit: the command above works in CAS but not in Home, in Home you need to do: STRING(CAS("-expr(L0(3))"))

[DrD]

Well, I tried many similar variants, but not precisely that ... I was hoping you would set me on the right path! For one thing, I was using EXPR, not expr, and it doesn't work with the upper case version. I like your method much better than the long winded version I've shown.

There is one other thing, it turns out that the last function in the list is the only one needing change of signs. So, in general, I can use something like:

L0(SIZE(L0));

To reach the objective in any size list of string elements. However that approach doesn't work in the CAS world, frustrating something like this:

STRING(CAS("-expr(L0( SIZE(L0) ))"));

This WILL work, however:

N:=SIZE(L0);
STRING(CAS("-expr(L0(N))"));

Would you have any thoughts on how to adapt your excellent method to any size list, in general?

[Didier Lachieze]

You can use L0(0) to access to the last element of L0.

[DrD]

Yes, I had forgotten about that. That is very helpful. Thank you!

[Han]

Be careful when evaluating a symbolic object (represented as a string) within a program whether it be through CAS() or EXPR().

Code:


export localwarning()
begin
local x:=1;
L0:={ "x^2+y^2=r^2" };
return(string(CAS("-expr(L0(x))")));
end;

There is no bug, but you should check whether the answer is what you wanted. If not, you'll need to create your own myEXP() and myCAS() functions when dealing with indirection and undefined variables. The expressions stored as strings in L0 will be evaluated, and therefore inherit whatever values are present as local variables inside the calling function. Since x was used here in our calling program (set to 1), then any expression parsed via EXPR() and CAS() will be evaluate x to 1 -- including the instance where the string is parsed into a symbolic expression. The short solution is to not use x or y or c in your calling program. However, a generalized approach would stead call CAS() or EXPR() without ANY local variables defined, except for possibly the variable used to pass the string (which you hope and cross your fingers does not exist inside the string itself).

Code:


begin myCAS(casString)
  return(CAS(EVAL(casString)); // cross your fingers that casString is itself not a sequence of characters in the variable casString
end;

No local variables (other than 'casString') are used in the myCAS() calling program so your chances of having your string/expression modified by pre-existing local variables is next to none. The EVAL() is needed because CAS commands treat their arguments as being literal.