Calling P.order() does not terminate unless P.curve().order() is first called

[Alexander Krigsman]

This seems to me like a bug with Sage.  I have attached a point on an elliptic curve over a finite field for which this problem occurs to this message.  Running Sage in the directory containing the point gives the following:

sage: from sage.misc.persist import load
sage: P = load("point")
sage: P.order()
^C---------------------------------------------------------------------------
KeyboardInterrupt                         Traceback (most recent call last)
<ipython-input-3-e60806397b1c> in <module>()
----> 1 P.order()

/usr/lib/python2.7/site-packages/sage/schemes/elliptic_curves/ell_point.pyc in order(self)
   3519         E = self.curve()
   3520         ord = getattr(E, "_order", None)  # get cached order of the curve
-> 3521         return Integer(E.pari_curve().ellorder(self, ord))
   3522
   3523     additive_order = order

cypari2/auto_gen.pxi in cypari2.gen.Gen_base.ellorder()

KeyboardInterrupt:
sage: P.curve().order()
18061112346694138117304349799948434434304
sage: P.order()
11
sage:

Here I interrupt P.order() after waiting for a long time, yet if I first run P.curve().order() the command P.order() runs quickly.

[John Cremona]

I think I can explain this, but my diagnosis may be out of date since Sage now uses more pari functions than it used to, and fewer of the function I wrote for Sage itself.

The point is a point on an elliptic curve E over the field GF(103^20)  but the curve's j-invariant only has degree 2, which means that computing the cardinality of E is fast, the result being

sage: E.cardinality()
18061112346694138117304349799948434434304
sage: E.cardinality().factor()
2^8 * 3^2 * 11^2 * 13^2 * 17^2 * 1171^2 * 95191^2 * 10332211^2

Knowing the cardinality of E makes finding the order of points straightforward.  Now asking a point for its order might check whether the curve cardinality is known (I assume that this is true -- a pari function is called), but does not trigger its calculation if not.  Now when you ask Sage for the cardinality it *does* check whether the j-invariant lies in a subfield, but the cardinality function in pari, which is called implicitly when you ask for the order of P first, does not (as I have been told by pari developers).

It might be a good idea for Sage to do something different and possibly compute the cardinality of E before calling pari for the order of the point.  One reason why we used not compute the curve cardinality first always was that the methods of computing the cardinality used to (and perhaps still do) involve computing the order of random points.

I myself do not intend to go further with this.  Perhaps the people who replaced my code with calls to pari would like to comment? 

John

--
You received this message because you are subscribed to the Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/2ca16691-5c2b-4fbb-951f-8206e2e6bcce%40googlegroups.com.

[Alex]

Maybe it would be a good idea to have Sage check the j-invariant before calling pari when asking for the order of P?  Either way, thank you for your quick response.  This is very clear.

Alex

To unsubscribe from this group and stop receiving emails from it, send an email to sage-...@googlegroups.com.