lycantropos / orient

Geometric queries (point-in-segment, point-in-polygon, polygon-in-polygon, etc.)
https://orient.rtfd.io
MIT License
4 stars 0 forks source link

Wrong `point_in_region()` output when `Point()` is initialized with `numpy.float64` coordinates #1

Open mdealencar opened 2 months ago

mdealencar commented 2 months ago

Analogous error observed for point_in_polygon().

The Point instances return True for equality check.

To reproduce: (Python 3.10.14, numpy 1.26.4, , ground 9.0.0, orient 7.0.0) (Windows 10 64bit)

import numpy as np
from ground import base as ground_base
from orient import planar as orient_planar

context = ground_base.get_context()
Contour = context.contour_cls
Point = context.point_cls
Polygon = context.polygon_cls
Multipolygon = context.multipolygon_cls
Segment = context.segment_cls

contour_np = Contour([Point(*xy) for xy in np.array(((0., 0.), (1., 0.), (0., 1.)))])
contour = Contour([Point(*xy) for xy in ((0., 0.), (1., 0.), (0., 1.))])
pt = Point(0.1, 0.1)

contour_np == contour
True
orient_planar.point_in_region(pt, contour_np)
Location.EXTERIOR
orient_planar.point_in_region(pt, contour)
Location.INTERIOR
mdealencar commented 2 months ago

Exact the same output in Linux-64. Same package versions.

lycantropos commented 2 months ago

numpy types are not supported since comparison of them do not return bool (which can be compared using is/is not operators) but numpy.bool_, which is different and require rewriting all of boolean comparisons to use ==/!= which I do not want, it's ugly, much easier to use regular floats for coordinates instead

mdealencar commented 2 months ago

Thanks for the reply. I think the biggest issue is it apparently working with numpy floats and then behaving unpredictably with no warnings. This bug cost me a few hours to figure out.

Is some automatic type casting something you would consider?