Hi,
I started to work on the proposed new features, namely convex hull and
voronoi diagrams but am a bit stuck with the API design.
The current type structure in the geometry package introduced a so
called Space with different implementation for 1D, 2D and 3D. To
represent a Vector in the respective space, a Vector<S extends Space>
interface exists, with implementing classes for each Space:
* Vector1D
* Vector2D
* Vector3D
Unfortunately, the Vector interface does not provide a generic access
method to each component, e.g. get(int) to get the ith component of the
vector. Each subclass has its own getX(), getY() ... method according to
the dimension of the Space. This makes it impossible to implement a
generic algorithm using the Space as type parameter.
Ok, so I was thinking about separate algorithms for the different
spaces. Now when trying to generify a ConvexHull interface using the
Space I would have something like this:
public interface ConvexHull<S extends Space> {
Vector<S>[] generate(Vector<S>[] points);
}
e.g. with an implementation of the 2D GrahamScan algorithm:
public class GrahamScan2D implements ConvexHull<Euclidean2D> {
public Vector<Euclidean2D>[] generate(
final Vector<Euclidean2D>[] points) { ... }
}
So the Vector types would not be Vector2D, Vector3D but the generic
ones. Users would need to explicitly cast to them, as I guess these are
more convenient to use.
A better solution would be to ignore the Space for now and define the
interface as follows:
public interface ConvexHull<S extends Space, V extends Vector<S>> {
V[] generate(V[] points);
}
which allows me to use Vector2D and so forth directly in the implementation.
Package structure:
right now the geometry package is structured as follows:
* basic interfaces in the base package
* euclidean package split up for the 1D, 2D and 3D cases
* partitioning package
I started creating a hull package, which will contain the outlined
ConvexHull interface, and implementations, for the different Spaces,
e.g. GrahamScan2D, DivideAndConquer2D, Chan3D
Does this make sense? Or should I stick to the general case and provide
only one algorithm for the 2D and 3D respectively?
Maybe we should also create an algo package which will serve as home for
such algorithms?
Thanks,
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
