-
-
Notifications
You must be signed in to change notification settings - Fork 510
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
changed from zeta(CDF(1)) go boom! + zeta of 1 return value be consistent in different rings #5739
Comments
comment:1
I think Robert Bradshaw massively optimized CDF special functions, and that's where this comes from. Changing the code for zeta in complex_double.pyx to:
somewhat fixes the problem, though doing
then raises a RuntimeError. Unfortunately, doing this doesn't work because the _sig_on/_sig_off stuff doesn't play well with Cython exceptions:
So I'm not sure how to fix this in general in a nice way with the right exception, but definitely adding _sig_on/_sig_off's around all the calls to pari is a very very good idea. |
comment:2
We should be able to replace the calls to pari with calls to mpmath. |
Author: Mike Hansen |
comment:5
Attachment: trac_5739.patch.gz The patch looks fine, but results in zeta of a CDF being approximately fifty times slower. This seems problematic, and perhaps also something that would happen a lot if we start switching things to mpmath? Mpmath looks like a great package, but if it has the same issue as NetworkX versus C graphs, we might not want to move default behavior there quite yet. Marking as needs_info since there does not seem to be a Sage-wide policy on mpmath at this point, and I am reluctant to give positive review to such a marked slowdown. |
Attachment: 5739-CDF-zeta.patch.gz |
comment:6
I added an alternative patch that special cases the one pole at s=1 (returning the unsigned infinity, as gamma does). |
comment:7
I hate to send this back to the drawing board again, but let's just fix things once and for all...
Can we think of any other places where this needs to be checked? For instance, zeta(1) returns this error too, though I think it inherits it from the CC example. Also, regarding whether it should be Infinity or some signed infinity:
I'm not saying which one is better, just what the current behavior is. What do folks think? |
Reviewer: Karl-Dieter Crisman, Robert Bradshaw |
comment:8
kcrisman: Starting with the next version, mpmath uses the Riemann-Siegel formula, so it should be much faster than Pari for large imaginary parts near the critical strip. Right now I even get a segmentation fault if I try to compute zeta(CDF(1/2+10000000*I)) in Sage. For CDF, zeta could also use mpmath.fp.zeta that will be available in the next version of mpmath. This function is currently typically 10-50 times faster than mpmath.mp.zeta. However, fp.zeta loses accuracy proportional to the magnitude of the imaginary part near the critical strip, so the question is whether this loss would be acceptable. For small imaginary parts, it's quite accurate. Both functions could be accelerated in Sage by overriding the base case of an internal function (mpmath/functions/zeta.py/_zetasum in the svn trunk, if anyone wants a go). This should require just few lines of Cython. Other than that, I would recommend keeping Pari where it's faster. |
Attachment: 5739-CC-RR.patch.gz apply this and 5739-CDF-zeta.patch |
comment:9
I fixed CC. As to whether it should be a signed or unsigned infinity, I went with unsigned because it has a simple pole there.
When the new mpmath gets released, we could open a ticket with timings and accuracy comparison. Generally we favor correctness over speed. |
comment:11
Patch applies cleanly to 4.5.alpha1 and builds fine, but some doctests fail:
Moreover, it doesn't seem to live up to the promise in the title of making the return value of zeta(1) consistent:
|
comment:12
Since #8864, |
Attachment: 5739-complex-zeta.patch.gz apply only this patch |
comment:13
It's really sad we still have this trivial-to-fix hard crash after over a year! I've attached a patch that fixes the behavior of CDF(1).zeta() and CC(1).zeta(). It leaves the real fields alone, which I think is fine 'cause they have reasonable representations of (an) infinity, and we usually try to return something of the same type. (IN the complex case, infinity is a lot messier without a lot of special casing that's beyond the scope of this ticket...)
|
Changed author from Mike Hansen to Mike Hansen, Robert Bradshaw |
comment:14
OK, that looks fine. I'd still argue that it should be an unsigned infinity in the real field cases as well, but (as you say) more or less anything is better than the current behaviour! Let's get this in. |
Changed reviewer from Karl-Dieter Crisman, Robert Bradshaw to Karl-Dieter Crisman, Robert Bradshaw, David Loeffler |
comment:15
The patch is missing a Mercurial header. Could someone add this and restore the positive review? |
Version with Mercurial header |
comment:16
Attachment: 5739-complex-zeta-with-header.patch.gz Done |
Merged: sage-4.6.alpha2 |
CC: @robertwb @sagetrac-fredrik
Component: number theory
Author: Mike Hansen, Robert Bradshaw
Reviewer: Karl-Dieter Crisman, Robert Bradshaw, David Loeffler
Merged: sage-4.6.alpha2
Issue created by migration from https://trac.sagemath.org/ticket/5739
The text was updated successfully, but these errors were encountered: