serious problem in Xcas

[fhub]

Hi,

while defining some own functions in Xcas (Windows version) I've found a serious problem -
let me give 2 examples:

Code : Tout sélectionner

diftest(f,x):={
  return(diff(f,x));
}

This function is ok, it returns the expected results:
diftest(x^2,x) --> 2*x
diftest(a^2,a) --> 2*a

And now the same with 'integrate':

Code : Tout sélectionner

inttest(f,x):={
  return(integrate(f,x));
}

Unfortunately calling this function works only for the variable x:
inttest(x^2,x) --> x^3/3
but
inttest(a^2,a) --> a^2*x (???)

It seems that the function 'integrate' does not evaluate the integration variable (x)
when it is used within a function definition, but always uses its unevaluated name.
So it's in fact impossible to use the 'integrate' function in own programs or functions,
which should also work for other variables (given as argument to this program or function).

If this is not a bug but an intended behaviour (and I'm overlooking something),
then please let me know.

Regards,
Franz

[parisse]

integrate does not evaluate it's second argument so that it works even if the integration variable has a value (I just realize that this feature does not work currently, I'm going to fix that). This has indeed a side effect, you must either always use the same symbolic variable or subst the actual integration variable by a local integration variable

Code : Tout sélectionner

inttest(f,x):={
 local y;
 assume(y,symbol);
 f:=subst(f,x,y);
 f:=integrate(f,y);
 f:=subst(f,y,x);
}

[fhub]

This has indeed a side effect, you must either always use the same symbolic variable or subst the actual integration variable by a local integration variable

Oops, that's indeed a bit strange (and uncomfortable), I don't know any other CAS where this has to be done in such a complicated way - quite dangerous if you don't think of this when writing Xcas procedures.
And furthermore it's rather inconsistent, because why should there be any difference between 'integrate' and 'diff' (where it's working as expected)?

BTW, I discovered this problem while I wrote a short function for solving a 1st order ODE with linear substitution
(i.e. for y'=f(ax+by+c)), which was discussed in the HP-forum a few days ago.
You mentioned that you might implement this special type, but since it's not yet in the latest Xcas I've made the following function myself:

Code : Tout sélectionner

deLinSubst(f,x,y):={
  local k,c_0;
  purge(c_0);
  k:=simplify(diff(f,x)/diff(f,y));
  if (diff(k,x)<>0 or diff(k,y)<>0) return("No linear substitution!");
  f:=simplify(solve(subst(integrate(1/(subst(f,y=y-k*x)+k),y),y=y+k*x)=x+c_0,y));
  if (dim(f)==1) f:=f[0];
  return(f);
}

Works perfectly for the example y'=(x+y)^2 from the HP-forum:
deLinSubst((x+y)^2,x,y) --> tan(x+c_0)-x

Franz

[parisse]

Well, I don't think it's a good idea to change that now, but I can add the following syntax
int(expr,unquote(var))
I have now added the piece of code for desolve. Will be available probably next week...

[fhub]

Well, I don't think it's a good idea to change that now, but I can add the following syntax
int(expr,unquote(var))

I don't know what you mean with this 'unquote'.
Well, I don't think changing this strange behaviour of 'integrate' (i.e. let it evaluate also its 2nd argument) would have any side-effects, but what about the following idea:
Evaluate the 2nd argument, and if it is a plain variable name then use this (evaluated) name, else use the unevaluated 2nd argument (as it does currently).
With this method 'integrate' would behave like 'diff' (and like probably 99% of all CAS users would expect it).

Franz

[parisse]

But x may be assigned to say 3, a or a+1. If it's 3 or a+1, then it's clear it should not be evaluated. But how do you make the difference between a as integration variable or as a polynomial of degree 1 depending on a parameter ? You can't.
It's better to have something special for that. With the change I made this evening, your function will look like this:

inttest(f,x):={
return(integrate(f,unquote(x)));
}

unquote is an inert function that indicates the argument should not be auto-quoted. It is already recognized by :=, try this
a:=x
unquote(a):=3
will assign 3 to x (and not 3 to a like a:=3 would do).

[fhub]

But x may be assigned to say 3, a or a+1. If it's 3 or a+1, then it's clear it should not be evaluated. But how do you make the difference between a as integration variable or as a polynomial of degree 1 depending on a parameter ? You can't.

Well, 2 remarks:
1) exactly the same reason would then also be applicable to 'diff', so why no evaluation for 'int', but evaluate the argument for 'diff'?
2) at the end the user (of Xcas) should have to decide (and is responsible for) what he wants as integration variable,
and if he really enters any nonsense for it: "wrong input --> wrong output" is valid for every program.

But of course Xcas is your project, so you can do it however you want it.

It's better to have something special for that. With the change I made this evening, your function will look like this:

inttest(f,x):={
return(integrate(f,unquote(x)));
}

Yes, that's a possibility, but then it would even be easier to define an own function (e.g. 'integ') with the "substitute, integrate and re-substitute" method, and always use this own function instead of the original 'integrate'.

Anyway, thanks for your answers,
Franz

[parisse]

The reason is that symbolic integration is much more complex than diff (and much less used in a program) and I have various constraints coming from the softwares that are using giac, like geogebra or the HP Prime, making changes in evaluation would likely break something.
I don't want to take the risk, I would prefer to make the use of unquote more consistent.