#12880: Inconsistent domain, codomain and parent in EllipticCurveIsogeny
-------------------------------------+-------------------------------------
       Reporter:  nthiery            |        Owner:  cremona
           Type:  defect             |       Status:  needs_work
       Priority:  minor              |    Milestone:  sage-6.2
      Component:  elliptic curves    |   Resolution:
       Keywords:                     |    Merged in:
        Authors:  Sébastien Besnier  |    Reviewers:
Report Upstream:  N/A                |  Work issues:
         Branch:                     |       Commit:
  u/sbesnier/ticket/12880            |  b486f244b98a16b144cd45399eee3112ed5f824b
   Dependencies:  #11474             |     Stopgaps:
-------------------------------------+-------------------------------------

Comment (by defeo):

 > This looks good to me overall.  The main thing I am wondering about is
 if it wouldn't make sense to keep the current version of `_composition_`
 (raise a `NotImplementedError`) until we have real composition of
 isogenies.  What I mean is that with your change, we just get a "formal"
 composition of two isogenies.  Although this may be good enough for some
 applications, what we really want is to compute the actual polynomials
 defining the composed isogeny.  From that perspective I wouldn't say that
 removing the method "makes composition work".

 I'd rather say the opposite. There are applications where formal
 composition is the desired result.

 Formal composition is essentially free, while "flesh-and-blood"
 composition may be expensive (exponential in the length of the chain).
 There are cryptosystems that exploit this fact, Sage should make it easy
 to implement them in a few lines of code.

 I'm more in favour of using formal composition by default, and having a
 method (`.normalize()`, maybe?) to compute the "flesh-and-blood" version.
 Subsidiary question : what should equality do in this case?

 > I think we should open a separate ticket for composition, since we are
 obviously not going to do all of #7368 at the same time.

 Agreed. It would be a better place to continue this discussion.

--
Ticket URL: <http://trac.sagemath.org/ticket/12880#comment:21>
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