Working with curves over number fields is less abstract than the textbooks make it look
You start with a smooth projective curve C defined over a number field K, usually given by a polynomial equation or a set of them. The arithmetic side comes from looking at the set C(K) of K-rational points and trying to understand its structure. If the genus is zero, you either have no points or infinitely many, and that's straightforward to decide. Genus one is where things get interesting because that's an elliptic curve, so you have the Mordell-Weil theorem doing the heavy lifting. Genus two and above is where the theory gets genuinely difficult and the software starts to fail you. I keep a SageMath worksheet open with Magma available for anything that won't factor fast enough. Here's the actual sequence I go through when a new curve lands on my desk. Define the curve over your field. In Sage that's usually something like defining the base field first—QQ or a number field constructed with a minimal polynomial—then writing C = Curve(f) where f is your polynomial. You immediately check the genus. If it's 1, compute the Mordell-Weil group. If it's 2 or higher, you're looking at Faltings' theorem, which tells you the group is finite but gives you zero information about how to find those points.
The next thing I do is search for rational points using a brute-force height bound when the field is small, or use the Chabauty-Coleman method when the rank is below the genus. For genus 2 curves over Q, if the Jacobian has rank 0 or 1, Chabauty works beautifully and you can determine C(Q) completely. I've had cases where this cut a two-day computation down to about twenty minutes compared to trying generic point search methods. After that, check the Tamagawa numbers and the Sha group at any primes of bad reduction. Local-global principles fail here more often than people expect. I once spent three weeks chasing what I thought was a computational bug before realizing the curve had a nontrivial element in Sha(E/Q) that was hiding the true rank. The workaround was computing the 2-Selmer group separately and comparing it to the Mordell-Weil rank through descent. The gap told me exactly where the obstruction was sitting. For curves over number fields that aren't Q, you need to be careful about integral points versus rational points. The Siegel theorem says integral points are always finite, but the effective bounds are so large they're useless in practice. I use a combination of the LLL reduction on the Mordell-Weil lattice and then a direct search within the reduced bounds. This usually brings the search space down to something feasible in under an hour for fields of moderate degree.
If you're dealing with modular curves or Shimura curves specifically, there's a whole different toolbox involving modular symbols and eigenforms. That's a separate rabbit hole, but the basic idea is the same: translate the geometric problem into something computable in a space where you actually have algorithms.
Get the Full Details
Common pitfalls and what the literature quietly omits
Beginners always assume that computing the rank of a Jacobian over a number field is a solved problem. It isn't. The descent algorithms are theoretically sound but they hit walls at genus 3 and above over fields larger than Q. I've seen papers claim complete determinations of rational points on genus 3 curves that later turned out to rest on an unverified assumption about Sha being trivial. Always verify the Sha computation independently when possible. Another thing nobody emphasizes enough: the choice of model matters enormously for computation. A curve given by a high-degree equation in projective space might have genus 2, but a bad choice of coordinates can make every algorithm orders of magnitude slower. Reducing to a minimal Weierstrass form or a double cover of P1 is worth the effort. I typically run a model reduction step first, and it changes computation time from hours to minutes in most cases I've encountered. There's also the issue of computers failing gracefully. When Magma or Sage runs out of memory during a height bound computation, it doesn't always tell you clearly what went wrong. I've learned to monitor the memory usage and set explicit timeout limits on individual subroutines. A five-minute timeout on a failed descent is better than a three-hour hang that produces nothing.
The theory has genuine blind spots. Non-abelian Chabauty is progressing but still isn't general-purpose enough for routine use. The Coleman-Gross p-adic height pairing is beautiful and correct but computationally expensive, and it doesn't yet have a robust implementation for arbitrary genus curves. If you're working on a curve where abelian Chabauty doesn't apply and the rank is too high for classical methods, you're in territory where people are still publishing new results rather than following established recipes. Software recommendations are straightforward but limited. Magma remains the most complete for explicit arithmetic geometry work, though it's expensive. SageMath is free and covers most standard operations, but its performance on large Selmer group computations lags behind Magma. There's also Cremona's tables for elliptic curves over Q, which are definitive for rank and modular degree calculations up to conductor 650000. Beyond that, you're on your own with whatever general-purpose code you can assemble. The bottom line is that Algebraic Geometry And Arithmetic Curves is a field where the conceptual framework is well understood and the computational tools are adequate for a substantial range of problems, but there are real gaps at the higher genera and over larger number fields that haven't been closed yet. You learn to work within those gaps rather than around them.
