Hello, sorry for bothering you so much, you probably think by now I get paid for this. The tutorial says that parameters to quo() should be univariate polynomials. Is this really necessary, esp. if you also get the main variable as parameter? Even if I accept the univariateness for parameters[*], the behaviour of the function towards multivariate input is inconsistent, as the ginsh session shows:
quo(y,y*x,y); FAIL quo(y*x,y,y); x
Thanks, ralf [*] I do not accept it, as I understand ginac from its interface to be inherently multivariate, except for the diff function, and even that is disputable.
Trying to be more exact, if you require a main variable as parameter to quo, then you already impose an ordering on the variables, and in this case quo is always well-defined, eg quo(y,y*x,y) would be 1/x. So the restriction to univariate input would be unnecessary if the implementation would follow this logic. Also, if quo would act as described an implementation of floor and frac[tional part] for rational functions would be a natural. However, if the ginac designers don't want this, then quo should throw an exception on *any* multivariate input, IMHO. ralf
Hi! On Sun, Aug 15, 2004 at 11:32:25AM +0200, Ralf Stephan wrote:
The tutorial says that parameters to quo() should be univariate polynomials. Is this really necessary, esp. if you also get the main variable as parameter?
I believe it works with multivariate polynomials but it currently won't return anything that is not a polynomial in all variables. However, the wording in the tutorial is a bit misleading. Seeing that quo() works on polynomials whose coefficient domain is a field it should also be able to return meaningful results if those coefficients (with respect to the specified main variable) are rational functions. I guess one needs to re-express quo()/rem() in terms of pquo()/prem() to make that work? Bye, Christian -- / Physics is an algorithm \/ http://www.uni-mainz.de/~bauec002/
participants (2)
-
Christian Bauer
-
Ralf Stephan