>> 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.
Oh, OK. Then PolynomialRing can perfectly be used for
LaurentPolynomials, however, I would like to have a signature
/: (%, S) -> %
where S is the multiplicative set in the S^{-1}R construction of a local
ring. In that sense I meant that I cannot divide by variables. The
multiplicative set is not known. PolynomialRing behaves like a
polynomial *ring* without knowing about its local nature.
What would be nice would be a "local category". Currently, we oly have
Localize as a domain.
>> 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.
Well, I have nothing against a generic implementation of a localization
of a ring/module, but of course it should not be forbidden to use
PolynomialRing as a special implementation for a localization at the
variables. I don't see a big problem to do this, I'm only missing a nice
category for local structures.
> Well, Localize is really limited. General approch would specify
> multiplicative set via a function from R to Boolean.
Why? Why wouldn't you rather give the set itself? Maybe, we should first
collect the common cases, but I somehow feel, that it would be easy to
create one or several constructor that is given a number of generators
of the multiplicative set or considers just the multiplicative structure
of a ring, etc. Well... one would have to program some prototypes to see
what is better, but my feeling is somehow that with a member function as
you suggest above, division always requires a membership test.
>>>> 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.
Yes, but that loses the idea of "positiveness".
However, in a sense I agree with you, sup for group structures is
probably not useful enough to introduce such a signature.
>> 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.
Thanks. Of course, I'm open to discussions and therefore did not simply
commit it in the first place.
Ralf
--
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/516841f0-ce19-5d5d-9bd6-facb1967d0a8%40hemmecke.org.
