Sage: Ticket #7575: mwrank interface improvements
https://trac.sagemath.org/ticket/7575
<p>
Ticket TODO list:
</p>
<ul><li><code>src/qrank/mrank1.cc</code> needs to be patched, as John described.
</li></ul><ul><li>Switch all uses of mwrank from the interface to the library.
</li></ul><ul><li>Make sure that all options to mwrank are properly used.
</li></ul><ul><li>Make sure that all output from mwrank is available.
</li></ul><ul><li>...?
</li></ul>en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/7575
Trac 1.2Robert MillerSat, 02 Jan 2010 15:17:25 GMTstatus changed
https://trac.sagemath.org/ticket/7575#comment:1
https://trac.sagemath.org/ticket/7575#comment:1
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_info</em>
</li>
</ul>
<p>
With the patch <code>trac_7575-heegner_index_example.patch</code> applied on top of (sage-4.3 plus) <a class="closed ticket" href="https://trac.sagemath.org/ticket/7576" title="#7576: enhancement: improvements to the prove_BSD function (closed: fixed)">#7576</a> and <a class="closed ticket" href="https://trac.sagemath.org/ticket/7819" title="#7819: defect: RealInterval(+infinity,+infinity).is_int() blows up (closed: fixed)">#7819</a>, I get the following:
</p>
<pre class="wiki">sage: E = EllipticCurve('123a1')
sage: E.prove_BSD(verbosity=2)
p = 2: true by 2-descent
---------------------------------------------------------------------------
RuntimeError Traceback (most recent call last)
...<SNIP>...
/Users/rlmill/sage-4.3/local/lib/python2.6/site-packages/sage/libs/mwrank/interface.pyc in gens(self)
310 """
311 self.saturate()
--> 312 return eval(self.__two_descent_data().getbasis().replace(":",","))
313
314 def certain(self):
RuntimeError:
</pre>
TicketJohn CremonaSun, 03 Jan 2010 18:27:43 GMT
https://trac.sagemath.org/ticket/7575#comment:2
https://trac.sagemath.org/ticket/7575#comment:2
<p>
In the original example (in this ticket's description), note that calling E.two_descent() produces output to the screen but returns nothing and stores nothing in E which was not there before. E.gens() by default uses mwrank_shell, which does not allow any passing of parameters (see the TODO block in the docstring), not because it cannot be done but because we have not implemented it. The non-default option mwrank_lib goes via creation of the associated mwrank_curve which also does not allow changing of the parameters.
</p>
<p>
What I suggest is that we use mwrank_lib by default; that we allow passing of all the parameters which the two_descent function of an mwrank elliptic curve allows from all higher level functions which call mwrank (e.g. gens()) and that we use the enquiry functions provided by mwrank to find out how successful it has been: it can give you a lower and upper bound for the rank, so all is well if they are equal and in any case can give you a number of gens equal to the lower bound. The only difficulty would be with caching rank and gens -- probably best not to do so at all unless we have certainly found them.
</p>
<p>
Does this all make sense? I think it would be much more helpful to have sample curves where things do not work well and sample code which does not go via a call to the (presumably complicated) function prove_BSD()!
</p>
TicketJohn CremonaSun, 03 Jan 2010 18:29:47 GMT
https://trac.sagemath.org/ticket/7575#comment:3
https://trac.sagemath.org/ticket/7575#comment:3
<p>
Another thought: perhaps we should have a class to hold a list of all mwrank-options.
</p>
TicketRobert MillerTue, 19 Jan 2010 21:46:20 GMTsummary changed
https://trac.sagemath.org/ticket/7575#comment:4
https://trac.sagemath.org/ticket/7575#comment:4
<ul>
<li><strong>summary</strong>
changed from <em>EllipticCurve.gens: height bounds not handled well in two_descent</em> to <em>Sage's interface with mwrank needs serious work</em>
</li>
</ul>
<p>
Here is another part where using the library would help:
</p>
<pre class="wiki">sage: EllipticCurve([1, 1, 1, -9718914979, 370891890941633]).mwrank()
ERROR: An unexpected error occurred while tokenizing input
The following traceback may be corrupted or invalid
The error message is: ('EOF in multi-line statement', (47, 0))
ERROR: An unexpected error occurred while tokenizing input
The following traceback may be corrupted or invalid
The error message is: ('EOF in multi-line statement', (362, 0))
---------------------------------------------------------------------------
RuntimeError Traceback (most recent call last)
/Users/rlmill/sage-4.3.1.rc1/devel/sage-main/<ipython console> in <module>()
/Users/rlmill/sage-4.3.1.rc1/local/lib/python2.6/site-packages/sage/schemes/elliptic_curves/ell_rational_field.pyc in mwrank(self, options)
484 from sage.interfaces.all import Mwrank
485 mwrank = Mwrank(options=options)
--> 486 return mwrank(list(self.a_invariants()))
487
488 def conductor(self, algorithm="pari"):
/Users/rlmill/sage-4.3.1.rc1/local/lib/python2.6/site-packages/sage/interfaces/mwrank.pyc in __call__(self, cmd)
75
76 def __call__(self, cmd):
---> 77 return self.eval(str(cmd))
78
79 def eval(self, *args, **kwds):
/Users/rlmill/sage-4.3.1.rc1/local/lib/python2.6/site-packages/sage/interfaces/mwrank.pyc in eval(self, *args, **kwds)
95 # Doing _start again fixes that always. See trac #5157.
96 self._start()
---> 97 return Expect.eval(self, *args, **kwds)
98
99 def console(self):
/Users/rlmill/sage-4.3.1.rc1/local/lib/python2.6/site-packages/sage/interfaces/expect.pyc in eval(self, code, strip, synchronize, locals, **kwds)
981 try:
982 with gc_disabled():
--> 983 return '\n'.join([self._eval_line(L, **kwds) for L in code.split('\n') if L != ''])
984 except KeyboardInterrupt:
985 # DO NOT CATCH KeyboardInterrupt, as it is being caught
/Users/rlmill/sage-4.3.1.rc1/local/lib/python2.6/site-packages/sage/interfaces/expect.pyc in _eval_line(self, line, allow_use_file, wait_for_prompt)
666 # we expect to get an EOF if we're quitting.
667 return ''
--> 668 raise RuntimeError, "%s\n%s crashed executing %s"%(msg,self, line)
669 out = E.before
670 else:
RuntimeError: End Of File (EOF) in read_nonblocking(). Empty string style platform.
<pexpect.spawn instance at 0xebec738>
version: 2.0 ($Revision: 1.151 $)
command: /Users/rlmill/sage-4.3.1.rc1/local/bin/mwrank
args: ['/Users/rlmill/sage-4.3.1.rc1/local/bin/mwrank']
patterns:
Enter curve:
buffer (last 100 chars):
before (last 100 chars): up to 232549 (square a first...)
Attempt to round -9608958007.0937 to a long int fails, aborting!
after: <class 'pexpect.EOF'>
match: None
match_index: None
exitstatus: None
flag_eof: 1
pid: 90387
child_fd: 7
timeout: None
delimiter: <class 'pexpect.EOF'>
logfile: None
maxread: 10000
searchwindowsize: None
delaybeforesend: 0
Mwrank crashed executing [1, 1, 1, -9718914979, 370891890941633]
</pre>
TicketJohn CremonaTue, 19 Jan 2010 21:56:34 GMT
https://trac.sagemath.org/ticket/7575#comment:5
https://trac.sagemath.org/ticket/7575#comment:5
<p>
This behaviour is supposed to be caught by mwrank C++ code, so that this can be detected gracefully by using the ok() function.
</p>
<p>
As we are planning to replace the pexpect interface entirely this will be dealt with. (There is absolutely no reason to use the interactive interface when everything can be found from the library interface.)
</p>
TicketJohn CremonaTue, 19 Jan 2010 22:02:04 GMT
https://trac.sagemath.org/ticket/7575#comment:6
https://trac.sagemath.org/ticket/7575#comment:6
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7575#comment:5" title="Comment 5">cremona</a>:
</p>
<blockquote class="citation">
<p>
This behaviour is supposed to be caught by mwrank C++ code, so that this can be detected gracefully by using the ok() function.
</p>
</blockquote>
<p>
On looking into it, I see that this will need a patch to the file src/qrank/mrank1.cc, since I just call abort() when I try to round to a long int and it overflows. Instead I need to catch that properly. (Pity C++ does not have the try/except functionality of python).
</p>
<p>
So this particular bug / behaviour needs to be flagged as "report upstream (done) and wait for a patch from upstream (on my todo list)".
</p>
<blockquote class="citation">
<p>
As we are planning to replace the pexpect interface entirely this will be dealt with. (There is absolutely no reason to use the interactive interface when everything can be found from the library interface.)
</p>
</blockquote>
TicketRobert MillerTue, 19 Jan 2010 22:11:48 GMTdescription changed
https://trac.sagemath.org/ticket/7575#comment:7
https://trac.sagemath.org/ticket/7575#comment:7
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/7575?action=diff&version=7">diff</a>)
</li>
</ul>
<p>
The documentation for <code>EllipticCurve.gens</code> says:
</p>
<pre class="wiki">HINT: If you would like to control the height bounds used in the
2-descent, first call the two_descent function with those height
bounds. However that function, while it displays a lot of output,
returns no values.
</pre><p>
However, this doesn't work, because <code>EllipticCurve.gens</code> doesn't know about it:
</p>
<pre class="wiki">sage: x,y=var('x,y')
sage: E = EllipticCurve(y^2 + x*y + y == x^3 - 10525529*x - 21714803524)
sage: E.two_descent(second_limit=11, verbose=False)
sage: E.gens()
*BOOM*
</pre><p>
Despite:
</p>
<pre class="wiki">sage: A = E.mwrank_curve()
sage: A.gens()
[[1737553736529419603224344006006032245457891558644991945121564365621L, -1605018042749306385493128932071874233128412498544999275367916849231954L, 2038538889602737161869943561394015059980551394212496529475951L]]
</pre>
TicketRobert MillerWed, 03 Feb 2010 05:11:13 GMTstatus changed; author set
https://trac.sagemath.org/ticket/7575#comment:8
https://trac.sagemath.org/ticket/7575#comment:8
<ul>
<li><strong>status</strong>
changed from <em>needs_info</em> to <em>needs_review</em>
</li>
<li><strong>author</strong>
set to <em>Robert Miller</em>
</li>
</ul>
TicketJohn CremonaThu, 04 Feb 2010 14:34:41 GMTstatus changed
https://trac.sagemath.org/ticket/7575#comment:9
https://trac.sagemath.org/ticket/7575#comment:9
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
The 1st and 4th items in the TODO list are implemented in <a class="closed ticket" href="https://trac.sagemath.org/ticket/8184" title="#8184: defect: eclib upgrade and bugfix (closed: fixed)">#8184</a> with a new spkg and subsequent patch,
</p>
<p>
I think that logically that patch should be reviewed first, and then this one will need so changes (since a lot of the same functions are affected). I hope others (rlm in particular) will agree! For that reason (only) I have switched this to "needs work".
</p>
TicketRobert MillerThu, 04 Feb 2010 21:01:45 GMTattachment set
https://trac.sagemath.org/ticket/7575
https://trac.sagemath.org/ticket/7575
<ul>
<li><strong>attachment</strong>
set to <em>trac_7575.patch</em>
</li>
</ul>
<p>
depends on <a class="closed ticket" href="https://trac.sagemath.org/ticket/8184" title="#8184: defect: eclib upgrade and bugfix (closed: fixed)">#8184</a>, <a class="closed ticket" href="https://trac.sagemath.org/ticket/8155" title="#8155: defect: add sig_on/sig_off to sage.schemes.elliptic_curves.descent_two_isogeny (closed: fixed)">#8155</a> (and possibly <a class="closed ticket" href="https://trac.sagemath.org/ticket/8124" title="#8124: enhancement: Selmer groups for number fields (closed: fixed)">#8124</a>)
</p>
TicketRobert MillerThu, 04 Feb 2010 21:02:34 GMTstatus, summary changed
https://trac.sagemath.org/ticket/7575#comment:10
https://trac.sagemath.org/ticket/7575#comment:10
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
<li><strong>summary</strong>
changed from <em>Sage's interface with mwrank needs serious work</em> to <em>mwrank interface improvements</em>
</li>
</ul>
TicketJohn CremonaSat, 06 Feb 2010 17:58:11 GMTstatus changed; reviewer set
https://trac.sagemath.org/ticket/7575#comment:11
https://trac.sagemath.org/ticket/7575#comment:11
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
<li><strong>reviewer</strong>
set to <em>John Cremona</em>
</li>
</ul>
<p>
I applied trac_7575.patch successfully to 4.3.2 after first applying everything from
<a class="closed ticket" href="https://trac.sagemath.org/ticket/8184" title="#8184: defect: eclib upgrade and bugfix (closed: fixed)">#8184</a>, <a class="closed ticket" href="https://trac.sagemath.org/ticket/8155" title="#8155: defect: add sig_on/sig_off to sage.schemes.elliptic_curves.descent_two_isogeny (closed: fixed)">#8155</a> and <a class="closed ticket" href="https://trac.sagemath.org/ticket/8124" title="#8124: enhancement: Selmer groups for number fields (closed: fixed)">#8124</a> in that order.
</p>
<p>
The code looks good. It's great now that we do not have to make embarrassing excuses for mwrank's incomplete output!
</p>
<p>
I only spotted one thing: in a couple of places the docstring says that the default search bound is 16, whereas it is in fact 12. (Certainly 12 is more sensible!) That needs changing (trivial). It might be a good idea to alert the user to how expensive (in time) adding one to the bound is, so that (for example) a bound of 20 could lead to the program never ending.
</p>
<p>
One other comment (to rlm): when doing descent by 2-isogeny, when the second descent is used and the coefficients are large, it is a good idea to increase the decimal precision a lot (to 100 or 200 digits) because then the reduction of the second descent quartics is done much better. Now, mwrank will not do that for you (though perhaps it should). I suggest that when mwrank is used on curves with 2-torsion, we first call mwrank_set_precision(200). This will not slow anything down (in fact the opposite) -- but that is not the case for 2-descent in general (no 2-torsion). Perhaps we could do that on another ticket.
</p>
<p>
I tested the whole library with -long after applying this patch and the earlier ones on which it depends (as well as the new eclib spkg at <a class="closed ticket" href="https://trac.sagemath.org/ticket/8184" title="#8184: defect: eclib upgrade and bugfix (closed: fixed)">#8184</a>): all pass!
</p>
<p>
I really hope that this sequence of 4 tickets can all be merged quickly into 4.3.3.
</p>
TicketJohn CremonaSat, 06 Feb 2010 17:59:25 GMT
https://trac.sagemath.org/ticket/7575#comment:12
https://trac.sagemath.org/ticket/7575#comment:12
<p>
PS Robert, please look at those second descent default search limits: 16 is really large, and when I looked again I saw that you really do have 16 as the default. I would suggest using 12.
</p>
TicketRobert MillerSun, 07 Feb 2010 02:04:42 GMTattachment set
https://trac.sagemath.org/ticket/7575
https://trac.sagemath.org/ticket/7575
<ul>
<li><strong>attachment</strong>
set to <em>trac_7575-followup.patch</em>
</li>
</ul>
<p>
Fixes default search bounds
</p>
TicketRobert MillerSun, 07 Feb 2010 02:05:50 GMT
https://trac.sagemath.org/ticket/7575#comment:13
https://trac.sagemath.org/ticket/7575#comment:13
<p>
This last patch sets all defaults (and docstrings) to 12.
</p>
TicketJohn CremonaSun, 07 Feb 2010 11:18:30 GMT
https://trac.sagemath.org/ticket/7575#comment:14
https://trac.sagemath.org/ticket/7575#comment:14
<p>
With the new version of trac_7575-followup.patch everything is 100% fine.
</p>
<p>
Recap: apply everything from <a class="closed ticket" href="https://trac.sagemath.org/ticket/8184" title="#8184: defect: eclib upgrade and bugfix (closed: fixed)">#8184</a>, <a class="closed ticket" href="https://trac.sagemath.org/ticket/8155" title="#8155: defect: add sig_on/sig_off to sage.schemes.elliptic_curves.descent_two_isogeny (closed: fixed)">#8155</a> and <a class="closed ticket" href="https://trac.sagemath.org/ticket/8124" title="#8124: enhancement: Selmer groups for number fields (closed: fixed)">#8124</a> in that order and then both patches here in order. All tests pass, and all looks (very) good!
</p>
TicketMitesh PatelThu, 11 Feb 2010 00:16:17 GMT
https://trac.sagemath.org/ticket/7575#comment:15
https://trac.sagemath.org/ticket/7575#comment:15
<p>
In preparing for 4.3.3.alpha0, I noticed a [minor?] problem : After I run <code>sage -t ell_rational_field.py</code>, there's a new untracked file in the repository:
</p>
<pre class="wiki">$ hg stat
? sage/schemes/elliptic_curves/PRIMES
m
</pre><p>
It contains <code>16180561</code> and sometimes <code>19047851</code>. If this is easy to fix, feel free to add another follow-up patch here.
</p>
TicketJohn CremonaThu, 11 Feb 2010 09:25:43 GMT
https://trac.sagemath.org/ticket/7575#comment:16
https://trac.sagemath.org/ticket/7575#comment:16
<p>
Sorry about that. When eclib programs run they leave behind a file of that name (containing large primes found during the computations, for use in later runs). And it is left in the working directory. This is probably leftover from a testrun I did before committing changes.
</p>
<p>
I think all will be well if you just delete that file.
</p>
TicketMitesh PatelThu, 11 Feb 2010 10:37:47 GMT
https://trac.sagemath.org/ticket/7575#comment:17
https://trac.sagemath.org/ticket/7575#comment:17
<p>
It reappears after <code>make ptestlong</code>, or anywhere I run a <code>sage -t</code> command that includes <code>ell_rational_field.py</code>. Is it possible to save the file to a fixed location?
</p>
<p>
We could
</p>
<ul><li>Add a line to <code>.hgignore</code>.
</li><li>Not add a line to <code>MANIFEST.in</code>.
</li></ul><p>
This should ensure the file is not included in a new <code>sage-*.spkg</code>. But users might complain about the new file appearing elsewhere.
</p>
TicketMitesh PatelThu, 11 Feb 2010 10:45:57 GMTattachment set
https://trac.sagemath.org/ticket/7575
https://trac.sagemath.org/ticket/7575
<ul>
<li><strong>attachment</strong>
set to <em>trac_7575-hgignore_PRIMES.patch</em>
</li>
</ul>
<p>
Add <code>PRIMES</code> to <code>.hgignore</code>. Apply in addition to other patches.
</p>
TicketMitesh PatelThu, 11 Feb 2010 10:47:30 GMT
https://trac.sagemath.org/ticket/7575#comment:18
https://trac.sagemath.org/ticket/7575#comment:18
<p>
I've attached an "hgignore" patch we can use for 4.3.3.alpha0, if it's OK.
</p>
TicketJohn CremonaThu, 11 Feb 2010 11:10:06 GMT
https://trac.sagemath.org/ticket/7575#comment:19
https://trac.sagemath.org/ticket/7575#comment:19
<p>
I'm not quite sure why this has arisen as an issue now, since mwrank/eclib have always used this file. Was it just that I forgot to delete it when preparing the spkg? In which case I could just make a small change to the new eclib spkg at <a class="closed ticket" href="https://trac.sagemath.org/ticket/8184" title="#8184: defect: eclib upgrade and bugfix (closed: fixed)">#8184</a>?
</p>
TicketMitesh PatelThu, 11 Feb 2010 11:47:45 GMT
https://trac.sagemath.org/ticket/7575#comment:20
https://trac.sagemath.org/ticket/7575#comment:20
<p>
Is it a consequence of
</p>
<div class="wiki-code"><div class="code"><pre><span class="gd">- algorithm='mwrank_shell',
</span><span class="gi">+ algorithm='mwrank_lib',
</span></pre></div></div><p>
in <code>EllipticCurve_rational_field.gens</code> and/or <code>EllipticCurve_rational_field.rank</code>?
</p>
TicketJohn CremonaThu, 11 Feb 2010 11:57:48 GMT
https://trac.sagemath.org/ticket/7575#comment:21
https://trac.sagemath.org/ticket/7575#comment:21
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7575#comment:20" title="Comment 20">mpatel</a>:
</p>
<blockquote class="citation">
<p>
Is it a consequence of
</p>
<div class="wiki-code"><div class="code"><pre><span class="gd">- algorithm='mwrank_shell',
</span><span class="gi">+ algorithm='mwrank_lib',
</span></pre></div></div><p>
in <code>EllipticCurve_rational_field.gens</code> and/or <code>EllipticCurve_rational_field.rank</code>?
</p>
</blockquote>
<p>
No, that should not make any difference.
</p>
TicketMitesh PatelThu, 11 Feb 2010 13:02:05 GMT
https://trac.sagemath.org/ticket/7575#comment:22
https://trac.sagemath.org/ticket/7575#comment:22
<p>
If I replace <code>algorithm='mwrank_lib'</code> with <code>algorithm='mwrank_shell'</code> in both argspecs and run <code>sage -b; sage -t ell_rational_field.py</code>, the <code>PRIMES</code> file does not appear. Am I missing something?
</p>
TicketMitesh PatelThu, 11 Feb 2010 14:32:34 GMTstatus changed; resolution, merged set
https://trac.sagemath.org/ticket/7575#comment:23
https://trac.sagemath.org/ticket/7575#comment:23
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>closed</em>
</li>
<li><strong>resolution</strong>
set to <em>fixed</em>
</li>
<li><strong>merged</strong>
set to <em>sage-4.3.3.alpha0</em>
</li>
</ul>
<p>
For the record: The "hgignore" patch is <em>not</em> in 4.3.3.alpha0.
</p>
TicketJohn CremonaThu, 11 Feb 2010 17:38:59 GMT
https://trac.sagemath.org/ticket/7575#comment:24
https://trac.sagemath.org/ticket/7575#comment:24
<p>
I have made some progress in tracking this down.
</p>
<ol><li>When the mwrank shell starts up, it looks to see if there is a file in the local directory called PRIMES. If so, it reads in the contents and uses them (without checking their primality) in a trial division stage of integer factorization.
</li><li>The function that does that is called initprimes(). This function is wrapped in Sage but as far as I can see is not called when the library is used. This should possibly be changed.
</li><li>When integers are factored there is an initial trial division stage. Primes which are detected this way (e.g. if trial division goes up to their square root) are added to a list which is maintained for the session to help in future trial divisions.
</li><li>On exit, if there are any primes in the maintained list (which might be there either because they are read at the start or added when found) then that list is output to a file called PRIMES. In the working directory, and created if it does not already exist, or overwritten if it does.
</li></ol><p>
Now, two of the curves in the doctests for ell_rational_field.rank, namely [1,0,0,0,37455] and [0,0,1,-79,342], have large primes in their discriminants, namely 16180561 and 19047851. These are added to the maintained list of primes when found, and therefore on exit should be output to the file PRIMES.
</p>
<p>
I do not know why the output file is only being produced when mwrank_lib is used. I would expect it to be the other way round! The writing to file is done by a function called when a global instance of a C++ class has its destructor called. I know that that happens when a normal binary finishes executing (since the compiler puts in calls to relevant destructors). But I don't see why those destructors would be called when the library is used. (Until Sage, I had never used my own C++ code as a library in this way, so my knowledge of C++ runs out here.)
</p>
<p>
One solution would be to *only* output to the file PRIMES if it already exists. That way, users of mwrank can still use the functionality it provides (by creating an empty file at the start) but Sage can ignore it. This would require a new patch to the eclib code, to be applied after the one recently applied (p9).
</p>
TicketRobert MillerThu, 11 Feb 2010 17:50:20 GMT
https://trac.sagemath.org/ticket/7575#comment:25
https://trac.sagemath.org/ticket/7575#comment:25
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7575#comment:24" title="Comment 24">cremona</a>:
</p>
<blockquote class="citation">
<p>
One solution would be to *only* output to the file PRIMES if it already exists.
</p>
</blockquote>
<p>
Wouldn't it be better to simply set the location to something in <code>DOT_SAGE</code>, instead of the current directory?
</p>
TicketJohn CremonaThu, 11 Feb 2010 19:55:45 GMT
https://trac.sagemath.org/ticket/7575#comment:26
https://trac.sagemath.org/ticket/7575#comment:26
<p>
Trouble is, eclib currently does not allow this to be changed, it always uses the current dir. I can change that (as I have changed many other similar hard-wired things specifically for Sage!). But it also would require another patch to eclib.
</p>
TicketMitesh PatelMon, 15 Feb 2010 13:06:49 GMT
https://trac.sagemath.org/ticket/7575#comment:27
https://trac.sagemath.org/ticket/7575#comment:27
<p>
I inserted diagnostic "cout" statements in <code>extra_prime_class::~extra_prime_class</code> and ran a few tests. It seems the destructor always gets called, but the timing --- and whether <code>PRIMES</code> is actually written to the file system, it seems --- depends on whether I use the library or pexpect interface.
</p>
<p>
The pexpect interface reads <code>SAGE_ROOT/data/extcode/mwrank/PRIMES</code>. But it doesn't update this file when I quit the Sage command line. However, if I run
</p>
<pre class="wiki">sage -c "EllipticCurve([1,0,0,0,37455]).rank(proof=False)"
</pre><p>
then "hg stat", for example, confirms the file has changed.
</p>
<p>
Would it help to call a <code>exitprimes</code> method explicitly, near the end of <code>main</code>? This <em>might</em> avoid problems related to when the runtime calls the destructor.
</p>
<p>
Disclaimer: I'm not at all familiar with eclib.
</p>
TicketJohn CremonaThu, 25 Feb 2010 09:21:35 GMT
https://trac.sagemath.org/ticket/7575#comment:28
https://trac.sagemath.org/ticket/7575#comment:28
<p>
The quickest quick fix would be just to comment out line 372 in src/procs/marith.cc (in eclib).
</p>
Ticket