commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <>
Subject [Geometry][Numbers] Blocker issues (Was: [geometry] 1.0 Roadmap)
Date Mon, 03 Dec 2018 09:41:26 GMT
Hi Matt.

Could you please make a list of tasks to be done in [Numbers]
on which [Geometry] relies.  All those should be reported in
JIRA, with their status elevated to "blocker".  We need to have
them implemented, and make an official release of [Numbers]
before [Geometry] can be released (since a release cannot
depend on a SNAPSHOT version).
Perhaps Steve will be able to help here.  Others welcome too...

Best regards,

On Fri, 7 Sep 2018 02:29:21 +0000, Matt Juntunen wrote:
> Hi all,
> I've been working on the new commons-geometry component for a while
> now and I wanted to share with everyone the current state of the
> project and what I'm picturing for the future, up to a 1.0 release.
> Here is where we are now:
>   1.  All of the original geometry code from commons-math has been
> moved to commons-geometry.
>   2.  Code has been split into a number of distinct modules, per Java
> 9+ conventions.
>   3.  The old Vector classes have been completely redesigned and
> refactored into separate Point and Vector classes to better reflect
> the underlying math.
>   4.  All Point and Vector classes are now VALJOs.
>   5.  Support for spherical and polar coordinates has been added.
> Here is what I'd like to still accomplish before a 1.0 release (in
> order of priority):
>   1.  Add additional Vector methods (GEOMETRY-9) -- This includes
> methods like lerp, project, and reject among others. A pull request
> has been submitted for this and is in discussion.
>   2.  Vector normalization optimizations (GEOMETRY-10) -- We can
> avoid a lot of computation by making some tweaks here. I've started 
> on
> this but do not yet have a pull request.
>   3.  Add matrix-based AffineTransform?D classes (GEOMETRY-14) -- We
> are sorely lacking an API to translate, rotate, and scale.
>   4.  Encapsulate concept of tolerance (GEOMETRY-11) -- We currently
> use raw double tolerance values to help determine equality between
> floating point numbers. I think we should encapsulate this into a
> GeometryContext class to ensure that this is done consistently and to
> allow us to easily tweak the algorithm if needed. If anyone has any
> ideas for how to best maintain floating point accuracy here, that
> would be great.
>   5.  API cleanup for Region, Hyperplane, and BSPTree (no JIRA issue
> yet) -- This is a big one and kind of ill-defined. One of the main
> gripes I and other people at my work have had with the old
> commons-math geometry code was that it was awkward to use. You had to
> jump through a bunch of hoops to do things like get the vertices of
> the union of two 2D shapes. I'd like to try to clean this up and
> streamline some of the common use cases. Comments and feedback on 
> this
> would be great.
>   6.  BSPTree optimizations (no JIRA issue yet) -- I have some ideas
> I'd like to try out to speed up the BSP tree code. My unofficial
> benchmark is to convert a model of the Utah teapot I have with ~1000
> facets into a PolygonsSet and back. The current code cannot do this.
> It takes forever and then fails, I believe due to accumulated 
> floating
> point errors. If we can get the code to be able to do this correctly
> and in a reasonable amount of time, then I'd feel good about making a
> release.
> Thoughts? Comments? I have a project at work coming up near the end
> of the year that I'd really love to use commons-geometry on, so 
> that's
> what I'm aiming for in terms of a timeline.
> Thanks,
> Matt Juntunen

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message