Opened 9 years ago

Last modified 9 years ago

## #15299 closed defect

# Incorrect results for analytic Sha due to low precision — at Version 8

Reported by: | Jeroen Demeyer | Owned by: | |
---|---|---|---|

Priority: | major | Milestone: | sage-5.13 |

Component: | elliptic curves | Keywords: | |

Cc: | John Cremona, William Stein | Merged in: | |

Authors: | Jeroen Demeyer | Reviewers: | |

Report Upstream: | Fixed upstream, but not in a stable release. | Work issues: | |

Branch: | Commit: | ||

Dependencies: | Stopgaps: |

### Description (last modified by )

See https://groups.google.com/forum/#!topic/sage-support/rYQ4rWyncG4

sage: E = EllipticCurve(QQ,[0, 0, 1, -79, 342]); E.sha().an(),E.sha().an_numerical() (0, 1.00000000000000) sage: E.lseries().deriv_at1(100*sqrt(E.conductor()) + 10) # L1, error_bound (1.94655218772191e-15, 1.82478252135394e-270)

This seems to be due to inappropriate use of Python floats instead of more precise real numbers. After the patch:

sage: E = EllipticCurve(QQ,[0, 0, 1, -79, 342]); E.sha().an(),E.sha().an_numerical() (1.00000000000000, 1.00000000000000) sage: E.lseries().deriv_at1(100*sqrt(E.conductor()) + 10) # L1, error_bound (-4.32787398660869448751904675450772492666840247314688171540527473331725818170217268435223462033366791557160872926179439894639315476270837428785657638252738603056742447337636326343956370276624493916496382120766160023620812331280787034239648552009947468067829864968026720015203778821069593806584e-277, 1.82478252137476307223140369768561190028055347258560054363485475966241792307587640145132294203994875344783110100551912347495775160520204557245032474939095251969168953786545612090565728262067746413119194690260652692254781091147749697957445424152473292233020112755190503925812425294821095313979e-270)

### Change History (8)

### comment:1 Changed 9 years ago by

Description: | modified (diff) |
---|

### comment:2 follow-up: 3 Changed 9 years ago by

### comment:3 follow-up: 5 Changed 9 years ago by

So this is plain wrong then (I don't know enough mathematics to judge this):

if self.__E.root_number() == 1: return 0

### comment:4 Changed 9 years ago by

I don't know about `11a1`

, but this at least fixes the original problem.

### comment:5 Changed 9 years ago by

Replying to jdemeyer:

So this is plain wrong then (I don't know enough mathematics to judge this):

if self.__E.root_number() == 1: return 0

The root number is the sign of the functional equation so is +1 for even analytic rank and -1 for odd. This function computes the first derivative. *In practice* this is something one would only want to do if the 0'th derivative was already known to be 0, in which case the code you quote would be OK since if the value is 0 and the order is even then the order is at least 2 so the first derivative is exactly 0. But of course this function then lies in wait for the user who decides they want the first derivative's value even when the value is nonzero (as for 11a1). The trouble is that (1) Formulas for the r'th derivative which are implemented are *only* valid under the assumption that all previous derivatives are 0; and of course (2) proving the earlier derivatives are exactly 0 is usually impossible with current theory.

Where does that leave this deriv_at1 function? At the very least it should come with a huge warning about all this. And it really should return 0 when the root number is +1 unless the user has made an explicit assumption (assume_order_of_vanishing_is_positive=True, say) and otherwise raise a NotImplemented? error (or attempt to prove that L(1)=0).

### comment:6 Changed 9 years ago by

Status: | new → needs_review |
---|

### comment:7 Changed 9 years ago by

Description: | modified (diff) |
---|

### comment:8 Changed 9 years ago by

Description: | modified (diff) |
---|

**Note:**See TracTickets for help on using tickets.

It gets worse!

I.e., it is wrong for all curves of rank 0 too... (This isn't what we wrote the code for. Ugh.)