> > No I am against changing this. For two reasons, when working with > > polynomials in variable names liks "k", "p". It is not always easy to > > remember which was the first and which was the second variable. Then > > it is very handy to pass keywords for evaluation - but still to expect > > a base_ring element. > > +1 (but where is the second reason?)
Well, given that my message got posted three times, there are 3 reasons already :) The other (which I forgot to include in the end) is that it would probably imply a lot of changes throughout the full sage code and many people might be used to the syntax. > > Instead I think we should check that all variables are evaluated. This > > would be consistent with the call f(2,3) which screams when the number > > of variables is not correct. Even better, we could check if the result > > is really a ring element after substitution, which is easy to do. E.g. > > I would allow > > f = x*(x+y) > > f(x=0) > > but not > > f(x=1) > > I don't like this approach. I would allow both f(x=0) and f(x=1), in > both cases returning a univariate polynomial. Mathematically I fully agreee with you. I would expect an element of R[x,y]/(x) = R[x,y]/(x-1) = R[y] in both cases. But if we want to stick to the principle that the type should be the same for all returned answers, we would have to do f.subs() gives back an element of the parent of f and f(..) gives back an element of the base-ring of f and hence it would only be allowed to be used in case the evaluation really yields an element in there. My suggestion above is based on the fact that it is very easy to check if the result is in the base_ring. Maybe it is just as easy to check if the length of the keywords is equal to the number of variables. Chris. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
