On Jun 27, 2008, at 3:18 AM, Bjarke Hammersholt Roune wrote: > On Jun 27, 11:50 am, "Joel B. Mohler" <[EMAIL PROTECTED]> wrote: >> On Friday 27 June 2008 04:59:37 am Burcin Erocal wrote: >> >> In general, the difference between >> multivariate and univariate should not matter in practice. >> > +1. > > E.g. exponents() on univariate ring returns a list of int, while > exponents() on a multivariate ring returns a list of list of ints > (well, not lists exactly, actually, but conceptually the returned > object is a list). So any code dealing with exponents has to have one > case for univariate rings and another case for multivariate rings. > Univariate rings should have an interface that works exactly the same > as the one for multivariate rings, except that it can have additional > methods that make sense only for univariate rings. > > I would actually even prefer there to be no distinction at all, and > for *polynomial* rings (not multivariate or univariate) just to have > methods that raise an exception if called on a ring that has more or > less than a single variable, if we really need univariate-only > functionality.
While I am for unifying the interfaces, I am -1 to changes that make it harder to use univariate polynomial rings, which are extremely common and should be optimized for. For example, the coefficient() and coefficients() methods have semantics that make a lot of sense in the univariate case, but are much more complicated to understand in the multivariate case. If one has an algorithm that needs to handle both univariate and multivariate polynomials in a similar fashion, another option would be to (at the top of the algorithm) do a conversion from univariate to 1-var multivariate (which could be a wrapper around the underlying univariate polynomial ring for speed). Another option is to have a method like multi_coefficient(...) which would in both types of rings support the multivariate semantics. - Robert --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] 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://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
