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
riemann.pyx gives lots of invalid value in divide warnings #10821
Comments
This comment has been minimized.
This comment has been minimized.
comment:1
Ethan, I noticed several things that could be pulled out of the inner loop, and so rewrote this line in the attached patch. However, I don't know this code or the algorithms very well---can you look at the patch? It appears that the warnings happen when there is a division by zero, as in this test case:
So should we turn off the error checking for this error when doing this operation since at least one entry in cp-cp[t] will be zero? Or should we check for zero denominators and not calculate the fraction with those? |
comment:3
Attachment: trac-10821-riemann-invalid-divide.patch.gz Unfortunately, it appears that I really changed something in my patch, or introduced a significant amount of numerical error, as now the doctests give results that are way different than documented. |
comment:4
I am not sure what to do with arrays quoted with indices and without, as in:
but I am fairly sure you attached .conjugate() to the wrong expression. |
my own version of the patch |
This comment has been minimized.
This comment has been minimized.
comment:5
Attachment: trac-10821-riemann-invalid-divide.2.patch.gz This code generates a square array of dimension NB. The 't'th row is generated by (among other things) computing the difference between every element of cp and cp[t]. That's the meaning of
fbissey: It looks like your patch is correct, I'll try it shortly. Jason: If it interests you, this section of code is preparing a square matrix for nystrom numerical integration. The computing the square array will of course end up with illegal divisions for the 't'th element of the 't'th row. However, the next line of code:
overwrites the bad elements with 1's. Thus the divisions by zero don't affect the algorithm. (If we have any other divisions by 0, that means that the user has tried to evaluate a self intersecting figure (and gotten very unlucky) for which the algorithm is meaningless anyway.) We can deal with the zero divides whatever way fits sage style best. If there's an efficient way to not perform those divisions that's fine. Otherwise I have no problems with simply ignoring the warnings.
|
comment:6
Replying to @sagetrac-evanandel:
I will think about that a little bit but given the context we can indeed ignore |
comment:7
Do I have the syntax right in thinking that K off-diagonal elements are defined by
or do I have i and j mixed up? |
comment:8
Seeing this made me look through riemann.pyx, and it turns out that file could use some general TLC. Esp. with regard to a few doc things and some fairly massive redundancy with complex plots. See #10945. |
slight fix |
comment:9
Attachment: trac-10821-riemann-invalid-divide.3.patch.gz Alright, I wrapped the offending code in calls that tell numpy to ignore those invalid divide warnings then restore the original settings. It seems to fix things well. |
comment:11
Okay, the code seems right, (and slightly refactored but fine), conforms with Numpy specs, passes the tests, and Ethan says it's correct for his algorithm. |
Author: François Bissey, Jason Grout |
Reviewer: Ethan Van Andel, Karl-Dieter Crisman |
Merged: sage-4.7.1.alpha0 |
I keep getting Warning: invalid value encountered in divide, and the error happens in these lines in the _generate_theta_array function in calculus/riemann.pyx:
CC: @sagetrac-evanandel @kiwifb
Component: calculus
Author: François Bissey, Jason Grout
Reviewer: Ethan Van Andel, Karl-Dieter Crisman
Merged: sage-4.7.1.alpha0
Issue created by migration from https://trac.sagemath.org/ticket/10821
The text was updated successfully, but these errors were encountered: