4. Magma versus Sage

If you want to do a range of explicit computations with elliptic curves, you will very likely use Sage or Magma. If you're really serious, you'll use both.

Note, as mentioned above, that both Sage and Magma are far ahead of all other software for elliptic curves.

• Magma reference manual about elliptic curves.

• Sage reference manual about elliptic curves.

• Pari reference manual about elliptic curves. -- pari is part of Sage and has some unique powerful functionality, e.g., ellheegner...

History:

When I started contributing to Magma in 1999, I remember that it was way, way behind PARI. I remember having lunch with John Cannon (founder of Magma), and telling him we could "kill Pari" if only Magma would have dramatically faster code for computing $a_p = p + 1 - \#E(\FF_p)$; he responded "I don't want to kill Pari."

In any case, a few years later, John wisely hired Mark Watkins to work fulltime on Magma, and Mark has been working there for over a decade. Mark is definitely one of the top people in the world at implementing (and using) computational number theory algorithms, and he's ensured that Magma can do a lot. Some of that "do a lot" means catching up with (and surpassing!) what was in Pari and Sage for a long time (e.g., point counting, $p$-adic $L$-functions, etc.)

However, in addition, many people have visited Sydney and added functionality for doing higher descents to Magma, which is not available in any open source software. Search for Magma in this paper to see how, even today, there seems to be no open source way to compute the rank of the curve $y^2 = x^3 + 169304x + 25788938$.

Situation today

There are several elliptic curves algorithms available only in Magma (e.g., higher descents) ... and some available only in Sage ($L$-function rank bounds, some overconvergent modular symbols, zeros of $L$-functions, images of Galois representations). I could be wrong about stuff not in Sage, since WITH MONEY almost anything can get implemented in a year... And Magma has money.

The code bases are completely separate, which is a very good thing. Any time something gets implemented in one, it gets (or should get) tested via a big run through tables of elliptic curves up to some bound. This usually results in numerous bugs being found. I remember refereeing the "integral points" code in Sage by running it against all curves up to some bound and comparing to what Magma output, and getting many discrepancies, which showed that there were bugs in both Sage and Magma.

However, we would be way better off if Sage could do everything Magma does.