#18356: special resultants ``composed_sum`` and ``composed_product``
-------------------------------------+-------------------------------------
       Reporter:  pernici            |        Owner:
           Type:  enhancement        |       Status:  needs_info
       Priority:  major              |    Milestone:  sage-6.7
      Component:  algebra            |   Resolution:
       Keywords:                     |    Merged in:
        Authors:                     |    Reviewers:
Report Upstream:  N/A                |  Work issues:
         Branch:                     |       Commit:
  u/pernici/ticket/18356             |  1fe9b052c8f1e49f9b0480f40dfa1937ef9f8dcf
   Dependencies:                     |     Stopgaps:
-------------------------------------+-------------------------------------

Comment (by pernici):

 Replying to [comment:30 vdelecroix]:
 > Replying to [comment:29 pernici]:
 > > Replying to [comment:28 vdelecroix]:
 > > > Hi,
 > > >
 > > > Did you completely avoid the power series ring? We should provide
 more methods to polynomial like:
 > > >  - `inverse_series(self, prec, as_polynomial=False)`: return the
 inverse series and if `as_polynomial` is true returns it as a polynomial
 > >
 > > Yes, I used `fmpq_poly_inv_series`, `fmpq_poly_exp_series`, so the
 power series ring is not used.
 >
 > I think this is bad. This will make your code specific over Q. You might
 consider implementing (in an other ticket) an `inverse_series` and an
 `exp_series` method on polynoms that handle the option of returning a
 polynom. This method would have a default implementation in
 `polynomial_element.pyx` and specialized one for the FLINT classes.

 I have rewritten `composed_op` using `inverse_series`, `exp_series`,
 methods in `polynomial_element.pyx`
 (without default implementation yet), using `_mul_trunc_` in #18420 as a
 template.
 It is faster than the "resultant" algorithm in all the cases tested.

 I think that `inverse_series`, `exp_series`, etc. in
 `polynomial_element.pyx`
 should always return a polynomial.

 I could open a ticket on implementing these methods, depending on #18420.
 Do you think that it is ok?

--
Ticket URL: <http://trac.sagemath.org/ticket/18356#comment:31>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica, 
and MATLAB

-- 
You received this message because you are subscribed to the Google Groups 
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.

Reply via email to