Martin Rubey wrote:
>
> Ralf Hemmecke <[EMAIL PROTECTED]> writes:
>
> > >> coefficient: (%, IndexedExponents Var) -> Coef (*2)
> > >>
> > >> to return %.
> > >
> > > I'd rather prefer
> > >
> > > coefficient: (%, Monomial) -> ???
> > >
> > > which is what I did in (35) above.
> >
> > Well... What is a power series? It's a mapping from N^n to the
> > coefficient domain. Now whether you call N^n "Monomial" is probably a
> > matter of taste. I also think that it is not bad, but IndexedExponents
> > is not totally bad, either.
>
> Sorry, I was unclear. IndexedExponents is OK for me. What I somewhat dislike
> is that
>
> -- coefficient(p, lv, ln) views the polynomial p as a polynomial
> -- in the variables of lv and returns the coefficient of the term
> -- \spad{lv**ln}, i.e. \spad{prod(lv_i ** ln_i)}.
>
> but
>
> -- coefficient(p, e) extracts the coefficient of the monomial with exponent e
> -- from polynomial p, or returns zero if exponent is not present.
>
> I.e., the second form takes a proper monomial, the first form doesn't.
>
Looking at polynomial (or power series) as depending only on some
variables (and treating the other as part of coefficient ring) is
very frequent operation -- I would consider it a fundamental one.
So, it needs good support. One may have doubt about names, but
the second version is really a special case of first one -- if
you specify _all_ variables you get something from base ring.
In other words: the semantic difference is really in types of
arguments/return values.
Note: for some purposes it is useful to consider both variants
as different, but it is really in Axiom spirit to provide most
general variant as a base and use overloading to have also
specialized versions.
Now, let us look at AMR. If you have free monoid then the same
general coefficient function makes sense. However, in general
monoid it is hard to treat generators sepatately, so only the
specialised version is used, but IMHO it still make sense to
use the same name.
> Anyway, here is a first patch that implements some of the missing functions
> for
> TS. I guess that quite a few definitions should become defaults of the
> category.
Remarks below:
> Martin
>
> Index: mts.spad.pamphlet
> ===================================================================
> --- mts.spad.pamphlet (revision 440)
> +++ mts.spad.pamphlet (working copy)
> @@ -86,6 +86,38 @@
>
> coefficient(s,n) == elt(s,n + 1)$Rep -- 1-based indexing for streams
>
> +-- coefficient(p, lv, ln) views the polynomial p as a polynomial
> +-- in the variables of lv and returns the coefficient of the term
> +-- \spad{lv**ln}, i.e. \spad{prod(lv_i ** ln_i)}.
> +
> + coefficient(s: %, lv: List Var, ln: List NNI): % ==
> + map(coefficient(#1, lv, ln), s)
It looks that terms of resulting series have wrong degree.
> + leadingCoefficient s ==
> + leadingCoefficient(coefficient(s, order(s pretend PS)$PS))
> +
That looks wrong. In fact, I do not think we can implement this: since
we use lexicographic order to know that say x is a leading term we
would have to examine infinitely many terms and check that each of
them contains x in power at least 1.
AFAICS your implementation corresponds to "total degree, reverse
lexicographic" order -- this is a reasonable order, but using
it would imply giving SMTS different category.
> + leadingMonomial s ==
> + leadingMonomial(coefficient(s, order(s pretend PS)$PS))::%
> +
> + reductum s == s - leadingMonomial s
> +
> + degree s == degree coefficient(s, order(s pretend PS)$PS)
> +
The same problem with the three functions above.
--
Waldek Hebisch
[EMAIL PROTECTED]
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
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/fricas-devel?hl=en
-~----------~----~----~----~------~----~------~--~---
