New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[fixed by #6671] bug in delta_qexp over finite fields #6020
Comments
Attachment: trac-6020.patch.gz |
comment:1
Okay, I've attached a patch. The issue is that we can't coerce from NTL into a finite field. This patch isn't anything too clever -- I just do the naive thing and work over the base ring from the start instead of using NTL. It runs at the same speed for |
comment:2
Wait a minute:
to
results in code that is way faster! That's because FLINT kick's NTL's ass, and FLINT is the default for poly's over ZZ now. Just get rid of the flint implementation. With NTL (on my OS X laptop):
With the "False" as above inserted, so FLINT gets used:
|
comment:3
This is pretty interesting: I get entirely different timings on my laptop, which is why I didn't remove the NTL code. I wonder if something funky went on with my FLINT compilation? The
The
That seems really weird ... I'm going to try looking at this tomorrow when I'm sitting next to you. This is kinda weird; I'd like to do some random timing comparisons. |
comment:4
On my 32-bit Linux laptop, I get these timings: With NTL:
With FLINT, i.e. with the "if False" hack:
So FLINT is faster for me (but not by so much as for William). |
comment:5
What is the status here? Cheers, Michael |
comment:6
I'm going to fix this soon, at SD15 if not before. (Me giving three talks during SD15 may prevent it from happening before.) Here's the status, though: we've discovered that on 64-bit OSX and on I'm changing the status to something slightly snarky to summarize the above. :) |
comment:7
As I said #6671 I merge this with the new code given there. I did some timings and the result is clear: Coercion into the new ring after using FLINT is fast.
I conclude that it is better to wait for Craig's new code. If nobody is opposed I will asked the current release manager (I think it's Minh) to make this as closed (since it is fixed by #6671). |
comment:10
Closed as requested (fixed by #6671). |
This is in sage-3.4.2:
I don't have time to investigate this right now, but it might be a similar issue as #5102.
Component: modular forms
Keywords: delta q-expansion finite field
Issue created by migration from https://trac.sagemath.org/ticket/6020
The text was updated successfully, but these errors were encountered: