You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Matt Juntunen <ma...@hotmail.com> on 2018/09/07 02:29:21 UTC
[geometry] 1.0 Roadmap
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
Re: [geometry] 1.0 Roadmap
Posted by Matt Juntunen <ma...@hotmail.com>.
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 <gi...@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
Re: [geometry] 1.0 Roadmap
Posted by Gilles <gi...@harfang.homelinux.org>.
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
[Geometry][Numbers] Blocker issues (Was: [geometry] 1.0 Roadmap)
Posted by Gilles <gi...@harfang.homelinux.org>.
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,
Gilles
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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org