[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [geometry] 1.0 Roadmap


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.

From: Gilles <gilles@xxxxxxxxxxxxxxxxxxxxx>
Sent: Saturday, December 15, 2018 9:52 AM
To: dev@xxxxxxxxxxxxxxxxxx
Subject: Re: [geometry] 1.0 Roadmap


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.

In progress.  PR provided but design is under discussion:

>   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.

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]).


If we agree, what timeline are we talking about?


> 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-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx