Trac 15667:  speed up point order when j=0,1728
Merge remote-tracking branch 'trac/develop' into ticket/15667

Conflicts:
	src/sage/schemes/elliptic_curves/ell_point.py
trac 15667: fix bug revealed by earlier change
trac #15864: Graph.is_distance_regular is awfully wrong
fixed typos, corrected the definitions of b, c, chnaged the way they are returned, one more example
docs fix: returning (b,c), not (c,b)
trac #15450 first try
trac #15450 polishing things
trac #15864: consistency between code and doc, and None in bi and ci
15698: Allow construction of power series from fractions

delegating conversion type check to numerator/denominator construction
 Please enter the commit message for your changes. Lines starting
Fraction to power series conversion when the fraction coerces into the base ring
Fraction to power series: doctests
Trac #15667: Time anomaly in finding orders of points on an elliptic curve over a finite field

See https://groups.google.com/forum/#!searchin/sage-
support/anomaly|sort:relevance|spell:true/sage-support/PzrQ6kUzSJg/m99x
--9TS-oJ

The upshot is that when computing the order of a point on an elliptic
curve whose cardinality has not yet been computed, there are cases where
that cardinality could be computed very quickly first, which would be
much faster than using BSGS methods for the order.  Specifically, this
is the case for curves with j-invariants 0 and 1728 over any finite
field.

From the mailing list contribution by Victor Miller:

Consider the following:
{{{
def NextProgression(n,a,q):
    p = next_prime(n)
    while (p%q) != a:
        p = next_prime(p+1)
    return p
}}}
{{{
def Test(n,compute=False):
    p = NextProgression(n,2,3)
    print "found prime=",p
    F.<u> = GF(p^2)
    print "Found field"
    E = EllipticCurve(F,[0,1])
    if compute:
        NN = E.order()
        print "Found Elliptic Curve of order ",NN
    P = E.random_point()
    Q = E.random_point()
    print "Found points"
    nP = P.order()
    print "Found order of P"
    nQ = Q.order()
    print "Found order of Q"
    N = lcm(nP,nQ)
    return E,P,Q,N
}}}
{{{
time E,P,Q,n = Test(2^25)

found prime= 33554501
Found field
Found points
Found order of P
Found order of Q
Time: CPU 10.52 s, Wall: 10.77 s
}}}

compared with
{{{
time E,P,Q,n = Test(2^25,compute=True)

found prime= 33554501
Found field
Found Elliptic Curve of order  1125904604468004
Found points
Found order of P
Found order of Q
Time: CPU 0.17 s, Wall: 0.18 s
}}}

URL: http://trac.sagemath.org/15667
Reported by: cremona
Ticket author(s): John Cremona
Reviewer(s): Jean-Pierre Flori
Trac #15698: conversion from polynomial fraction to its power series expansion

Original description was:

The following behaviour is not implemented, example:
{{{
  sage: R.<t> = QQ[]; A=1/(1-t)
  sage: A.expand(5)
  1+t+t^2+t^3+t^4+t^5+O(t^6)
  sage: A+O(t^6)
  1+t+t^2+t^3+t^4+t^5+O(t^6)
}}}
Add a parameter to specify the respective series variable (for
derivation) then multivariate polynomial fractions can be handled.
Result type being a power series. The pari function Ser() implements the
same behaviour. Note: I would like to implement this.

URL: http://trac.sagemath.org/15698
Reported by: rws
Ticket author(s): Ralf Stephan, Marc Mezzarobba
Reviewer(s): Marc Mezzarobba, Ralf Stephan
Trac #15864: Graph.is_distance_regular is awfully wrong

As reported in [1] `is_distance_regular` is SOooooooo awfully wrong that
the definition it uses is ... just wrong. I'm sorry for that `:-/`

The current patch fixes it.

Nathann

[1] http://trac.sagemath.org/ticket/14619#comment:27

URL: http://trac.sagemath.org/15864
Reported by: ncohen
Ticket author(s): Nathann Cohen
Reviewer(s): Dima Pasechnik
Trac #15450: Add derivative to Laurent polynomials

Currently

{{{
R.<x> = LaurentPolynomialRing(ZZ,1);
diff(x, x)
}}}

raises an error. Feature requested here:
<http://ask.sagemath.org/question/3246/how-to-differentiate-in-the-
laurent-polynomial>.

URL: http://trac.sagemath.org/15450
Reported by: defeo
Ticket author(s): Frédéric Chapoton
Reviewer(s): Travis Scrimshaw