Reconsider Point behavior

[juliohm]

The following behavior seems super odd:

using GeometricalPredicates

p = Point(1,1)
gety(p)
# 1.5

I always disliked this min_coord=1, max_coord=2 constraint, it is very unpleasant both mathematically speaking and programming-wise, but I believe there is a very good numerical reason for it.

This issue, however, is about the odd behavior of the point type regardless of numerics, can you please reconsider the design?

[skariel]

this is a bug, I was not aware of it. I'll fix it

[skariel]

actually this is not a bug-- as thee docs say the coordinates have to be min_coord <= x <= max_coord and min_coord = 1.0 + eps o obviously using x=1 is outside of this spec...

[skariel]

oops, I was referring to the voronoidelaunay docs... this is really a bug, reopening now

[skariel]

The code seems good, it is like a bug in Julia or something, I'll investigate...

[skariel]

no bug with Julia of course :) the problem is that you are calling Point with integers and the the following method gets called down the line: Point2D(peanokey::Int64, bits::Int64=peano_2D_bits)

I'm not sure this doesn't make sense, it is certainly not a bug, just confusing

[dkarrasch]

Could it be that we should have

Point(x::Real, y::Real) = Point2D(float(x), float(y))
Point(x::Real, y::Real, z::Real) = Point3D(float(x), float(y), float(z))

? Point has only these two methods, and there is no confusion with the peano-key functions Point2D and Point3D.