1 | initial version |

The following is a partial answer.

In the meantime I could analyse the following:
The root cause of the problems is the value for the **precision** in the mwrank library. There seems to be a default value in sage for precision (current value in Sage 9.5 seems to be 150) - and the mwrank library internally works with real numbers limited to that precision. At some point there is are divisions in mwrank by values which are - theoretically - not zero (theoretically they must be positive), but the limited precision may lead to rounding errors and therefore to negative values or even to 0. This seems to be the case here - and this explains the "RR: division by zero" exception, which seems to occur in the NTL library that is used my mwrank for dynamic floating point precision calculations.

I still do not understand why the Sage framework handles this "division by zero" exception in a way that a 2nd call will lead to segmentation fault. **This is the reason why this is only a partial answer**.

**Workarounds and Recommendations**

(1) The user may increase the precision to avoid this kind of problems. For example add the following 2 lines at the beginning of the code:

```
from sage.libs.eclib.mwrank import set_precision
set_precision(200)
```

This is not really a good workaround - since you have only 1 chance: As soon as the "division by zero" exception occured, changing the precision does not help and does not avoid the segmentation fault when called again. So, this

(2) The mwrank library could additionally check its real variables (which theoretically show positive values) for values <= 0 - and it should give an appropriate output in this case. (Internally in C++, it may throw a C++-exception in this case at a deeper level, and on the top C++-level it should catch this exception and give the hint that the precision seems to be too small for this elliptic curve.)

2 | No.2 Revision |

The following is a partial answer.

In the meantime I could analyse the following:
The root cause of the problems is the value for the **precision** in the mwrank library. There seems to be a default value in sage for precision (current value in Sage 9.5 seems to be 150) - and the mwrank library internally works with real numbers limited to that precision. At some point there is are divisions in mwrank by values which are - theoretically - not zero (theoretically they must be positive), but the limited precision may lead to rounding errors and therefore to negative values or even to 0. This seems to be the case here - and this explains the "RR: division by zero" exception, which seems to occur in the NTL library that is used my mwrank for dynamic floating point precision calculations.

I still do not understand why the Sage 9.0/9.5 framework handles this "division by zero" exception in a way that a 2nd call will lead to segmentation fault. And I still do not know what to do to open an appropriate ticket for Sage 9.0/9.5. **This is the reason why this is only a partial answer**.

**Workarounds and Recommendations**

(1) The user may increase the precision to avoid this kind of problems. For example add the following 2 lines at the beginning of the code:

```
from sage.libs.eclib.mwrank import set_precision
set_precision(200)
```

This is not really a good workaround - since you have only 1 chance: As soon as the "division by zero" exception occured, changing the precision does not help and does not avoid the segmentation fault when called again. So, this

(2) The mwrank library could additionally check its real variables (which theoretically show positive values) for values <= 0 - and it should give an appropriate output in this case. (Internally in C++, it may throw a C++-exception in this case at a deeper level, and on the top C++-level it should catch this exception and give the hint that the precision seems to be too small for this elliptic curve.)

Copyright Sage, 2010. Some rights reserved under creative commons license. Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.