Waldek Hebisch <[EMAIL PROTECTED]> writes:
> 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.
Yes, certainly.
> In other words: the semantic difference is really in types of
> arguments/return values.
Yes, I only dislike the types in case of coefficient(p, lv, ln).
> 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.
Great, I think we agree. Although I still dislike the notation
List Var, List NNI
as specifying a monomial. I admit however, that it's quite practical. I don't
have the time to design something better right now, so let's leave it for now.
> > +-- 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.
Are you sure?
(9) -> coefficient(sin(X+Y), [x], [1])
1 2
(9) 1 - - y + O(5)
2
Type: TaylorSeries(Fraction(Integer))
(10) -> sin(X+Y)
1 3 1 2 1 2 1 3
(10) (y + x) + (- - y - - x y - - x y - - x ) + O(5)
6 2 2 6
Type: TaylorSeries(Fraction(Integer))
> > + 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,
Yes
> but using it would imply giving SMTS different category.
Why? I thought it specialises well to the univariate case.
Martin
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
