RuntimeWarning: overflow encountered in distance #404
Comments
|
I am able to reproduce this; haven't yet determined if this is on the pygeos or the GEOS side. However, the second geography is not valid: I agree that these warnings are not ideal, but if they are limited to invalid geometries, it may not be possible to easily avoid those. |
|
Ah, that was a typo that caused invalid geometry. Fixing the invalid geometry resolved the second warning, the overflow is still there. At least I can see it on this snippet: x, y = 1, 6
g1 = pygeos.box(x, y, x+1, y+1)
g2 = pygeos.box(x-2, y-2, x-1, y-1)
pygeos.distance(g1, g2) |
|
See also #167. It's not really clear to me where the warning is coming from exactly. |
|
According to https://stackoverflow.com/a/7559950/9978945, |
|
I assume the output datatype is float64? As GEOS outputs a double, there should be no typecasting. The overflow is surprising. I wonder were the numpy code is that triggers this warning for float64 output. Haven’t found it yet… |
Do you mean like this? That doesn't make a difference, the warning is still there. pygeos.distance([g1, g2], [g2, g1], out=numpy.ones((2, ), dtype=numpy.float64)) |
|
cc @seberg in case you have an idea about where we could look for finding the reason that our custom ufunc gives such overflow warnings |
Yes exactly. I can't reproduce with your snippet on my system, also when specifying Maybe you can do something like this to inspect the binary output: For my |
|
I get |
|
My current theory is that GEOS internally sets floating point error flags (IEEE 754) and that numpy picks these up and neatly reports them to the user. I see no other way that our wrapping code would trigger such warnings when the output value is in fact completely valid. In that case, a fix should be done upstream in GEOS. |
That sounds right. Below, way too much information that probably doesn't apply :). There are some things that make FPE flags annoying, e.g.:
The desperate solution is to clear the FPE flags manually, although that won't discriminate and in theory you would have to store the flags and then reset them (what if casting causes FPEs to be set. To be clear, NumPy doesn't get this right). In many cases, bad flags are due to compiler optimizations (e.g. you use vectorized units and the compiler decides to optimize away cleaning up the unused part of the SIMD vector, for clang |
|
On closer investigation, this appears to be propagating up from GEOS for boundable geometry comparisons. Compiler environment: I'm building from the tip of GEOS In Comparing points that have the same distance does not raise this warning: whereas lines raise this warning: If we inspect the FPE flags (thanks @seberg for the tip!) after performing the calculation, we see that they are indeed set for overflow in this case: Will look next into writing a test case for GEOS for this specific case to verify that it indeed is happening there. |
|
Was able to reproduce directly in GEOS, see ticket. I don't think there are actions to take here in pygeos, short of clearing floating point exceptions after we call GEOS. |
|
Thanks to some quick work by @pramsey (👏 ), this is now fixed on GEOS I just rebuilt pygeos from the tip of GEOS |
|
You guys are amazing! Thanks! |
|
Closing as this is fixed upstream. Thanks @pramsey for the quick response |
I am getting
RuntimeWarning: overflow encountered in distance, sometimes followed byRuntimeWarning: invalid value encountered in distancewhen doingdistanceon some real-life geometries. MRE below:The result is correct but the errors are confusing and tend to spam the feed. I see the same on macOS and Ubuntu (details below).
macOS environemnt:
Ubuntu environment:
The text was updated successfully, but these errors were encountered: