2022-01-27 05:07:43 +0200 | received badge | ● Good Question (source) |
2020-01-04 23:43:15 +0200 | received badge | ● Notable Question (source) |
2018-12-02 18:51:26 +0200 | received badge | ● Notable Question (source) |
2018-12-02 18:51:26 +0200 | received badge | ● Popular Question (source) |
2018-06-16 19:35:02 +0200 | received badge | ● Popular Question (source) |
2014-08-06 20:22:23 +0200 | answered a question | $p$-adic regulator calculations I was thinking I should add an answer of my own since it's too long for a comment. I did some digging into the github library files and got the following comment: on lines 1907-1916 of this. So in effect, there is currently no code yet for taking the generators directly from the Cremona Database. I have very limited knowledge in programming and coding but based on my experimentation so far, this is what I got on SAGE in terms of trying to get the code from the generators in the database: Then essentially P are the generators that we need, except that they are in the form of a nested list, ie. [[a,b,c],[d,e,f],...] as opposed to when using E.gens() and getting output as [(a : b : c),(d : e : f),...] With this workaround, I can now obtain padic heights -> the padic height matrix and the discriminant -> padic regulator. Of course this hasn't been written into a proper code yet but it is a workaround. |
2014-08-06 18:49:49 +0200 | received badge | ● Nice Question (source) |
2014-08-06 12:55:56 +0200 | received badge | ● Scholar (source) |
2014-08-06 12:39:14 +0200 | commented answer | $p$-adic regulator calculations Do you mean I can just call the generator(s) by D=Cremona Database D.allgens()[] and use x.padic_regulator or do I then have compute the padic_regulator from there manually (which means there's a string of code that you didn't show)? |
2014-08-06 12:28:14 +0200 | received badge | ● Supporter (source) |
2014-08-05 12:38:17 +0200 | asked a question | $p$-adic regulator calculations Why can't some $p$-adic regulators be calculated? The first case where this happens is the curve 3314b3. I received the following error message after using this code: RuntimeError: Unable to compute the rank, hence generators, with certainty (lower bound=0, generators found=[]). This could be because Sha(E/Q)[2] is nontrivial. Try increasing descent_second_limit then trying this command again. |
2014-08-04 11:33:38 +0200 | asked a question | Use vim, emacs, or pico from a terminal instead. I received the following error message: Unable to open 'regs_20k_40k_out' - "Attempt to open large file of size 19MB; the maximum allowed size is 10MB. Use vim, emacs, or pico from a terminal instead." How do I go about opening this file? |
2014-07-12 01:17:34 +0200 | received badge | ● Editor (source) |
2014-07-11 11:03:24 +0200 | received badge | ● Student (source) |
2014-07-11 01:06:23 +0200 | commented question | Computation gets killed every couple of hours This is in the cloud and using a notebook. I have infinite timeout on the cloud so it's not a timeout issue. When looking at the results, the memory usage shows that it doesn't fully reset or remain constant. Should this be the case even thought I already have gc.collect()? |
2014-07-10 18:55:19 +0200 | asked a question | Computation gets killed every couple of hours I'm running the following computation (in parallel for different range of curves) but sage keps killing my computation every couple of hours. For the first few curves, it does fine and then when computation time takes something in the range of >3000s (~1hr), it will suddenly kill the computation without any warning. This had led to a lot of frustration because there is no way for me to tell what is actually going wrong. We initially thought it was a memory leak issue and hence we added in gc.enable and this only helped for the simpler computations. It still didn't seem to make any difference for the ones that would have failed in the case where gc.enable was not added in previously. I can understand if the computations may take a really long because the computation for the L-series is exponential (?), but that doesn't seem to be a reason for the computation to get killed. Also, when I start again at the last prime p that the computation gets killed at, sometimes it works and the computation carries on but gets killed later, sometimes it doesn't work at all. Could anybody potentially help to remedy this or point me in the direction of how to make the code better? Thanks. curves_list= ['30502b1', '30503b1', '30518c1', '30518d1', '30519f1', '30520a1', '30525w1', '30525x1', '30525bb1', '30530c1', '30530f1', '30534a1', '30535a1', '30535c1', '30537i1', '30537l1', '30544f1', '30544k1', '30550b1', '30550e1', '30550n1', '30550q1', '30550v1', '30550y1', '30558a1', '30558d1', '30564b1', '30564c1', '30564l1', '30565b1', '30566b1', '30573d1', '30575c1', '30576b1', '30576u1', '30576bf1', '30576bz1', '30576cb1', '30576cr1', '30576cs1', '30585c1', '30589b1', '30589d1', '30594a1', '30594b1', '30594d1'] Step 3: find the last curve you computed data forimport gc gc.enable() i = curves_list.index('30519f1') #this is the curve for which it stopped Step 4: put in the [i:] in the next linefor x in curves_list[i:]: ##put in [i:] a = gc.collect() E = EllipticCurve(x) print E.cremona_label() sys.stdout.flush() Step 5: now add this as a case to pick up where you left off Step 6: add in an else and the code below (more) |