commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Juntunen <matt.juntu...@hotmail.com>
Subject Re: [geometry] 1.0 Roadmap
Date Sun, 16 Dec 2018 20:03:18 GMT
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 <gilles@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message