On Fri, Feb 14, 2020 at 11:25:36PM +0100, Ralf Hemmecke wrote: > On 2/14/20 5:24 PM, Waldek Hebisch wrote: > > On Fri, Feb 14, 2020 at 04:43:12PM +0100, Ralf Hemmecke wrote: > >> Hello, > >> > >> FriCAS does not have LaurentPolynomial. > > > > One can view such domain as localization of polynomials. It > > is one of reasons that I would like to have good support > > for localizations, a lot of concrete examples could be > > covered in that way. > > In fact, I also thought about this, before I wrote my mail. In fact, > > PolynomialRing(Fraction(Integer),DirectProduct(3,Integer)) > > does not allow to divide by variables. That is why I wrote "an > approximation of".
Hmm, cosider: vL := OrderedVariableList([a, b ,c]) fM := FreeModule(Integer, vL) lP := PolynomialRing(Integer, fM) vara := monomial(1, monomial(1, a)$fM)$lP ivara := (1$lP exquo vara)::lP vara*ivara In what sense 'exquo' "does not allow to divide by variables"? Note that you can not divide by arbitrary elements, so 'exquo' is right operation for division. > However, > > Localize(M : Module R, R : CommutativeRing) > > basically forms fractions. That would not be needed in the case of > LaurentPolynomial. Sure, PolynomialRing is probably more efficient. OTOH localization should know more about ring, for example localization should know that we got UniqueFactorizationDomain or GcdDomain. With definition above lP has GcdDomain gives false and in general PolynomialRing has too limited information to say differently. > Other than that, I agree, that we should have better support for local > structures. > > BTW, I would like to change to order of parameters in Localize, i.e., R > should come first, because the "Module(R)" parameter depends on it and I > would like to search for dependencies from left to right. > > The second issue with FriCAS' Localize is that one usually write M^(-1)R > with a multiplicative set M and a ring/module R. The multiplicative set > is not present as an explicit domain parameter, it's rather implicit as > all non-zero elements of the "CommutativeRing" parameter of Localize. Well, Localize is really limited. General approch would specify multiplicative set via a function from R to Boolean. Representation would be via fractions, but 'exquo' would look if numerator of dividend is OK (by calling provided function). > >> DirectProduct(n,R) only exports OrderedAbelianMonoidSup, if R is of type > >> OrderedAbelianMonoidSup. Clearly, this sup function > >> > >> http://fricas.github.io/api/OrderedAbelianMonoidSup.html#l-ordered-abelian-monoid-sup-sup > >> > >> sup: (%, %) -> % > >> sup(x, y) returns the least element from which both x and y can be > >> subtracted. > >> > >> is mainly used for reductions. But the specification is a bit vague. > >> Why doesn't have Integer such a function? Yes, there would be no "least" > >> element. But what does "least" in this specification mean anyway? Is it > >> the smallest with respect to the < order of the domain? > >> Then clearly, Integer cannot have this. > > > > My impression is that this is essenially 'gcd', but written in additive > > terms (think of multiplicative monoid of a commutaive ring with 1 as > > n abelian monoid). Defining it for integers is probably useless, > > I would rather avoid requirng it when not necessary. > > You probably meant lcm instead of gcd, but yes, that's what it's > probably supposed to be. Yes, using divisibility it is lcm. > > Yes, for Integer, it's probably uninteresting, but what about > DirectProduct(n, Integer) or DirectProduct(n, Fraction Integer)? > If it's available for Integer, then DirectProduct inherits sup via > conditional export in DirectProductCategory. > > >> However, the idea of this function is to achieve "positiveness", i.e., > >> if c = sup(a, b) then c-a>=0 and c-b>=0. Right? Wouldn't it make sense > >> to add this condition to the "sup" specification. Then also Integer and > >> Fraction Integer can be of type OrderedAbelianMonoidSup. > > I don't insist on implementing OrderedAbelianMonoidSup for Integer, but > still I would like to add "if c = sup(a, b) then c-a>=0 and c-b>=0" to > the specification of sup, because "least" can only mean the smallest > wrt. < of the domain. No, documentation clearly say that they mean _partial_ pre-order corresponding to divisibility. Now, since this is OrderedAbelianMonoid linear order extends partial pre-order coming from divisibility, but logically what counts is divisibility. In fact, if you insist on having 'sup' for groups most natural definition is trivial one, namely always getting identity element. > But think about lex ordering or degrevlex ordering > of DirectProduct. Cannot there be two different elements depending on > whether the domain implements lex or degrevlex? And, for example, for > DirectProduct(n, Integer), it wouldn't be clear that sup(a,b)-a>=0 and > sup(a,b)-b>=0. > > >> Furthermore, I don't see a good reason why OrderedDirectProduct, > >> HomogeneousDirectProduct and SplitHomogeneousDirectProduct require > >> their argument to be of type OrderedAbelianMonoidSup. Without the "Sup" > >> would be sufficient. > > > > Yes, probably previously nobody was thinking about more general > > applications. > > Can I commit the patch, that I attached in my last mail? This > generalization would be enough for what I needed it for in the first > place, i.e., creating some pseudo LaurentPolynomial domain. Yes, OK. As I wrote, rationalizing categories in the future we may do it in slightly different way, but for now it is fine. -- Waldek Hebisch -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/20200216152027.GA25387%40math.uni.wroc.pl.
