# Ticket #5252(closed defect: fixed)

Opened 4 years ago

## [with patch, positive review] elliptic curves: P.height() lies about its precision

Reported by: Owned by: AlexGhitza was major sage-3.3 number theory

### Description

This is a bit weird because it seems to only happen with some elliptic curves.

Anyway, here's the example:

```sage: E = EllipticCurve([1, -1, 1, -2063758701246626370773726978, 32838647793306133075103747085833809114881])
sage: P = E([-30987785091199, 258909576181697016447])
sage: P.height()               # default precision: 53 bits
sage: P.height(precision=100)  # new precision: 100 bits
25.860317067546190744967149477
sage: P.height(precision=250)  # new precision: 250 bits
25.860317067546190744967149477417933667311444878578186035156250000000000000
```

I don't believe for a second that all the zeroes in the last example are correct. In fact, if you increase the precision to 1000 bits you only get more zeroes.

There must be "simpler" elliptic curves for which this happens, and I'll try to find some.

## Change History

### comment:1 Changed 4 years ago by AlexGhitza

Running this example in a native GP session works fine, so the problem is either in Sage or in the way Sage communicates with the Pari library.

### comment:2 Changed 4 years ago by cremona

• Summary changed from elliptic curves: P.height() lies about its precision to [with patch, needs review] elliptic curves: P.height() lies about its precision

Alex, I think that the ellheight() function needs to be given the precision parameter, despite what it says in the docstring for that function:

```sage: E = EllipticCurve([1, -1, 1, -2063758701246626370773726978, 32838647793306133075103747085833809114881])
sage: P = E([-30987785091199, 258909576181697016447])
sage: PE = E.pari_curve(prec=500)
sage: PE.ellheight([P[0],P[1],P[2]]).python()
25.8603170675461907
sage: PE.ellheight([P[0],P[1],P[2]],precision=500).python()
25.8603170675461907438688407407351103230988729038444162155771710417835725129551130570889813281792157278507639909972112856019190236125362914195452321719909
```

(Here I output the .python() conversion since otherwise it uses the gp default precision for output so you cannot see what is going on).

After my patch, your example works fine:

```sage: E = EllipticCurve([1, -1, 1, -2063758701246626370773726978, 32838647793306133075103747085833809114881])
sage: P = E([-30987785091199, 258909576181697016447])
sage: P.height()
25.8603170675462
sage: P.height(precision=100)
25.860317067546190743868840741
sage: P.height(precision=250)
25.860317067546190743868840740735110323098872903844416215577171041783572513
sage: P.height(precision=500)
25.8603170675461907438688407407351103230988729038444162155771710417835725129551130570889813281792157278507639909972112856019190236125362914195452321720
```

The patch (based on 3.3.rc0) corrects height(), adds a doctest, and corrects the docstring in gen.pyx. I also had to correct a doctest output in ell_rational_field.py.

NB The output at precision 500 for the new doctest looks odd on trac but is ok in the source file.

### comment:3 Changed 4 years ago by AlexGhitza

• Summary changed from [with patch, needs review] elliptic curves: P.height() lies about its precision to [with patch, positive review] elliptic curves: P.height() lies about its precision
• Milestone changed from sage-3.4.1 to sage-3.3

Excellent work, John!

### comment:4 Changed 4 years ago by mabshoff

• Status changed from new to closed
• Resolution set to fixed

Merged in Sage 3.3.rc1.

Cheers,

Michael

Note: See TracTickets for help on using tickets.