On Sun, 29 Oct 2006 03:53:15 -0700, Bill Hart <[EMAIL PROTECTED]> wrote: > One possibility, which I haven't quite thought through, is to allow the > user to get away with: > > R=PolynomialRing(ZZ) > > When asked what R is, SAGE will report that it is a univariate > polynomial ring over ZZ. > > But if a user tries to use a function which displays indeterminates > from the ring R, then it would report that indeterminates for R have > not yet been specified. Sage could even go all interactive and ask the > user to type yes or no for whether they want sage to automatically > assign x to be the indeterminate of R, or if x is already being used > elsewhere, x0, or if that is being used, x00, etc.
SAGE will never "go all interactive" for any reason, at least not if I can help it. Programs that do that are very annoying to me. > This would allow the following trace: > > x=polygen() > f=x^2+x^3-4 > g=x+1 > R=PolynomialRing(ZZ) > h=R(f*g) > > This operation would force the polynomials into the ring R > (automatically making the indeterminate of R to be called x). This is > natural if one thinks of the original x as being an indeterminate in a > formal ring that can be coerced into any ring. > > This would also work if R had been defined as: > > R = ZZ['x'] > > but not > > R = ZZ['y'] > > This is kind of what I had in mind when I advocated the introduction of > universal indeterminates. > > However, now the trick would be to think about what x the polynomials f > and g are now defined in terms of. Are they still defined in terms of > the universal x or the new indeterminate x of the ring R? > > I think the former is better, since those same polynomials can then be > coerced into another ring whose indeterminate is called x (or which > hasn't been defined yet). > > I think this leads to no confusion, since when someone types x without > the context of a ring, SAGE assumes they are talking about the > universal indeterminate x. If one is working in the context of R, then > it will assume you are talking about the indeterminate of R. > > Now the user typing x*R(x) could be a problem. One would need to > automatically coerce the first x into R to avoid the answer being x*x > with the two x's being different. A situation that must be avoided at > all costs. The coercion model we've defined for SAGE would already coerce the left x into R. > Of couse problems are going to arise if one has a hierarchy of > automatic coersions. If R can be automatically coerced into S and vice > versa (is this ever possible?) then there could obviously be trouble > with this whole approach unless one comes up with some mechanism that > allows x to be given a type that is in both R and S simultaneously > (like a kind of join of R and S, higher up the hierarchy). There *is* a model of canonical coercion already. One of the axioms is that if R coerces to S and S coerces to R, then R and S must be canonically isomorphic (and the compositions of the coercions in both directions must be the identity map). > The better option I think, is to force the user to always specify > coersions. Thus when someone types x*f(x) where the first x is > universal and the second in R, then sage will complain that the rings > are not the same and give the hint to the user that they might try a > coersion. Thus the user would have to type: > > R(x)*f(x) Such a system is almost unusable and seems very stupid. Please, the fact we have already solved the coercion problem (there was a lot of discussion and clarification of this yesterday and at SAGE days, and SAGE already has a nice sytem in place. E.g., try QQ(3) + 5 and 5 + QQ(3) and 7 + Integers(11)(5), all of which illustrate the excellent coercion model in SAGE. (Which was first designed by DAvid Kohel and I last year, and refined a lot recently -- though the refinements haven't been implemneted yet.) > Of course sage will still have to work out if it is possible to think > of the ring x belonged to as included in the ring R in a natural way. > > Can anyone think of a situation where this would not work?? It's too cumbersome. > I notice at present if someone does something like this in sage, it > merely complains that it is unable to find a common parent. So I > presume there is no system of coersions at all. E.g. > > x=polygen(ZZ) > f=x^2+x > R=QQ['x'] > R(x)*f > > causes an exception, as does: > > x = polygen() There is currently no system of coercions between *polynomial rings* right now. This was because one could change the name of the indeterminate at any time. Now that we've changed the model so that polynomial rings (etc.!) are immutable, there can be a sensible system of coercion -- namely if two polynomials R and S are in exactly the same indeterminate, and the base ring of R canonically coerces to the base ring of S, then R will automatically canonically coerce to the S, sending the generator of R to the generator of S. If the variable names are different the coercion won't be allowed. William --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
