You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If we want to rely on using an RTree for some of our operations (like
the Relate trait) we have to ensure our numeric types are RTree
compatible.
== Alternative considered
Since RTreeNum isn't necessarily a float, we could instead add these new
bounds to GeoNum instead of GeoFloat.
However, doing so would mean dropping support for unsigned ints from
GeoNum. Note that using unsigned ints now, while supported, can easily
lead to underflow if you're using one of the many operations that
involve subtraction.
It would also put one more barrier between ever getting BigDecimal
support in geo - which is not Bounded.
Also, apparently Float isn't necessarily Signed, but having never
personally encountered unsigned floating point in the wild, I don't have
strong feelings about retaining support for it.
And since Relate doesn't current support non-floats, this would be a
cost with no benefit. If that changes, we could reconsider this
decision, or perhaps add the required behavior to some derivative type,
like one of the HasKernel implementations.
0 commit comments