On Sun, Feb 16, 2020 at 06:52:36PM +0100, Ralf Hemmecke wrote:
> >> 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?
Ockham razor. To implement division ('exquo'), we need a
way to decide if arbitrary element of the ring is in the
multiplicative set. In principle with explicit S, we could
require that S has RetractableFrom R, but boolean predicate
is minimal thing.
> 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.
Division in localization always require membership test, implicit
or explict. Thinking more about this I see that what we really
need is a test if pair (a, b) is equivalent to valid element
of localization. That is we may need to remove common factors
before membership test for denominator.
--
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/20200217151511.GB37879%40math.uni.wroc.pl.
