Hello.
I added JIRA issues for everything that I think still needs to be done. The
issue breakdown is as follows:
3. Affine Transforms
- GEOMETRY-14 (PR open)
- GEOMETRY-24 (followup issue)
4. Tolerance
- GEOMETRY-11 (high priority)
5. API Cleanup
- GEOMETRY-27
- GEOMETRY-28
- GEOMETRY-29
- GEOMETRY-32
- GEOMETRY-33
6. Optimization
- GEOMETRY-34
I think it would be great to get a beta release out soon. The only limiting
factor for me is the amount of free-time I have, which is generally in a state
of flux.
-Matt
________________________________
From: Gilles <gil...@harfang.homelinux.org>
Sent: Saturday, December 15, 2018 9:52 AM
To: dev@commons.apache.org
Subject: Re: [geometry] 1.0 Roadmap
Hi.
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.
Done.
> 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.
Done.
> 3. Add matrix-based AffineTransform?D classes (GEOMETRY-14) -- We
> are sorely lacking an API to translate, rotate, and scale.
In progress. PR provided but design is under discussion:
https://issues.apache.org/jira/browse/GEOMETRY-14
> 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.
Open.
> 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.
Status?
> 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.
Status?
>
> 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.
I'm very much for RERO.
However, given the lack of feedback for this component, we cannot
be confident that no corners have been cut for such a large code
base (8526 LOC as of today[1]).
Hence I'd like to release (ASAP) a _beta_ version of what we have,
such that the functionality can be put to use (and problems, design
or bugs, arise from actual use cases).
[Geometry] depends on [Numbers] whose first release is also long
overdue! But the lack of feedback applies to the latter too, and
I thus also propose to prepare a beta version of it.
The safer approach[2] is to put _all_ codes under a new top-level
package (e.g. "org.apache.commons.geometry.beta").
That name would remain the same for all beta releases, _without_
any BC requirement (hence JAR hell _can_ occur, but is explicitly
allowed in beta releases[3]).
WDYT?
If we agree, what timeline are we talking about?
Regards,
Gilles
> Thanks,
> Matt Juntunen
[1] Down 10% from the original "Commons Math" code base, but with
more features (IIUC). :-)
Actually, AFAICT, the work by Matt is the first ever large
scale review/refactoring of the code contained in "geometry"
package of "Commons Math".
[2] IIUC the scarce discussions, without any firm conclusions,
about how our "Commons" project should deliver alpha/beta
releases. [Directions still welcome...]
[3] Cf. ML archive. If PMC members disagree, please speak up now.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
