-
Notifications
You must be signed in to change notification settings - Fork 245
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
new acb_theta module #1470
new acb_theta module #1470
Conversation
This reverts commit 40d0916.
Another thing we talked about is having documentation for the tests. It wouldn't be too much for me to write in in the rst file (or somewhere else), but it would clash with the rest of FLINT. |
Sets a precedent to improve the rest of FLINT then ;-) |
Ok! Do you have a preference between documenting each test right after the function as I did in the pdf documentation before, or at the end of the rst file? |
I would prefer to have them at the end of the file, so that it preserves the readability for the user part of the documentation. Very nice idea to document the tests! |
I wrote documentation for the tests (and profiling code while I was at it) in 71d2a46. If you have any thoughts on the format or wording let me know! |
The documentation looks excellent! I tried to compare the performance of acb_modular_theta and acb_theta_all for tau = i, z = sqrt(2) and I get a crossover around 2-3 million bits. Is that reasonable? For z = 0 the crossover looks astronomical. It's worth noting that acb_modular_theta has some code for detecting special cases where the real or imaginary part in the output is exactly zero, so one gets a prettier (and slightly more precise) enclosure. Is that something possible and worth doing for g > 1 also? |
For theta constants with tau = i, there is still a 4x difference between acb_modular_theta and acb_theta_all at 10^8 bits, which is around where acb_modular_theta runs out of memory on my machine. Obviously, losing a factor 4x in speed at that point is better than killing the process... |
I would say unless those changes are trivial, we should postpone implementing those optimizations. |
Yeah, crossovers between the classical and asymptotically fast implementations in the g = 1 case are supposed to go in a future PR. Just asking if I'm seeing the expected results. |
No, somehow that's not the results I would expect - I would expect the crossover to be much earlier, at a few thousand bits maybe. (I remember observing this before.) I'll try to investigate this but I'll be busy with other things until Monday. In the meantime, can you try to do timings for |
For the other question about special values, yes, we still have such properties in higher dimensions - e.g. theta constants are real when the matrix is purely imaginary, I believe. I haven't implemented this yet, but it wouldn't be difficult. |
In any case, don't hesitate to do a final rebase and unset the draft status on this PR. The current code is excellent and I'd be happy to merge it sooner rather than later. |
There's basically no difference between |
Thanks, I'll take a look then! Github tells me "Only those with write access to this repository can mark a draft pull request as ready for review." |
OK, fixed. |
The crossover between |
Valgrind passed. |
Confirmed! |
Thank you all! |
The purpose of this module is to provide methods for the numerical evaluation of theta functions in any dimension.
I make this PR as a draft, as I am not sure if @j-kieffer thinks it is ready for review.
But I think it would be helpful to start looking at it, particularly the auxiliary code that does the obvious things.
Here is some documentation documentation
ps: @j-kieffer, no pressure in working on the code this week, just there are a couple of folks here this week who are keen on looking into it.