On 2011-06-08 18:02, Mike Hansen wrote:
> This should be fixed by
> http://trac.sagemath.org/sage_trac/ticket/11389 which needs review.
Indeed it is fixed by this!
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+
On Wed, Jun 8, 2011 at 9:15 AM, John Cremona wrote:
> Good! Is that an educated guess, or have you tried the speed test
> before & after applying the patch at #11389?
I tried before and after the patch after looking into what was causing
all of the traceback.format_exc to be called.
--Mike
--
On Wed, Jun 8, 2011 at 5:02 PM, Mike Hansen wrote:
> On Wed, Jun 8, 2011 at 4:11 AM, John Cremona wrote:
>> The same used to happen for elliptic curves, until someone (possibly
>> me) decided that it was worth doing two things: (1) if you do want to
>> check that the equation is satisfied, do so
On Wed, Jun 8, 2011 at 4:11 AM, John Cremona wrote:
> The same used to happen for elliptic curves, until someone (possibly
> me) decided that it was worth doing two things: (1) if you do want to
> check that the equation is satisfied, do so in a naive way rather than
> using the whole scheme mach
My guess is that creating the points takes a lot of time since even
though their coordinates have been computed, we still go through a
generic procedure to check that these coordinates satisfy the equation
of the curve, which involves setting up a lot polynomial rings, etc.
The same used to happen
Hi Jeroen,
Using %prun, one finds with sage-4.6.2
ncalls tottime percall cumtime percall
filename:lineno(function)
75041.4020.0002.0990.000 algebraic_scheme.py:
660(_check_satisfies_equations)
40.2770.0693.0960.774 rational_point.py:
237(enum_pro