search

tylerjereddy / scipy

Scipy library main repository
http://scipy.org/scipylib/
BSD 3-Clause "New" or "Revised" License
1 stars 1 forks source link

Default to unit sphere behaviour in constructor #8

Closed niknow closed 4 years ago

niknow commented 8 years ago

The constructor of SphericalVoronoi allows to pass center and radius of the sphere as optional arguments. While not passing a center defaults to the origin, not passing a radius defaults to a radius estimation. Since this is inconsistent and might cause quite some computation in the constructor, I would suggest to remove the estimation and make the constructor default to the unit sphere completely. We could still add helper functions to estimate center and radius if we want to.

tylerjereddy commented 8 years ago

So, the user would have to convert to unit sphere coordinates beforehand? If we go that route, I think it would at least be sensible to ensure that the area calculations can be adjusted to return values for a specific radius. I think that is already the case anyway, as r^2 is in the spherical polygon surface area calculation.

It is maybe a little awkward that an end user would have to project their coordinates back to the appropriate radius after using the code though, but placing the burden of this projection / conversion on our code is probably asking for trouble.

Should there also be some kind of check to ensure that the input data in on the unit sphere?

niknow commented 8 years ago

No, the user would not have to convert beforehand. If the user does not specify a radius and center, the constructor will assume the unit sphere. If the user specifies radius and center, everything will work fine on the specified sphere. The only situation where one would have to do something manually would be if one wants to calculate the Voronoi diagram of points on a sphere with unknown center and radius. This is probably not realistic?

tylerjereddy commented 8 years ago

Ok, and if the user fails to provide radius and / or center arguments will the code be able to detect that there is a problem if the data is not on the unit sphere, or will we have to settle for a cryptic exception somewhere in the control flow?

Since the generators may not be distributed evenly on the sphere, it would be non-trivial to determine the actual center of the sphere (since it would not be the centroid of the points if they are biased to one hemisphere, etc.). One could check the diameter of the input sphere by determining the maximum Euclidean chord length from a distance matrix of all generators, but that would also be pretty expensive just for checking input.