[jira] [Commented] (GEOMETRY-110) 3D Convex Hull
[ https://issues.apache.org/jira/browse/GEOMETRY-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17841554#comment-17841554 ] Matt Juntunen commented on GEOMETRY-110: [~agoss], I've merged the implementation you provided in [PR #255|https://github.com/apache/commons-geometry/pull/225]. Thank you for your work on this! > 3D Convex Hull > -- > > Key: GEOMETRY-110 > URL: https://issues.apache.org/jira/browse/GEOMETRY-110 > Project: Commons Geometry > Issue Type: New Feature >Reporter: Matt Juntunen >Assignee: Matt Juntunen >Priority: Major > Fix For: 1.1 > > > We currently only have a 2D convex hull generator implementation. We should > add a 3D convex hull implementation, perhaps based on the > [Quickhull|https://en.wikipedia.org/wiki/Quickhull] algorithm. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GEOMETRY-110) 3D Convex Hull
[ https://issues.apache.org/jira/browse/GEOMETRY-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782582#comment-17782582 ] Matt Juntunen commented on GEOMETRY-110: Awesome! Thanks, [~agoss]! I'll plan on taking a look this weekend. > 3D Convex Hull > -- > > Key: GEOMETRY-110 > URL: https://issues.apache.org/jira/browse/GEOMETRY-110 > Project: Commons Geometry > Issue Type: New Feature >Reporter: Matt Juntunen >Assignee: Matt Juntunen >Priority: Major > Fix For: 1.1 > > > We currently only have a 2D convex hull generator implementation. We should > add a 3D convex hull implementation, perhaps based on the > [Quickhull|https://en.wikipedia.org/wiki/Quickhull] algorithm. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GEOMETRY-155) Implement getMidpoint(Vector x)
[
https://issues.apache.org/jira/browse/GEOMETRY-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743605#comment-17743605
]
Matt Juntunen commented on GEOMETRY-155:
This can be done by multiplying the vector by 0.5. There is no need for a
separate method for this.
{code:java}
Vector3D v = ...
Vector3D midPoint = v.multiply(0.5);
{code}
> Implement getMidpoint(Vector x)
> ---
>
> Key: GEOMETRY-155
> URL: https://issues.apache.org/jira/browse/GEOMETRY-155
> Project: Commons Geometry
> Issue Type: New Feature
> Components: euclidean1D, euclidean2D, euclidean3D
>Reporter: Dimitrios Efthymiou
>Priority: Minor
> Labels: features
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> It takes a vector and returns the point that is in the middle of the vector
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GEOMETRY-150) implement isCodirectionalTo(Vector y)
[ https://issues.apache.org/jira/browse/GEOMETRY-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743601#comment-17743601 ] Matt Juntunen commented on GEOMETRY-150: I believe this method is general enough and useful enough to warrant adding it. Since we must maintain backwards compatibility with 1.0 for 1.1, we need to add it as a default method to the interface, which (as mentioned before) we can do. It may be that we can override the default implementation in some cases for better performance. I'm not sure on that yet. > implement isCodirectionalTo(Vector y) > - > > Key: GEOMETRY-150 > URL: https://issues.apache.org/jira/browse/GEOMETRY-150 > Project: Commons Geometry > Issue Type: New Feature > Components: euclidean1D >Reporter: Dimitrios Efthymiou >Priority: Minor > Labels: features > Fix For: 1.1 > > Original Estimate: 1h > Remaining Estimate: 1h > > implement isCodirectionalTo(Vector y) method in the Vector interface. The > isCodirectionalTo() checks if the 2 vectors point at the same direction. This > means that each vector can be obtained from the other by multiplying by a > positive scalar. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GEOMETRY-154) Implement divideVectorWithRatio(Vector x, double ratio)
[
https://issues.apache.org/jira/browse/GEOMETRY-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743597#comment-17743597
]
Matt Juntunen commented on GEOMETRY-154:
[~dimitrios.efthymiou], I'm not sold on the idea of adding this method based on
these use cases. For the graphics use case, there is already the
{{EuclideanVector.lerp}} method, which linearly interpolates between two
vectors. For the other use cases, one can compute the desired length ratios and
then use scalar multiplication to get the desired vectors. The computation of
the length ratios will depend on what the caller is trying to do and so should
not be part of this library, IMHO.
Ex:
{code:java}
// point between other points
Vector3D a = Vector3D.of(1, 2, 3);
Vector3D b = Vector3D.of(4, 5, 6);
Vector3D midPoint = a.lerp(b, 0.5);
// split the vector into two parts; in this case, we'll just do a simple 1/4,
3/4 split
Vector3D oneQuarter = a.multiply(0.25);
Vector3D threeQuarters = a.multiply(0.75);
{code}
> Implement divideVectorWithRatio(Vector x, double ratio)
> ---
>
> Key: GEOMETRY-154
> URL: https://issues.apache.org/jira/browse/GEOMETRY-154
> Project: Commons Geometry
> Issue Type: New Feature
> Components: euclidean1D, euclidean2D, euclidean3D
>Reporter: Dimitrios Efthymiou
>Priority: Minor
> Labels: features
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> It takes a vector, say, u = (10) and divides it with ratio, say 1/2. That
> will return a pair of vectors v = (3.33) and w = (6.66). Regardless of
> dimensions, both vectors start at the point of origin
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GEOMETRY-154) Implement divideVectorWithRatio(Vector x, double ratio)
[ https://issues.apache.org/jira/browse/GEOMETRY-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743573#comment-17743573 ] Matt Juntunen commented on GEOMETRY-154: What would be a use case for this method? I'm not seeing one right off the bat. > Implement divideVectorWithRatio(Vector x, double ratio) > --- > > Key: GEOMETRY-154 > URL: https://issues.apache.org/jira/browse/GEOMETRY-154 > Project: Commons Geometry > Issue Type: New Feature > Components: euclidean1D, euclidean2D, euclidean3D >Reporter: Dimitrios Efthymiou >Priority: Minor > Labels: features > Original Estimate: 3h > Remaining Estimate: 3h > > It takes a vector, say, u = (10) and divides it with ratio, say 1/2. That > will return a pair of vectors v = (3.33) and w = (6.66). Regardless of > dimensions, both vectors start at the point of origin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GEOMETRY-150) implement isCodirectionalTo(Vector y)
[
https://issues.apache.org/jira/browse/GEOMETRY-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743185#comment-17743185
]
Matt Juntunen commented on GEOMETRY-150:
A few comments:
- {{Vectors}} is in the {{internal}} package and is not intended to be part of
the public API. We should not add any method intended for public use there.
- Two vectors are codirectional if the dot product of their normalized forms is
equal to 1. But how close to 1 do we have to be in order to return true? This
makes me think that this method needs to accept a
{{Precision.DoubleEquivalence}} in order to allow the caller to specify how
close we need to be.
- This could possibly be implemented as a default method in {{Vector}} with
something like this:
{code:java}
default boolean isCodirectionalWith(final V other, final
Precision.DoubleEquivalence precision) {
final V thisNormalized = normalizeOrNull();
final V otherNormalized = other.normalizeOrNull();
if (thisNormalized != null && otherNormalized != null) {
final double dot = thisNormalized.dot(otherNormalized);
return precision.eq(dot, 1.0);
}
return false;
}
{code}
> implement isCodirectionalTo(Vector y)
> -
>
> Key: GEOMETRY-150
> URL: https://issues.apache.org/jira/browse/GEOMETRY-150
> Project: Commons Geometry
> Issue Type: New Feature
> Components: euclidean1D
>Reporter: Dimitrios Efthymiou
>Priority: Minor
> Labels: features
> Fix For: 1.1
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> implement isCodirectionalTo(Vector y) method in the Vector interface. The
> isCodirectionalTo() checks if the 2 vectors point at the same direction. This
> means that each vector can be obtained from the other by multiplying by a
> positive scalar.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GEOMETRY-144) Review API in "hull" module
[
https://issues.apache.org/jira/browse/GEOMETRY-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17690953#comment-17690953
]
Matt Juntunen commented on GEOMETRY-144:
Sounds great! Thank you for your contributions on this!
> Review API in "hull" module
> ---
>
> Key: GEOMETRY-144
> URL: https://issues.apache.org/jira/browse/GEOMETRY-144
> Project: Commons Geometry
> Issue Type: Task
>Reporter: Gilles Sadowski
>Assignee: Gilles Sadowski
>Priority: Minor
> Fix For: 1.1
>
>
> Review codes in the
> [{{commons-geometry-hull}}|https://gitbox.apache.org/repos/asf?p=commons-geometry.git;a=tree;f=commons-geometry-hull;hb=HEAD]
> module.
> (x) Minimize the public API
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GEOMETRY-144) Review API in "hull" module
[
https://issues.apache.org/jira/browse/GEOMETRY-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17687515#comment-17687515
]
Matt Juntunen commented on GEOMETRY-144:
bq. i think that is a good proposition. At least in the three-dimensional case
the Mesh seems to be more fitting than ConvexHull. What would we then do with
two-dimensional algorithm is the end product LinePath?
Great! Yes, {{LinePath}} is what I was picturing for 2D.
bq. Having thought about it some more i believe we could go with the Builder
pattern and make use of some heuristic like the Akl- Toussaint in the two
dimensional case. I think one could continuously adjust the given quadrangle
constructed and test all points previously added against it. Matt Juntunen you
probably had something similar in mind.
Yes, exactly. I'm picturing a simple test as points are added to skip points
clearly not on the hull. After that, the full {{Quickhull}} algorithm would be
run on what remains.
> Review API in "hull" module
> ---
>
> Key: GEOMETRY-144
> URL: https://issues.apache.org/jira/browse/GEOMETRY-144
> Project: Commons Geometry
> Issue Type: Task
>Reporter: Gilles Sadowski
>Assignee: Gilles Sadowski
>Priority: Minor
> Fix For: 1.1
>
>
> Review codes in the
> [{{commons-geometry-hull}}|https://gitbox.apache.org/repos/asf?p=commons-geometry.git;a=tree;f=commons-geometry-hull;hb=HEAD]
> module.
> (x) Minimize the public API
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GEOMETRY-144) Review API in "hull" module
[
https://issues.apache.org/jira/browse/GEOMETRY-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17684354#comment-17684354
]
Matt Juntunen commented on GEOMETRY-144:
[~agoss], I've looked over your PR and it's looking good. I would like to see
more unit tests, particularly in the areas of asserting the expected output
vertices, checking that the algorithm is not sensitive to the order of the
input points, and testing cases where input points are very close to each other
wrt the configured precision. Before, we get there, though, I believe we first
need to come to a consensus on the public API we want. Your suggestion of doing
away with the {{ConvexHull3D}} interface and just using {{ConvexVolume}} got me
thinking more about what is actually needed here. My primary use case for
convex hull generation is during mesh manipulation. For example, you have a set
of geometries in mesh form and you want to compute the convex hull of all of
them together. This is a major reason I'm hesitant to use {{ConvexVolume}}: the
mesh form of the hull is generated directly in the algorithm and if that is the
desired end product, then converting to a {{ConvexVolume}} is just wasted work.
What, then, do you think of using {{Mesh}} as the end product of convex hull
operations? This would fulfill the requirement for easy access to vertex and
face information as well as allowing hulls of zero size, as in the case where
all points lie in the same plane. If needed, the caller can easily convert the
{{Mesh}} instance into {{ConvexVolume}} or {{RegionBSPTree3D}}.
> Review API in "hull" module
> ---
>
> Key: GEOMETRY-144
> URL: https://issues.apache.org/jira/browse/GEOMETRY-144
> Project: Commons Geometry
> Issue Type: Task
>Reporter: Gilles Sadowski
>Assignee: Gilles Sadowski
>Priority: Minor
> Fix For: 1.1
>
>
> Review codes in the
> [{{commons-geometry-hull}}|https://gitbox.apache.org/repos/asf?p=commons-geometry.git;a=tree;f=commons-geometry-hull;hb=HEAD]
> module.
> (x) Minimize the public API
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GEOMETRY-144) Review API in "hull" module
[
https://issues.apache.org/jira/browse/GEOMETRY-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17682847#comment-17682847
]
Matt Juntunen commented on GEOMETRY-144:
I still believe we should just go with one algorithm and hide all of the
details of the computation. The majority of users will not have any preference
as to which algorithm is used as long as the implementation is accurate and
fast.
{quote}Is there really a need for a {{ConvexHull}} interface as there is right
now in the hull module? As I see it, the interface offers little additional
functionality compared to the {{ConvexArea}} and {{ConvexVolume}} class (keeps
only track of the vertices in three dimensions).
{quote}
I do see utility in having the additional interface, even though it is similar
to {{ConvexVolume}}. The main reasons are
1. it provides direct access to the vertices on the hull, and
2. it supports hulls of zero size, i.e., with all points lying entirely on a
single plane, line, or point.
{{ConvexVolume}} does provide access to vertices but only by iterating through
each face. If you wanted to filter a cloud of points to only those points on
the convex hull using {{ConvexVolume}}, you would have to construct the hull
and then iterate through each face, collecting the vertices and removing
duplicates. This seems unnecessary since the list of used vertices is directly
available from the hull generation. Also, a convex hull does not need to have a
3 dimensional size, which is a requirement of {{ConvexVolume}}. Attempting to
construct a {{ConvexVolume}} of zero size results in an exception.
> Review API in "hull" module
> ---
>
> Key: GEOMETRY-144
> URL: https://issues.apache.org/jira/browse/GEOMETRY-144
> Project: Commons Geometry
> Issue Type: Task
>Reporter: Gilles Sadowski
>Assignee: Gilles Sadowski
>Priority: Minor
> Fix For: 1.1
>
>
> Review codes in the
> [{{commons-geometry-hull}}|https://gitbox.apache.org/repos/asf?p=commons-geometry.git;a=tree;f=commons-geometry-hull;hb=HEAD]
> module.
> (x) Minimize the public API
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CONFIGURATION-817) Upgrade to JUnit 5
[
https://issues.apache.org/jira/browse/CONFIGURATION-817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Juntunen resolved CONFIGURATION-817.
-
Resolution: Done
> Upgrade to JUnit 5
> --
>
> Key: CONFIGURATION-817
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-817
> Project: Commons Configuration
> Issue Type: Task
> Components: Build
>Reporter: Rob Spoor
>Priority: Minor
>
> From https://lists.apache.org/thread/ygtkpch0s7nss4vx8xfytwsbnv7mzss9
> {quote}Matt Juntunen - Monday, 4 July 2022 04:40:43 CEST
> Re: [VOTE] Release Apache Commons Configuration 2.8.0 based on RC3
> Thanks, Bruno and Gary!
> Gary,
> I think the unit tests as a whole could use some upgrading. I'm
> picturing a conversion to JUnit 5, during which we could ensure
> compatibility with the latest JDK versions. I'm not sure what to do
> about the javadoc warnings on the generated classes. From the comments
> in the pom, this seems to have been an issue since v2.4.
> Regards,
> Matt J{quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CONFIGURATION-817) Upgrade to JUnit 5
[
https://issues.apache.org/jira/browse/CONFIGURATION-817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17567643#comment-17567643
]
Matt Juntunen commented on CONFIGURATION-817:
-
Done in commits
- 0809670def4fee8c89fb9110fa5c8e3e0e357c95
- 36ad0945b1f86d04c38fd00582ee3c71759aa16a
- 24901b37011083797d6f946a95f14e9dd09ef1c6
- e5029984051e1d4dac51347bfcb293bd3badfeac
Thanks, [~Spoor]!
> Upgrade to JUnit 5
> --
>
> Key: CONFIGURATION-817
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-817
> Project: Commons Configuration
> Issue Type: Task
> Components: Build
>Reporter: Rob Spoor
>Priority: Minor
>
> From https://lists.apache.org/thread/ygtkpch0s7nss4vx8xfytwsbnv7mzss9
> {quote}Matt Juntunen - Monday, 4 July 2022 04:40:43 CEST
> Re: [VOTE] Release Apache Commons Configuration 2.8.0 based on RC3
> Thanks, Bruno and Gary!
> Gary,
> I think the unit tests as a whole could use some upgrading. I'm
> picturing a conversion to JUnit 5, during which we could ensure
> compatibility with the latest JDK versions. I'm not sure what to do
> about the javadoc warnings on the generated classes. From the comments
> in the pom, this seems to have been an issue since v2.4.
> Regards,
> Matt J{quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CONFIGURATION-817) Upgrade to JUnit 5
[
https://issues.apache.org/jira/browse/CONFIGURATION-817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17565221#comment-17565221
]
Matt Juntunen edited comment on CONFIGURATION-817 at 7/12/22 2:17 AM:
--
bq. How do we feel about using some more advanced JUnit 5 functionality?
IMHO, the examples given do not add to the readability of the tests so my vote
is to leave them as-is.
bq. Is it perhaps an idea to split this ticket into two?
Sounds perfectly reasonable to me. Plus, as you mention, others will be able to
use JUnit 5 sooner rather than later.
was (Author: mattjuntunen):
> How do we feel about using some more advanced JUnit 5 functionality?
IMHO, the examples given do not add to the readability of the tests so my vote
is to leave them as-is.
> Is it perhaps an idea to split this ticket into two?
Sounds perfectly reasonable to me. Plus, as you mention, others will be able to
use JUnit 5 sooner rather than later.
> Upgrade to JUnit 5
> --
>
> Key: CONFIGURATION-817
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-817
> Project: Commons Configuration
> Issue Type: Task
> Components: Build
>Reporter: Rob Spoor
>Priority: Minor
>
> From https://lists.apache.org/thread/ygtkpch0s7nss4vx8xfytwsbnv7mzss9
> {quote}Matt Juntunen - Monday, 4 July 2022 04:40:43 CEST
> Re: [VOTE] Release Apache Commons Configuration 2.8.0 based on RC3
> Thanks, Bruno and Gary!
> Gary,
> I think the unit tests as a whole could use some upgrading. I'm
> picturing a conversion to JUnit 5, during which we could ensure
> compatibility with the latest JDK versions. I'm not sure what to do
> about the javadoc warnings on the generated classes. From the comments
> in the pom, this seems to have been an issue since v2.4.
> Regards,
> Matt J{quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CONFIGURATION-817) Upgrade to JUnit 5
[
https://issues.apache.org/jira/browse/CONFIGURATION-817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17565221#comment-17565221
]
Matt Juntunen commented on CONFIGURATION-817:
-
> How do we feel about using some more advanced JUnit 5 functionality?
IMHO, the examples given do not add to the readability of the tests so my vote
is to leave them as-is.
> Is it perhaps an idea to split this ticket into two?
Sounds perfectly reasonable to me. Plus, as you mention, others will be able to
use JUnit 5 sooner rather than later.
> Upgrade to JUnit 5
> --
>
> Key: CONFIGURATION-817
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-817
> Project: Commons Configuration
> Issue Type: Task
> Components: Build
>Reporter: Rob Spoor
>Priority: Minor
>
> From https://lists.apache.org/thread/ygtkpch0s7nss4vx8xfytwsbnv7mzss9
> {quote}Matt Juntunen - Monday, 4 July 2022 04:40:43 CEST
> Re: [VOTE] Release Apache Commons Configuration 2.8.0 based on RC3
> Thanks, Bruno and Gary!
> Gary,
> I think the unit tests as a whole could use some upgrading. I'm
> picturing a conversion to JUnit 5, during which we could ensure
> compatibility with the latest JDK versions. I'm not sure what to do
> about the javadoc warnings on the generated classes. From the comments
> in the pom, this seems to have been an issue since v2.4.
> Regards,
> Matt J{quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CONFIGURATION-817) Upgrade to JUnit 5
[
https://issues.apache.org/jira/browse/CONFIGURATION-817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17564768#comment-17564768
]
Matt Juntunen commented on CONFIGURATION-817:
-
Wow! I just wished for something out loud on the mailing list and it magically
happened! Thanks, [~Spoor]!
One thing I was picturing during the upgrade was to remove all of the
unnecessary assertion messages. For example, {{ConfigurationAssert}} line 94
contains the line
{code:java}
assertEquals(expEquals, o1.equals(o2), "Wrong result of equals()");
{code}
The custom assertion message in this case feels like extra noise since the
failure could be traced back to this line in the test anyway, and would most
likely need to be in order to fix the issue. What do you think of removing
these superfluous messages? I think a good starting rule of thumb would be to
remove any message that doesn't include a value from the actual test.
> Upgrade to JUnit 5
> --
>
> Key: CONFIGURATION-817
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-817
> Project: Commons Configuration
> Issue Type: Task
> Components: Build
>Reporter: Rob Spoor
>Priority: Minor
>
> From https://lists.apache.org/thread/ygtkpch0s7nss4vx8xfytwsbnv7mzss9
> {quote}Matt Juntunen - Monday, 4 July 2022 04:40:43 CEST
> Re: [VOTE] Release Apache Commons Configuration 2.8.0 based on RC3
> Thanks, Bruno and Gary!
> Gary,
> I think the unit tests as a whole could use some upgrading. I'm
> picturing a conversion to JUnit 5, during which we could ensure
> compatibility with the latest JDK versions. I'm not sure what to do
> about the javadoc warnings on the generated classes. From the comments
> in the pom, this seems to have been an issue since v2.4.
> Regards,
> Matt J{quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (CONFIGURATION-803) java8 lambda improvements
[ https://issues.apache.org/jira/browse/CONFIGURATION-803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Juntunen closed CONFIGURATION-803. --- v2.8.0 released > java8 lambda improvements > -- > > Key: CONFIGURATION-803 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-803 > Project: Commons Configuration > Issue Type: Sub-task >Reporter: Arturo Bernal >Priority: Minor > Fix For: 2.8.0 > > > * Use Anonymous type > * Replace lambda with method reference > * Replace loop with Collection.removeIf() > * Use Single Map -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (CONFIGURATION-801) Remove redundant initializer
[ https://issues.apache.org/jira/browse/CONFIGURATION-801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Juntunen closed CONFIGURATION-801. --- v2.8.0 released > Remove redundant initializer > > > Key: CONFIGURATION-801 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-801 > Project: Commons Configuration > Issue Type: Sub-task >Reporter: Arturo Bernal >Priority: Minor > Fix For: 2.8.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (CONFIGURATION-808) DefaultListDelimiterHandler.escapeList working only for List
[
https://issues.apache.org/jira/browse/CONFIGURATION-808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Juntunen closed CONFIGURATION-808.
---
v2.8.0 released
> DefaultListDelimiterHandler.escapeList working only for List
>
>
> Key: CONFIGURATION-808
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-808
> Project: Commons Configuration
> Issue Type: Bug
>Reporter: Cedomir Igaly
>Priority: Minor
> Fix For: 2.8.0
>
>
> When DefaultListDelimiterHandler.escapeList is invoked with list of anything
> except String, it is throwing exception:
> java.lang.ArrayStoreException: java.lang.Integer at
> org.apache.commons.configuration2.convert.DefaultListDelimiterHandler.escapeList(DefaultListDelimiterHandler.java:110)
>
> Reason: {color:#00}escapedValues{color} is created as String array, but
> assigned to Object array
>
> {color:#0033b3}final {color}{color:#00}Object{color}[]
> {color:#00}escapedValues {color}= {color:#0033b3}new
> {color}String[values.size()];
>
> later Object returned from escape is attempted to store into (String) array:
> {color:#00}escapedValues{color}[idx++] = escape({color:#00}v{color},
> transformer);
>
> Suggested solution is to create escapedValues as Object array:
> {color:#0033b3}final {color}{color:#00}Object{color}[]
> {color:#00}escapedValues {color}= {color:#0033b3}new
> {color}Object[values.size()];
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (CONFIGURATION-804) Redundant local variable
[ https://issues.apache.org/jira/browse/CONFIGURATION-804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Juntunen closed CONFIGURATION-804. --- v2.8.0 released > Redundant local variable > > > Key: CONFIGURATION-804 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-804 > Project: Commons Configuration > Issue Type: Sub-task >Reporter: Arturo Bernal >Priority: Minor > Fix For: 2.8.0 > > > Remove unnecessary local variables, which add nothing to the > comprehensibility of a method. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (CONFIGURATION-813) Support javamail 2.0 in Configuration (package renamed, javax -> jakarta)
[ https://issues.apache.org/jira/browse/CONFIGURATION-813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Juntunen closed CONFIGURATION-813. --- v2.8.0 released > Support javamail 2.0 in Configuration (package renamed, javax -> jakarta) > - > > Key: CONFIGURATION-813 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-813 > Project: Commons Configuration > Issue Type: Bug >Reporter: Bruno P. Kinoshita >Priority: Major > Fix For: 2.8.0 > > > Via dependabot, I will update the PR with a tentative fix. > > https://github.com/apache/commons-configuration/pull/107 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (CONFIGURATION-800) Minor improvements
[ https://issues.apache.org/jira/browse/CONFIGURATION-800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Juntunen closed CONFIGURATION-800. --- v2.8.0 released > Minor improvements > -- > > Key: CONFIGURATION-800 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-800 > Project: Commons Configuration > Issue Type: Bug >Reporter: Arturo Bernal >Priority: Minor > Fix For: 2.8.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (CONFIGURATION-789) Add ImmutableConfiguration.getEnum() methods
[
https://issues.apache.org/jira/browse/CONFIGURATION-789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Juntunen closed CONFIGURATION-789.
---
v2.8.0 released
> Add ImmutableConfiguration.getEnum() methods
>
>
> Key: CONFIGURATION-789
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-789
> Project: Commons Configuration
> Issue Type: New Feature
> Components: Type conversion
>Reporter: Gary D. Gregory
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.8.0
>
>
> Add {{ImmutableConfiguration.getEnum}} methods:
> * org.apache.commons.configuration2.ImmutableConfiguration.getEnum(String,
> Class)
> * org.apache.commons.configuration2.ImmutableConfiguration.getEnum(String,
> Class, T)
> {code:java}
> /**
> * Gets an enum associated with the given configuration key.
> *
> * @param The enum type whose constant is to be returned.
> * @param enumType the \{@code Class} object of the enum type from which to
> return a constant
> * @param key The configuration key.
> * @return The associated enum.
> *
> * @throws org.apache.commons.configuration2.ex.ConversionException is thrown
> if the key maps to an object that
> * is not a String.
> * @since 2.8
> */
> default > T getEnum(String key, Class enumType)
> {code}
> and
> {code:java}
> /**
> * Gets the enum associated with the given configuration key. If the key
> doesn't map to an existing object, the
> * default value is returned.
> *
> * @param The enum type whose constant is to be returned.
> * @param key The configuration key.
> * @param enumType the \{@code Class} object of the enum type from which to
> return a constant
> * @param defaultValue The default value.
> * @return The associated enum if key is found and has valid format, default
> value otherwise.
> *
> * @throws org.apache.commons.configuration2.ex.ConversionException is thrown
> if the key maps to an object that is
> * not a Enum.
> * @since 2.8
> */
> default > T getEnum(String key, Class enumType, T
> defaultValue)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (CONFIGURATION-805) Use try with resource
[ https://issues.apache.org/jira/browse/CONFIGURATION-805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Juntunen closed CONFIGURATION-805. --- v2.8.0 released > Use try with resource > -- > > Key: CONFIGURATION-805 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-805 > Project: Commons Configuration > Issue Type: Sub-task >Reporter: Arturo Bernal >Priority: Major > Fix For: 2.8.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (CONFIGURATION-802) Use final
[ https://issues.apache.org/jira/browse/CONFIGURATION-802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Juntunen closed CONFIGURATION-802. --- v2.8.0 released > Use final > - > > Key: CONFIGURATION-802 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-802 > Project: Commons Configuration > Issue Type: Sub-task >Reporter: Arturo Bernal >Priority: Major > Fix For: 2.8.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (CONFIGURATION-794) Unclosed file handle when reading config from JAR file URL
[ https://issues.apache.org/jira/browse/CONFIGURATION-794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Juntunen closed CONFIGURATION-794. --- v2.8.0 released > Unclosed file handle when reading config from JAR file URL > -- > > Key: CONFIGURATION-794 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-794 > Project: Commons Configuration > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Robin Jansohn >Priority: Major > Fix For: 2.8.0 > > > We read a properties file which is included in a JAR file. Unfortunately we > cannot find any method to close the opened file handle after reading the > properties. > This currently means that the JAR file can only be deleted after the JVM > shuts down. I'll open a PR which shows the behavior. > We currently run our code mostly on Windows systems and Oracle JDK8. > PR: https://github.com/apache/commons-configuration/pull/76 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (CONFIGURATION-790) Update optional com.fasterxml.jackson.core:jackson-databind from 2.10.3 to 2.11.1
[ https://issues.apache.org/jira/browse/CONFIGURATION-790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Juntunen closed CONFIGURATION-790. --- v2.8.0 released > Update optional com.fasterxml.jackson.core:jackson-databind from 2.10.3 to > 2.11.1 > - > > Key: CONFIGURATION-790 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-790 > Project: Commons Configuration > Issue Type: New Feature >Reporter: Gary D. Gregory >Priority: Major > Fix For: 2.8.0 > > > Update optional com.fasterxml.jackson.core:jackson-databind from 2.10.3 to > 2.11.0. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (CONFIGURATION-787) Update from Apache Commons Lang 3.9 to 3.11.
[ https://issues.apache.org/jira/browse/CONFIGURATION-787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Juntunen closed CONFIGURATION-787. --- v2.8.0 released > Update from Apache Commons Lang 3.9 to 3.11. > > > Key: CONFIGURATION-787 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-787 > Project: Commons Configuration > Issue Type: Improvement >Reporter: Gary D. Gregory >Priority: Major > Fix For: 2.8.0 > > > Update from Apache Commons Lang 3.9 to 3.11. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (CONFIGURATION-764) Default date lookup can not work for some specific format
[
https://issues.apache.org/jira/browse/CONFIGURATION-764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Juntunen closed CONFIGURATION-764.
---
v2.8.0 released
> Default date lookup can not work for some specific format
> -
>
> Key: CONFIGURATION-764
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-764
> Project: Commons Configuration
> Issue Type: Bug
> Components: Interpolation
>Affects Versions: 2.6
> Environment: Java 1.8.0_144,
> Windows 10/Linux
>Reporter: Ning Zhang
>Priority: Major
> Fix For: 2.8.0
>
> Attachments: 0001-Fix-default-date-lookup-issue.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When default date lookup is like: *${date:MM}/${date:ddHHmmss}*
> It will encounter one exception like:
> _java.lang.IllegalArgumentException: Illegal pattern character 't'_
> But if change date lookup format to : /*${date:MM}/${date:ddHHmmss}*
> There will be not such issue anymore.
> After investigation, found it is caused by _interpolate_ method in
> _ConfigurationInterpolator.java_.
> For the input date lookup format, it is will be taken as single variable via
> _looksLikeSingleVariable_,
> so default date lookup will try to format the date directly then throw one
> exception.
> Attached patch is trying to catch the exception then return null, substitutor
> will continue to work.
>
> PR: https://github.com/apache/commons-configuration/pull/36
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (CONFIGURATION-753) Handling of interpolation is inconsistent
[
https://issues.apache.org/jira/browse/CONFIGURATION-753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Juntunen closed CONFIGURATION-753.
---
v2.8.0 released
> Handling of interpolation is inconsistent
> -
>
> Key: CONFIGURATION-753
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-753
> Project: Commons Configuration
> Issue Type: Bug
> Components: Interpolation
>Affects Versions: 2.5
> Environment: Java 8, Configurations2 2.5
>Reporter: Peter
>Assignee: Matt Juntunen
>Priority: Major
> Fix For: 2.8.0
>
> Attachments: test.properties
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If a key is repeated in a configuration and then used in an interpolation
> elsewhere, the behaviour is inconsistent. There are other tickets/discussions
> about whether it should just pick the first value or not, but I don't think
> it should do both.
> {code:java|title=/tmp/test.properties}
> abc = hello
> abc = world
> foo.one = ${abc}
> foo.two = prefix ${abc} suffix
> {code}
> {code:java|title=Demo.java (main)}
> Parameters params = new Parameters();
> FileBasedConfigurationBuilder builder = new
> FileBasedConfigurationBuilder(PropertiesConfiguration.class)
> .configure(params.fileBased()
> .setFileName("/tmp/test.properties")
> );
> try {
> FileBasedConfiguration config = builder.getConfiguration();
> System.out.println(config.getString("foo.one"));
> System.out.println(config.getString("foo.two"));
> } catch (ConfigurationException cex) {
> // pass
> }
> {code}
> The output from the above is
> {noformat}
> hello
> prefix [hello, world] suffix
> {noformat}
> In the first case, only the first value is being matched, in the second both
> values (and [, ]) are used.
> I'd expect the output to either be
> {noformat:title=First value only}
> hello
> prefix hello suffix
> {noformat}
> or
> {noformat:title=Both values used}
> [hello, world]
> prefix [hello, world] suffix
> {noformat}
> I can work around whichever style is chosen but think it'd be much more
> intuitive if both cases were handled the same.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CONFIGURATION-813) Support javamail 2.0 in Configuration (package renamed, javax -> jakarta)
[ https://issues.apache.org/jira/browse/CONFIGURATION-813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Juntunen updated CONFIGURATION-813: Fix Version/s: 2.8.0 > Support javamail 2.0 in Configuration (package renamed, javax -> jakarta) > - > > Key: CONFIGURATION-813 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-813 > Project: Commons Configuration > Issue Type: Bug >Reporter: Bruno P. Kinoshita >Priority: Major > Fix For: 2.8.0 > > > Via dependabot, I will update the PR with a tentative fix. > > https://github.com/apache/commons-configuration/pull/107 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (CONFIGURATION-813) Support javamail 2.0 in Configuration (package renamed, javax -> jakarta)
[ https://issues.apache.org/jira/browse/CONFIGURATION-813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Juntunen resolved CONFIGURATION-813. - Resolution: Done > Support javamail 2.0 in Configuration (package renamed, javax -> jakarta) > - > > Key: CONFIGURATION-813 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-813 > Project: Commons Configuration > Issue Type: Bug >Reporter: Bruno P. Kinoshita >Priority: Major > > Via dependabot, I will update the PR with a tentative fix. > > https://github.com/apache/commons-configuration/pull/107 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (CONFIGURATION-813) Support javamail 2.0 in Configuration (package renamed, javax -> jakarta)
[ https://issues.apache.org/jira/browse/CONFIGURATION-813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17553863#comment-17553863 ] Matt Juntunen commented on CONFIGURATION-813: - Added in commit 079cf7176989fb91d622a6a06f1fb7023cb79a25. > Support javamail 2.0 in Configuration (package renamed, javax -> jakarta) > - > > Key: CONFIGURATION-813 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-813 > Project: Commons Configuration > Issue Type: Bug >Reporter: Bruno P. Kinoshita >Priority: Major > > Via dependabot, I will update the PR with a tentative fix. > > https://github.com/apache/commons-configuration/pull/107 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (CONFIGURATION-813) Support javamail 2.0 in Configuration (package renamed, javax -> jakarta)
[ https://issues.apache.org/jira/browse/CONFIGURATION-813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17553858#comment-17553858 ] Matt Juntunen commented on CONFIGURATION-813: - After the discussion on the mailing list [here|https://lists.apache.org/thread/xpp1vf7q5dj2v0z9dyjj87nvhbgj1xox], we have decided to move back to the set of changes from the original PR (#107). This includes support for both the javax.* and the jakarta* mailapi namespaces since making the change would require some users to update their code, thereby breaking "implicit" binary compatibility. The new PR (with the changes rebased on master) is https://github.com/apache/commons-configuration/pull/186. > Support javamail 2.0 in Configuration (package renamed, javax -> jakarta) > - > > Key: CONFIGURATION-813 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-813 > Project: Commons Configuration > Issue Type: Bug >Reporter: Bruno P. Kinoshita >Priority: Major > > Via dependabot, I will update the PR with a tentative fix. > > https://github.com/apache/commons-configuration/pull/107 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (CONFIGURATION-813) Support javamail 2.0 in Configuration (package renamed, javax -> jakarta)
[ https://issues.apache.org/jira/browse/CONFIGURATION-813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17552490#comment-17552490 ] Matt Juntunen commented on CONFIGURATION-813: - I've replaced the PR above with this one: https://github.com/apache/commons-configuration/pull/185 > Support javamail 2.0 in Configuration (package renamed, javax -> jakarta) > - > > Key: CONFIGURATION-813 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-813 > Project: Commons Configuration > Issue Type: Bug >Reporter: Bruno P. Kinoshita >Priority: Major > > Via dependabot, I will update the PR with a tentative fix. > > https://github.com/apache/commons-configuration/pull/107 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (CONFIGURATION-753) Handling of interpolation is inconsistent
[
https://issues.apache.org/jira/browse/CONFIGURATION-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17539898#comment-17539898
]
Matt Juntunen commented on CONFIGURATION-753:
-
Done in commit 454fa0ce34fee5f182e8dcd83af77947d5dfddaa
> Handling of interpolation is inconsistent
> -
>
> Key: CONFIGURATION-753
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-753
> Project: Commons Configuration
> Issue Type: Bug
> Components: Interpolation
>Affects Versions: 2.5
> Environment: Java 8, Configurations2 2.5
>Reporter: Peter
>Assignee: Matt Juntunen
>Priority: Major
> Fix For: 2.8.0
>
> Attachments: test.properties
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If a key is repeated in a configuration and then used in an interpolation
> elsewhere, the behaviour is inconsistent. There are other tickets/discussions
> about whether it should just pick the first value or not, but I don't think
> it should do both.
> {code:java|title=/tmp/test.properties}
> abc = hello
> abc = world
> foo.one = ${abc}
> foo.two = prefix ${abc} suffix
> {code}
> {code:java|title=Demo.java (main)}
> Parameters params = new Parameters();
> FileBasedConfigurationBuilder builder = new
> FileBasedConfigurationBuilder(PropertiesConfiguration.class)
> .configure(params.fileBased()
> .setFileName("/tmp/test.properties")
> );
> try {
> FileBasedConfiguration config = builder.getConfiguration();
> System.out.println(config.getString("foo.one"));
> System.out.println(config.getString("foo.two"));
> } catch (ConfigurationException cex) {
> // pass
> }
> {code}
> The output from the above is
> {noformat}
> hello
> prefix [hello, world] suffix
> {noformat}
> In the first case, only the first value is being matched, in the second both
> values (and [, ]) are used.
> I'd expect the output to either be
> {noformat:title=First value only}
> hello
> prefix hello suffix
> {noformat}
> or
> {noformat:title=Both values used}
> [hello, world]
> prefix [hello, world] suffix
> {noformat}
> I can work around whichever style is chosen but think it'd be much more
> intuitive if both cases were handled the same.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (CONFIGURATION-753) Handling of interpolation is inconsistent
[
https://issues.apache.org/jira/browse/CONFIGURATION-753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Juntunen resolved CONFIGURATION-753.
-
Resolution: Fixed
> Handling of interpolation is inconsistent
> -
>
> Key: CONFIGURATION-753
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-753
> Project: Commons Configuration
> Issue Type: Bug
> Components: Interpolation
>Affects Versions: 2.5
> Environment: Java 8, Configurations2 2.5
>Reporter: Peter
>Assignee: Matt Juntunen
>Priority: Major
> Fix For: 2.8.0
>
> Attachments: test.properties
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If a key is repeated in a configuration and then used in an interpolation
> elsewhere, the behaviour is inconsistent. There are other tickets/discussions
> about whether it should just pick the first value or not, but I don't think
> it should do both.
> {code:java|title=/tmp/test.properties}
> abc = hello
> abc = world
> foo.one = ${abc}
> foo.two = prefix ${abc} suffix
> {code}
> {code:java|title=Demo.java (main)}
> Parameters params = new Parameters();
> FileBasedConfigurationBuilder builder = new
> FileBasedConfigurationBuilder(PropertiesConfiguration.class)
> .configure(params.fileBased()
> .setFileName("/tmp/test.properties")
> );
> try {
> FileBasedConfiguration config = builder.getConfiguration();
> System.out.println(config.getString("foo.one"));
> System.out.println(config.getString("foo.two"));
> } catch (ConfigurationException cex) {
> // pass
> }
> {code}
> The output from the above is
> {noformat}
> hello
> prefix [hello, world] suffix
> {noformat}
> In the first case, only the first value is being matched, in the second both
> values (and [, ]) are used.
> I'd expect the output to either be
> {noformat:title=First value only}
> hello
> prefix hello suffix
> {noformat}
> or
> {noformat:title=Both values used}
> [hello, world]
> prefix [hello, world] suffix
> {noformat}
> I can work around whichever style is chosen but think it'd be much more
> intuitive if both cases were handled the same.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (CONFIGURATION-753) Handling of interpolation is inconsistent
[
https://issues.apache.org/jira/browse/CONFIGURATION-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17539897#comment-17539897
]
Matt Juntunen commented on CONFIGURATION-753:
-
No problem! I'm hoping to have the next version out soon.
> Handling of interpolation is inconsistent
> -
>
> Key: CONFIGURATION-753
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-753
> Project: Commons Configuration
> Issue Type: Bug
> Components: Interpolation
>Affects Versions: 2.5
> Environment: Java 8, Configurations2 2.5
>Reporter: Peter
>Assignee: Matt Juntunen
>Priority: Major
> Fix For: 2.8.0
>
> Attachments: test.properties
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If a key is repeated in a configuration and then used in an interpolation
> elsewhere, the behaviour is inconsistent. There are other tickets/discussions
> about whether it should just pick the first value or not, but I don't think
> it should do both.
> {code:java|title=/tmp/test.properties}
> abc = hello
> abc = world
> foo.one = ${abc}
> foo.two = prefix ${abc} suffix
> {code}
> {code:java|title=Demo.java (main)}
> Parameters params = new Parameters();
> FileBasedConfigurationBuilder builder = new
> FileBasedConfigurationBuilder(PropertiesConfiguration.class)
> .configure(params.fileBased()
> .setFileName("/tmp/test.properties")
> );
> try {
> FileBasedConfiguration config = builder.getConfiguration();
> System.out.println(config.getString("foo.one"));
> System.out.println(config.getString("foo.two"));
> } catch (ConfigurationException cex) {
> // pass
> }
> {code}
> The output from the above is
> {noformat}
> hello
> prefix [hello, world] suffix
> {noformat}
> In the first case, only the first value is being matched, in the second both
> values (and [, ]) are used.
> I'd expect the output to either be
> {noformat:title=First value only}
> hello
> prefix hello suffix
> {noformat}
> or
> {noformat:title=Both values used}
> [hello, world]
> prefix [hello, world] suffix
> {noformat}
> I can work around whichever style is chosen but think it'd be much more
> intuitive if both cases were handled the same.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (CONFIGURATION-764) Default date lookup can not work for some specific format
[
https://issues.apache.org/jira/browse/CONFIGURATION-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17537247#comment-17537247
]
Matt Juntunen commented on CONFIGURATION-764:
-
I've submitted a new PR
(https://github.com/apache/commons-configuration/pull/182) that changes the
logic in {{looksLikeSingleVariable}} to better detect inputs like this. This
approach requires fewer changes and does not suppress any exceptions. Let me
know what you think.
> Default date lookup can not work for some specific format
> -
>
> Key: CONFIGURATION-764
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-764
> Project: Commons Configuration
> Issue Type: Bug
> Components: Interpolation
>Affects Versions: 2.6
> Environment: Java 1.8.0_144,
> Windows 10/Linux
>Reporter: Ning Zhang
>Priority: Major
> Attachments: 0001-Fix-default-date-lookup-issue.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When default date lookup is like: *${date:MM}/${date:ddHHmmss}*
> It will encounter one exception like:
> _java.lang.IllegalArgumentException: Illegal pattern character 't'_
> But if change date lookup format to : /*${date:MM}/${date:ddHHmmss}*
> There will be not such issue anymore.
> After investigation, found it is caused by _interpolate_ method in
> _ConfigurationInterpolator.java_.
> For the input date lookup format, it is will be taken as single variable via
> _looksLikeSingleVariable_,
> so default date lookup will try to format the date directly then throw one
> exception.
> Attached patch is trying to catch the exception then return null, substitutor
> will continue to work.
>
> PR: https://github.com/apache/commons-configuration/pull/36
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (CONFIGURATION-753) Handling of interpolation is inconsistent
[
https://issues.apache.org/jira/browse/CONFIGURATION-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17537236#comment-17537236
]
Matt Juntunen commented on CONFIGURATION-753:
-
I've added a new PR (https://github.com/apache/commons-configuration/pull/181)
with an expanded version of [~tpoliaw]'s changes. The basic idea is to expose
the string conversion logic of {{ConfigurationInterpolator}} as a configurable
property, with a default that closely resembles the logic in
{{DefaultConversionHandler}}. This makes the interpolation behavior consistent
while also allowing users to customize it on their own if this does not meet
their needs.
Thoughts?
> Handling of interpolation is inconsistent
> -
>
> Key: CONFIGURATION-753
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-753
> Project: Commons Configuration
> Issue Type: Bug
> Components: Interpolation
>Affects Versions: 2.5
> Environment: Java 8, Configurations2 2.5
>Reporter: Peter
>Priority: Major
> Attachments: test.properties
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If a key is repeated in a configuration and then used in an interpolation
> elsewhere, the behaviour is inconsistent. There are other tickets/discussions
> about whether it should just pick the first value or not, but I don't think
> it should do both.
> {code:java|title=/tmp/test.properties}
> abc = hello
> abc = world
> foo.one = ${abc}
> foo.two = prefix ${abc} suffix
> {code}
> {code:java|title=Demo.java (main)}
> Parameters params = new Parameters();
> FileBasedConfigurationBuilder builder = new
> FileBasedConfigurationBuilder(PropertiesConfiguration.class)
> .configure(params.fileBased()
> .setFileName("/tmp/test.properties")
> );
> try {
> FileBasedConfiguration config = builder.getConfiguration();
> System.out.println(config.getString("foo.one"));
> System.out.println(config.getString("foo.two"));
> } catch (ConfigurationException cex) {
> // pass
> }
> {code}
> The output from the above is
> {noformat}
> hello
> prefix [hello, world] suffix
> {noformat}
> In the first case, only the first value is being matched, in the second both
> values (and [, ]) are used.
> I'd expect the output to either be
> {noformat:title=First value only}
> hello
> prefix hello suffix
> {noformat}
> or
> {noformat:title=Both values used}
> [hello, world]
> prefix [hello, world] suffix
> {noformat}
> I can work around whichever style is chosen but think it'd be much more
> intuitive if both cases were handled the same.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (CONFIGURATION-753) Handling of interpolation is inconsistent
[
https://issues.apache.org/jira/browse/CONFIGURATION-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17534850#comment-17534850
]
Matt Juntunen commented on CONFIGURATION-753:
-
Coming in late to this discussion...
The main cause of the inconsistency here seems to be the interaction between
{{DefaultConversionHandler}} and {{ConfigurationInterpolator}}. In the case
where the property value consists of only a variable reference, the
{{ConfigurationInterpolator}} returns the actual collection object instead of a
string. {{DefaultConversionHandler}} then attempts to convert the "complex"
object to a string and chooses the first entry from the collection. However, if
the property value contains more than just the variable reference, then
{{ConfigurationInterpolator}} uses {{StringSubstitutor}} to construct the final
string. {{StringSubstitutor}} does not contain the complex string conversion
logic that {{DefaultConversionHandler}} has and simply uses
{{Objects.toString()}}, producing the inconsistency noted in this ticket.
Here are my thoughts on how to address this:
1. Rework the API so that {{ConfigurationInterpolator}} can call back into a
{{ConversionHandler}} to convert values to strings. This would produce the most
consistent results overall and would prevent us from having similar conversion
logic in both classes.
2. Do nothing. We can document the fact that single variable interpolation can
return different values than interpolation with variables and non-variables. I
believe this is internally consistent behavior even though it may not be the
expected behavior at times.
I plan on looking into the first option more. Thoughts?
> Handling of interpolation is inconsistent
> -
>
> Key: CONFIGURATION-753
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-753
> Project: Commons Configuration
> Issue Type: Bug
> Components: Interpolation
>Affects Versions: 2.5
> Environment: Java 8, Configurations2 2.5
>Reporter: Peter
>Priority: Major
> Attachments: test.properties
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If a key is repeated in a configuration and then used in an interpolation
> elsewhere, the behaviour is inconsistent. There are other tickets/discussions
> about whether it should just pick the first value or not, but I don't think
> it should do both.
> {code:java|title=/tmp/test.properties}
> abc = hello
> abc = world
> foo.one = ${abc}
> foo.two = prefix ${abc} suffix
> {code}
> {code:java|title=Demo.java (main)}
> Parameters params = new Parameters();
> FileBasedConfigurationBuilder builder = new
> FileBasedConfigurationBuilder(PropertiesConfiguration.class)
> .configure(params.fileBased()
> .setFileName("/tmp/test.properties")
> );
> try {
> FileBasedConfiguration config = builder.getConfiguration();
> System.out.println(config.getString("foo.one"));
> System.out.println(config.getString("foo.two"));
> } catch (ConfigurationException cex) {
> // pass
> }
> {code}
> The output from the above is
> {noformat}
> hello
> prefix [hello, world] suffix
> {noformat}
> In the first case, only the first value is being matched, in the second both
> values (and [, ]) are used.
> I'd expect the output to either be
> {noformat:title=First value only}
> hello
> prefix hello suffix
> {noformat}
> or
> {noformat:title=Both values used}
> [hello, world]
> prefix [hello, world] suffix
> {noformat}
> I can work around whichever style is chosen but think it'd be much more
> intuitive if both cases were handled the same.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (CONFIGURATION-810) Refactor DummyLayout in TestPropertiesConfiguration to improve test design
[
https://issues.apache.org/jira/browse/CONFIGURATION-810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Juntunen resolved CONFIGURATION-810.
-
Resolution: Won't Fix
> Refactor DummyLayout in TestPropertiesConfiguration to improve test design
> --
>
> Key: CONFIGURATION-810
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-810
> Project: Commons Configuration
> Issue Type: Improvement
>Reporter: Xiao Wang
>Priority: Minor
>
> h3. Description
> I noticed that there is a test class
> [DummyLayout|https://github.com/apache/commons-configuration/blob/66b4f4eb73b276d041debaad80af3074ccb359bd/src/test/java/org/apache/commons/configuration2/TestPropertiesConfiguration.java#L91]
> implements production class
> [PropertiesConfigurationLayout|https://github.com/apache/commons-configuration/blob/66b4f4eb73b276d041debaad80af3074ccb359bd/src/main/java/org/apache/commons/configuration2/PropertiesConfigurationLayout.java#L102]
> to assist testing method [PropertiesConfiguration.propertyLoaded(String,
> String,
> Deque)|https://github.com/apache/commons-configuration/blob/66b4f4eb73b276d041debaad80af3074ccb359bd/src/main/java/org/apache/commons/configuration2/PropertiesConfiguration.java#L1467].
> This might not be the best priactice in unit testing and can be improved by
> leveraging mocking frameworks.
> h3. Current Implementation
> * {{DummyLayout}} extends {{PropertiesConfigurationLayout}} and creates a
> new variable to keep tracking of the method invocation status for
> {{load(PropertiesConfiguration, Reader)}}.
> * In test cases, after executing
> {{PropertiesConfiguration.propertyLoaded(String, String, Deque)}}, the
> new variable will be used in assertion statement to check the execution
> status of {{load(PropertiesConfiguration, Reader)}}.
> h3. Proposed Implementation
> * Replace {{DummyLayout}} with a mocking object created by Mockito.
> * Remove the {{int}} variable that used to keep tracking the invocation
> times of {{load(PropertiesConfiguration, Reader)}}.
> * Use {{Mockito.verify()}} to check execution status of
> {{load(PropertiesConfiguration, Reader)}}.
> h3. Motivation
> * Decouple test class {{DummyLayout}} from production class
> {{PropertiesConfigurationLayout}}.
> * Make test logic more clear by removing the overridden method in
> {{DummyLayout}}.
> * Make test condition more explict by directly using {{Mockito.verify()}} to
> verify method execution status.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (CONFIGURATION-810) Refactor DummyLayout in TestPropertiesConfiguration to improve test design
[
https://issues.apache.org/jira/browse/CONFIGURATION-810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17532005#comment-17532005
]
Matt Juntunen commented on CONFIGURATION-810:
-
Thank you for your PR! Your rationale is good and your issue description is
very clearly structured. However, I don't believe this change is necessary for
the following reasons:
1. It adds a new dependency on mockito when, for better or worse, the project
already has a dependency on [easymock|https://easymock.org/]. Having two
mocking frameworks in the same project will be confusing.
2. I typically avoid mocking or otherwise modifying the actual object under
test because it is not obvious how the mocking framework is modifying or
extending the object. With {{DummyLayout}}, the modification is clear: the
class under test is being extended, a single method is overridden, and all
other behavior is the same. Note that I'm not saying that mockito isn't doing
this internally; I'm saying that this fact is not clear from just looking at
the test.
3. The use case for {{DummyLayout}} is very simple and not much longer than the
mocked version.
> Refactor DummyLayout in TestPropertiesConfiguration to improve test design
> --
>
> Key: CONFIGURATION-810
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-810
> Project: Commons Configuration
> Issue Type: Improvement
>Reporter: Xiao Wang
>Priority: Minor
>
> h3. Description
> I noticed that there is a test class
> [DummyLayout|https://github.com/apache/commons-configuration/blob/66b4f4eb73b276d041debaad80af3074ccb359bd/src/test/java/org/apache/commons/configuration2/TestPropertiesConfiguration.java#L91]
> implements production class
> [PropertiesConfigurationLayout|https://github.com/apache/commons-configuration/blob/66b4f4eb73b276d041debaad80af3074ccb359bd/src/main/java/org/apache/commons/configuration2/PropertiesConfigurationLayout.java#L102]
> to assist testing method [PropertiesConfiguration.propertyLoaded(String,
> String,
> Deque)|https://github.com/apache/commons-configuration/blob/66b4f4eb73b276d041debaad80af3074ccb359bd/src/main/java/org/apache/commons/configuration2/PropertiesConfiguration.java#L1467].
> This might not be the best priactice in unit testing and can be improved by
> leveraging mocking frameworks.
> h3. Current Implementation
> * {{DummyLayout}} extends {{PropertiesConfigurationLayout}} and creates a
> new variable to keep tracking of the method invocation status for
> {{load(PropertiesConfiguration, Reader)}}.
> * In test cases, after executing
> {{PropertiesConfiguration.propertyLoaded(String, String, Deque)}}, the
> new variable will be used in assertion statement to check the execution
> status of {{load(PropertiesConfiguration, Reader)}}.
> h3. Proposed Implementation
> * Replace {{DummyLayout}} with a mocking object created by Mockito.
> * Remove the {{int}} variable that used to keep tracking the invocation
> times of {{load(PropertiesConfiguration, Reader)}}.
> * Use {{Mockito.verify()}} to check execution status of
> {{load(PropertiesConfiguration, Reader)}}.
> h3. Motivation
> * Decouple test class {{DummyLayout}} from production class
> {{PropertiesConfigurationLayout}}.
> * Make test logic more clear by removing the overridden method in
> {{DummyLayout}}.
> * Make test condition more explict by directly using {{Mockito.verify()}} to
> verify method execution status.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEOMETRY-147) BoundsXD Linecastable
[
https://issues.apache.org/jira/browse/GEOMETRY-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Juntunen resolved GEOMETRY-147.
Resolution: Done
> BoundsXD Linecastable
> -
>
> Key: GEOMETRY-147
> URL: https://issues.apache.org/jira/browse/GEOMETRY-147
> Project: Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Fix For: 1.1
>
>
> Make the {{Bounds2D}} and {{Bounds3D}} classes implement {{Linecastable}}.
> Use the
> ["slabs"|https://education.siggraph.org/static/HyperGraph/raytrace/rtinter3.htm]
> algorithm to determine intersection points.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEOMETRY-147) BoundsXD Linecastable
[
https://issues.apache.org/jira/browse/GEOMETRY-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17531473#comment-17531473
]
Matt Juntunen commented on GEOMETRY-147:
Merged in commit 27b8d65ad6900af39b6036d8a00dcd8d448c99ee
> BoundsXD Linecastable
> -
>
> Key: GEOMETRY-147
> URL: https://issues.apache.org/jira/browse/GEOMETRY-147
> Project: Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Fix For: 1.1
>
>
> Make the {{Bounds2D}} and {{Bounds3D}} classes implement {{Linecastable}}.
> Use the
> ["slabs"|https://education.siggraph.org/static/HyperGraph/raytrace/rtinter3.htm]
> algorithm to determine intersection points.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEOMETRY-144) Review API in "hull" module
[
https://issues.apache.org/jira/browse/GEOMETRY-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17530519#comment-17530519
]
Matt Juntunen commented on GEOMETRY-144:
I'm thinking it would be useful to apply the builder pattern for convex hull
construction. The current API in {{commons-geometry-hull}} only accepts a
collection of points, which means that if callers do not have such a collection
readily available, they must allocate memory for the collection, extract points
from whatever data structure they are part of, and _then_ pass it to the convex
hull algorithm. If we use the builder pattern, we can avoid this allocation
overhead. For example,
{code:java}
// previous API
RegionBSPTree3D tree = ...
List pts = new ArrayList<>();
tree.boundaryStream(b -> pts.addAll(pts.getVertices()); // pts could become
quite large here
ConvexHull3D hull = ... // create from pts
// builder API
RegionBSPTree3D tree = ...
ConvexHull3D.Builder hullBuilder = ConvexHull3D.builder(precision);
tree.boundaryStream(b -> hullBuilder.addAll(b.getVertices()));
ConvexHull3D hull = hullBuilder.build();
{code}
It may also be possible for us completely ignore particular points (and not
even store them within the builder) if the point can be immediately determined
to not lie on the hull.
> Review API in "hull" module
> ---
>
> Key: GEOMETRY-144
> URL: https://issues.apache.org/jira/browse/GEOMETRY-144
> Project: Commons Geometry
> Issue Type: Task
>Reporter: Gilles Sadowski
>Assignee: Gilles Sadowski
>Priority: Minor
> Fix For: 1.1
>
>
> Review codes in the
> [{{commons-geometry-hull}}|https://gitbox.apache.org/repos/asf?p=commons-geometry.git;a=tree;f=commons-geometry-hull;hb=HEAD]
> module.
> (x) Minimize the public API
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (GEOMETRY-146) PointSet/Map closest points
[
https://issues.apache.org/jira/browse/GEOMETRY-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Juntunen reassigned GEOMETRY-146:
--
Assignee: Matt Juntunen
> PointSet/Map closest points
> ---
>
> Key: GEOMETRY-146
> URL: https://issues.apache.org/jira/browse/GEOMETRY-146
> Project: Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Assignee: Matt Juntunen
>Priority: Major
> Fix For: 1.1
>
>
> Add methods to the new {{PointSet}} and {{PointMap}} interfaces to allow
> querying of points in order of distance from a query point.
> {code:java}
> PointSet {
> // find the closest point to pt or null if empty
> P closest(P pt);
> // iterate through points in order, with points closest to pt coming first
> Iterable closestFirst(P pt);
> // find the farthest point from pt or null if emtpy
> P farthest(P pt);
> // iterate through point in order, with points farthest from pt coming
> first
> Iterable farthestFirst(P pt);
> }
> {code}
> {{PointMap}} should have similar methods providing access to the map keys and
> entries.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEOMETRY-146) PointSet/Map closest points
[
https://issues.apache.org/jira/browse/GEOMETRY-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Juntunen resolved GEOMETRY-146.
Resolution: Done
> PointSet/Map closest points
> ---
>
> Key: GEOMETRY-146
> URL: https://issues.apache.org/jira/browse/GEOMETRY-146
> Project: Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Fix For: 1.1
>
>
> Add methods to the new {{PointSet}} and {{PointMap}} interfaces to allow
> querying of points in order of distance from a query point.
> {code:java}
> PointSet {
> // find the closest point to pt or null if empty
> P closest(P pt);
> // iterate through points in order, with points closest to pt coming first
> Iterable closestFirst(P pt);
> // find the farthest point from pt or null if emtpy
> P farthest(P pt);
> // iterate through point in order, with points farthest from pt coming
> first
> Iterable farthestFirst(P pt);
> }
> {code}
> {{PointMap}} should have similar methods providing access to the map keys and
> entries.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEOMETRY-146) PointSet/Map closest points
[
https://issues.apache.org/jira/browse/GEOMETRY-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17530318#comment-17530318
]
Matt Juntunen commented on GEOMETRY-146:
Merged in ffc9ff964654948aab93438dff8b8a2bbdab03d7
> PointSet/Map closest points
> ---
>
> Key: GEOMETRY-146
> URL: https://issues.apache.org/jira/browse/GEOMETRY-146
> Project: Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Fix For: 1.1
>
>
> Add methods to the new {{PointSet}} and {{PointMap}} interfaces to allow
> querying of points in order of distance from a query point.
> {code:java}
> PointSet {
> // find the closest point to pt or null if empty
> P closest(P pt);
> // iterate through points in order, with points closest to pt coming first
> Iterable closestFirst(P pt);
> // find the farthest point from pt or null if emtpy
> P farthest(P pt);
> // iterate through point in order, with points farthest from pt coming
> first
> Iterable farthestFirst(P pt);
> }
> {code}
> {{PointMap}} should have similar methods providing access to the map keys and
> entries.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEOMETRY-147) BoundsXD Linecastable
[
https://issues.apache.org/jira/browse/GEOMETRY-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17530317#comment-17530317
]
Matt Juntunen commented on GEOMETRY-147:
PR is in: https://github.com/apache/commons-geometry/pull/196
> BoundsXD Linecastable
> -
>
> Key: GEOMETRY-147
> URL: https://issues.apache.org/jira/browse/GEOMETRY-147
> Project: Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Fix For: 1.1
>
>
> Make the {{Bounds2D}} and {{Bounds3D}} classes implement {{Linecastable}}.
> Use the
> ["slabs"|https://education.siggraph.org/static/HyperGraph/raytrace/rtinter3.htm]
> algorithm to determine intersection points.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEOMETRY-146) PointSet/Map closest points
[
https://issues.apache.org/jira/browse/GEOMETRY-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529908#comment-17529908
]
Matt Juntunen commented on GEOMETRY-146:
I'm planning on merging the above PR either today or tomorrow unless there are
any objections.
> PointSet/Map closest points
> ---
>
> Key: GEOMETRY-146
> URL: https://issues.apache.org/jira/browse/GEOMETRY-146
> Project: Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Fix For: 1.1
>
>
> Add methods to the new {{PointSet}} and {{PointMap}} interfaces to allow
> querying of points in order of distance from a query point.
> {code:java}
> PointSet {
> // find the closest point to pt or null if empty
> P closest(P pt);
> // iterate through points in order, with points closest to pt coming first
> Iterable closestFirst(P pt);
> // find the farthest point from pt or null if emtpy
> P farthest(P pt);
> // iterate through point in order, with points farthest from pt coming
> first
> Iterable farthestFirst(P pt);
> }
> {code}
> {{PointMap}} should have similar methods providing access to the map keys and
> entries.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEOMETRY-144) Review API in "hull" module
[
https://issues.apache.org/jira/browse/GEOMETRY-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17527276#comment-17527276
]
Matt Juntunen commented on GEOMETRY-144:
Having thought on this some more, I believe the best way to go here would be to
just implement a single algorithm and hide the details from the user, similar
to how the JDK's {{Arrays.sort}} uses TimSort internally. If this ends up being
insufficient, then we could add additional algorithms through an enum for use
in special cases, while still retaining the API for the general-purpose use
case. This seems cleaner to me than adding several algorithm options at first
and then trying to revert to a single-algorithm API if there are not any
compelling use cases for the different algorithms (which I suspect will end up
being the case).
> Review API in "hull" module
> ---
>
> Key: GEOMETRY-144
> URL: https://issues.apache.org/jira/browse/GEOMETRY-144
> Project: Commons Geometry
> Issue Type: Task
>Reporter: Gilles Sadowski
>Assignee: Gilles Sadowski
>Priority: Minor
> Fix For: 1.1
>
>
> Review codes in the
> [{{commons-geometry-hull}}|https://gitbox.apache.org/repos/asf?p=commons-geometry.git;a=tree;f=commons-geometry-hull;hb=HEAD]
> module.
> (x) Minimize the public API
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEOMETRY-144) Review API in "hull" module
[
https://issues.apache.org/jira/browse/GEOMETRY-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17527270#comment-17527270
]
Matt Juntunen commented on GEOMETRY-144:
{quote}Could different algorithms have their respective advantages and
inconveniences? If so, shouldn't we provide access to all (e.g. through an
enum)?
{quote}
There could be advantages to having multiple algorithms available. The
performance of some algorithms varies with the characteristics of the inputs,
so users could possibly choose the algorithm best suited for their situation.
For example, the [Graham scan|https://en.wikipedia.org/wiki/Graham_scan]
algorithm has an overall time complexity of O(n log n) but can run in O(n ) on
presorted points.
On the other hand, the single-algorithm approach is simple and would not
require users to learn the ins and outs of convex hull computation. Plus, if
optimizations are discovered, they could be passed on transparently to the user
without them needing to update their code (to select a different algorithm, for
example).
I'm unsure which approach is best here.
{quote}
Also, why keep those algorithms in a separate maven module, rather than include
them in module commons-geometry-euclidean (in packages
o.a.c.geometry.euclidean.twod and o.a.c.geometry.euclidean.threed,
respectively).
{quote}
This is the structure inherited from {{commons-math}}. If we go with a simple,
one algorithm approach, I could easily picture it going into
{{commons-geometry-euclidean}}. If we end up implementing multiple algorithms,
then I think a separate module would be best, in order to avoid cluttering the
euclidean module.
> Review API in "hull" module
> ---
>
> Key: GEOMETRY-144
> URL: https://issues.apache.org/jira/browse/GEOMETRY-144
> Project: Commons Geometry
> Issue Type: Task
>Reporter: Gilles Sadowski
>Assignee: Gilles Sadowski
>Priority: Minor
> Fix For: 1.1
>
>
> Review codes in the
> [{{commons-geometry-hull}}|https://gitbox.apache.org/repos/asf?p=commons-geometry.git;a=tree;f=commons-geometry-hull;hb=HEAD]
> module.
> (x) Minimize the public API
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEOMETRY-146) PointSet/Map closest points
[
https://issues.apache.org/jira/browse/GEOMETRY-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17527268#comment-17527268
]
Matt Juntunen commented on GEOMETRY-146:
{{neighborEntriesFullBaseline}} was a baseline comparison method that simply
iterated through the _entire_ map and pulled out the ones that were within the
max distance. It was basically like this:
{code:java}
Vector3D refPt = ...
double maxDist = ...
List> neighbors = new ArrayList<>();
for (Entry entry : map.entrySet()) {
if (entry.getKey().distance(refPt) <= maxDist) {
neighbors.add(entry);
}
}
{code}
No optimizations or anything. I was completely dumbfounded that this was faster
than anything else but I was unable to see anything wrong with the tests. The
tests above are with maps with about ~8000 entries. The main culprit I could
see was the use of streams vs raw iterators. For example, {{neighborEntries}}
and {{neighborEntriesFullStreamBaseline}} use streams.
> PointSet/Map closest points
> ---
>
> Key: GEOMETRY-146
> URL: https://issues.apache.org/jira/browse/GEOMETRY-146
> Project: Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Fix For: 1.1
>
>
> Add methods to the new {{PointSet}} and {{PointMap}} interfaces to allow
> querying of points in order of distance from a query point.
> {code:java}
> PointSet {
> // find the closest point to pt or null if empty
> P closest(P pt);
> // iterate through points in order, with points closest to pt coming first
> Iterable closestFirst(P pt);
> // find the farthest point from pt or null if emtpy
> P farthest(P pt);
> // iterate through point in order, with points farthest from pt coming
> first
> Iterable farthestFirst(P pt);
> }
> {code}
> {{PointMap}} should have similar methods providing access to the map keys and
> entries.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (GEOMETRY-144) Review API in "hull" module
[
https://issues.apache.org/jira/browse/GEOMETRY-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17526836#comment-17526836
]
Matt Juntunen edited comment on GEOMETRY-144 at 4/23/22 11:57 AM:
--
The current implementation uses an algorithm-specific design. For example,
there is a public class named {{MonotoneChain}} that implements the "monotone
chain" 2D convex hull algorithm. I'm wondering if we should abandon this in
favor of providing just a single well-rounded algorithm option. For example,
the API could simply be
{code:java}
public final class ConvexHulls {
public static ConvexHull2D create2D(Collection pts) {
// ...
}
public static ConvexHull3D create3D(Collection pts) {
// ...
}
}
{code}
This relieves users of the need to be knowledgeable about convex hull
algorithms and gives us the flexibility to swap out the algorithm later on if
needed.
was (Author: mattjuntunen):
The current implementation uses an algorithm-specific design. For example,
there is a public class named {{MonotoneChain}} that implements the "monotone
chain" 2D convex hull algorithm. I'm wondering if we should abandon this in
favor of providing just a single well-rounded algorithm option. For example,
the API could simply be
{code:java}
public final class ConvexHulls {
public static ConvexHull2D create2D(Collection pts) {
// ...
}
public static ConvexHull2D create3D(Collection pts) {
// ...
}
}
{code}
This relieves users of the need to be knowledgeable about convex hull
algorithms and gives us the flexibility to swap out the algorithm later on if
needed.
> Review API in "hull" module
> ---
>
> Key: GEOMETRY-144
> URL: https://issues.apache.org/jira/browse/GEOMETRY-144
> Project: Commons Geometry
> Issue Type: Task
>Reporter: Gilles Sadowski
>Assignee: Gilles Sadowski
>Priority: Minor
> Fix For: 1.1
>
>
> Review codes in the
> [{{commons-geometry-hull}}|https://gitbox.apache.org/repos/asf?p=commons-geometry.git;a=tree;f=commons-geometry-hull;hb=HEAD]
> module.
> (x) Minimize the public API
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEOMETRY-144) Review API in "hull" module
[
https://issues.apache.org/jira/browse/GEOMETRY-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17526836#comment-17526836
]
Matt Juntunen commented on GEOMETRY-144:
The current implementation uses an algorithm-specific design. For example,
there is a public class named {{MonotoneChain}} that implements the "monotone
chain" 2D convex hull algorithm. I'm wondering if we should abandon this in
favor of providing just a single well-rounded algorithm option. For example,
the API could simply be
{code:java}
public final class ConvexHulls {
public static ConvexHull2D create2D(Collection pts) {
// ...
}
public static ConvexHull2D create3D(Collection pts) {
// ...
}
}
{code}
This relieves users of the need to be knowledgeable about convex hull
algorithms and gives us the flexibility to swap out the algorithm later on if
needed.
> Review API in "hull" module
> ---
>
> Key: GEOMETRY-144
> URL: https://issues.apache.org/jira/browse/GEOMETRY-144
> Project: Commons Geometry
> Issue Type: Task
>Reporter: Gilles Sadowski
>Assignee: Gilles Sadowski
>Priority: Minor
> Fix For: 1.1
>
>
> Review codes in the
> [{{commons-geometry-hull}}|https://gitbox.apache.org/repos/asf?p=commons-geometry.git;a=tree;f=commons-geometry-hull;hb=HEAD]
> module.
> (x) Minimize the public API
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEOMETRY-146) PointSet/Map closest points
[
https://issues.apache.org/jira/browse/GEOMETRY-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17526835#comment-17526835
]
Matt Juntunen commented on GEOMETRY-146:
PR is in: https://github.com/apache/commons-geometry/pull/195
> PointSet/Map closest points
> ---
>
> Key: GEOMETRY-146
> URL: https://issues.apache.org/jira/browse/GEOMETRY-146
> Project: Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Fix For: 1.1
>
>
> Add methods to the new {{PointSet}} and {{PointMap}} interfaces to allow
> querying of points in order of distance from a query point.
> {code:java}
> PointSet {
> // find the closest point to pt or null if empty
> P closest(P pt);
> // iterate through points in order, with points closest to pt coming first
> Iterable closestFirst(P pt);
> // find the farthest point from pt or null if emtpy
> P farthest(P pt);
> // iterate through point in order, with points farthest from pt coming
> first
> Iterable farthestFirst(P pt);
> }
> {code}
> {{PointMap}} should have similar methods providing access to the map keys and
> entries.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEOMETRY-146) PointSet/Map closest points
[
https://issues.apache.org/jira/browse/GEOMETRY-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17526158#comment-17526158
]
Matt Juntunen commented on GEOMETRY-146:
It turns out that my instincts on the performance of {{neighborEntries}} were
incorrect and I am not able to find a performance boost over just using
{{nearToFar}} or even just iterating through the entire map. Below are the JMH
results for the best implementation I could come up with.
||Benchmark||(dist)||(randomSeed)||(shape)||Mode||Cnt||Score||Error||Units||
|neighborEntries|random|1|block|avgt|5|18078272.739|± 2855877.430|ns/op|
|neighborEntriesFullBaseline|random|1|block|avgt|5|3953413.160|±
1299435.732|ns/op|
|neighborEntriesFullStreamBaseline|random|1|block|avgt|5|19190180.574|±
3775274.018|ns/op|
|neighborEntriesNearToFarBaseline|random|1|block|avgt|5|13143387.077|±
2344194.490|ns/op|
|neighborEntryIterable|random|1|block|avgt|5|15025352.786|± 3978281.128|ns/op|
- {{neighborEntries}} - supposedly "optimized" method
- {{neighborEntriesFullBaseline}} - iterating through the entire map and
checking the distance for each entry
- {{neighborEntriesFullStreamBaseline}} - filtering a stream over the map entry
set
- {{neighborEntriesNearToFarBaseline}} - iterating over the {{nearToFar}}
collection and breaking out of the loop when the max distance is passed
- {{neighborEntryIterable}} - iterator version of {{neighborEntries}}
Based on these results, I'm going to remove {{neighborEntries}} from the API.
There isn't a performance boost and the functionality can be implemented in
terms of the other methods.
> PointSet/Map closest points
> ---
>
> Key: GEOMETRY-146
> URL: https://issues.apache.org/jira/browse/GEOMETRY-146
> Project: Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Fix For: 1.1
>
>
> Add methods to the new {{PointSet}} and {{PointMap}} interfaces to allow
> querying of points in order of distance from a query point.
> {code:java}
> PointSet {
> // find the closest point to pt or null if empty
> P closest(P pt);
> // iterate through points in order, with points closest to pt coming first
> Iterable closestFirst(P pt);
> // find the farthest point from pt or null if emtpy
> P farthest(P pt);
> // iterate through point in order, with points farthest from pt coming
> first
> Iterable farthestFirst(P pt);
> }
> {code}
> {{PointMap}} should have similar methods providing access to the map keys and
> entries.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEOMETRY-146) PointSet/Map closest points
[
https://issues.apache.org/jira/browse/GEOMETRY-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17520664#comment-17520664
]
Matt Juntunen commented on GEOMETRY-146:
It can certainly be implemented using {{nearToFar}}. However, I may be able to
get some more performance out of the current implementations if the ordering
requirement is removed. If not, I'll remove this method from the API.
> PointSet/Map closest points
> ---
>
> Key: GEOMETRY-146
> URL: https://issues.apache.org/jira/browse/GEOMETRY-146
> Project: Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Fix For: 1.1
>
>
> Add methods to the new {{PointSet}} and {{PointMap}} interfaces to allow
> querying of points in order of distance from a query point.
> {code:java}
> PointSet {
> // find the closest point to pt or null if empty
> P closest(P pt);
> // iterate through points in order, with points closest to pt coming first
> Iterable closestFirst(P pt);
> // find the farthest point from pt or null if emtpy
> P farthest(P pt);
> // iterate through point in order, with points farthest from pt coming
> first
> Iterable farthestFirst(P pt);
> }
> {code}
> {{PointMap}} should have similar methods providing access to the map keys and
> entries.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEOMETRY-146) PointSet/Map closest points
[
https://issues.apache.org/jira/browse/GEOMETRY-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17520505#comment-17520505
]
Matt Juntunen commented on GEOMETRY-146:
bq. Hmm, I thought that it was inefficient (requiring iterating in order to
copy all references to entries into the returned collection)
Full enumeration is only required if the size is not known ahead of time, as in
the case of returning a collection representing entries within a specified
radius. The return values from {{nearToFar}} and {{farToNear}} represent the
entire map/set so we already know the size. The collections are lazily
populated views of the map/set data and only store enough information to
determine the next element to return during iteration. (This is why {{List}}
would still be inefficient here, since it would require much more storage to
support access by index. Hence, it is left to the caller to convert to a
{{List}} if needed.)
bq. Otherwise, it is great; and, thus, why not have
Great! I'll start converting to this API.
> PointSet/Map closest points
> ---
>
> Key: GEOMETRY-146
> URL: https://issues.apache.org/jira/browse/GEOMETRY-146
> Project: Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Fix For: 1.1
>
>
> Add methods to the new {{PointSet}} and {{PointMap}} interfaces to allow
> querying of points in order of distance from a query point.
> {code:java}
> PointSet {
> // find the closest point to pt or null if empty
> P closest(P pt);
> // iterate through points in order, with points closest to pt coming first
> Iterable closestFirst(P pt);
> // find the farthest point from pt or null if emtpy
> P farthest(P pt);
> // iterate through point in order, with points farthest from pt coming
> first
> Iterable farthestFirst(P pt);
> }
> {code}
> {{PointMap}} should have similar methods providing access to the map keys and
> entries.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEOMETRY-146) PointSet/Map closest points
[
https://issues.apache.org/jira/browse/GEOMETRY-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17520056#comment-17520056
]
Matt Juntunen commented on GEOMETRY-146:
{quote}IOW, assuming "deep" access, can {{PointMap}} instantiate a {{List}}
view object that would *lazily* navigate the map's content?
{quote}
No, that is not feasible with the current implementations.
{quote}If the low-level API only provides navigation (in "natural"/near-to-far
and "reverse"/far-to-near ordering), wouldn't it be clearer to let any
additional filtering belong to a higher-level API
{quote}
Yes, that sounds like a good approach. Along those lines, what do you think of
the following simplified API?
{code:java}
interface PointSet {
// get the element nearest to pt
P nearest(P pt);
// get the element farthest from pt
P farthest(P pt);
// get all elements in order of nearest to farthest relative to pt
Collection nearToFar(P pt);
// get all elements in order of farthest to nearest relative to pt
Collection farToNear(P pt);
// get a stream containing all elements neighboring pt, i.e.
// within maxDist of pt; the points may be in any order
Stream neighbors(P pt, double maxDist);
}
// same methods as PointSet but with the words "entry"/"entries"
// added for consistency with other map methods
interface PointMap {
Entry nearestEntry(P pt);
Entry farthestEntry(P pt);
Collection> entriesNearToFar(P pt);
Collection> entriesFarToNear(P pt);
Stream> neighborEntries(P pt, double maxDist);
}
{code}
A few notes here:
- All iteration is internal to the implementing map/set.
- {{nearToFar}} and {{farToNear}} return {{Collection}} since the number of
elements is known (i.e. the Collection contains all of the elements in the
map/set). This lets us support access through both {{Iterable}} and {{Stream}}
without needing a new type like {{StreamingIterable}}.
- {{neighbors}} returns a {{Stream}} since the number of elements is not known
without enumerating all members (at least in the current implementations). The
elements may be returned in any order.
- {{nearest/farthest}} are present to allow optimized retrieval of single
values.
> PointSet/Map closest points
> ---
>
> Key: GEOMETRY-146
> URL: https://issues.apache.org/jira/browse/GEOMETRY-146
> Project: Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Fix For: 1.1
>
>
> Add methods to the new {{PointSet}} and {{PointMap}} interfaces to allow
> querying of points in order of distance from a query point.
> {code:java}
> PointSet {
> // find the closest point to pt or null if empty
> P closest(P pt);
> // iterate through points in order, with points closest to pt coming first
> Iterable closestFirst(P pt);
> // find the farthest point from pt or null if emtpy
> P farthest(P pt);
> // iterate through point in order, with points farthest from pt coming
> first
> Iterable farthestFirst(P pt);
> }
> {code}
> {{PointMap}} should have similar methods providing access to the map keys and
> entries.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEOMETRY-146) PointSet/Map closest points
[
https://issues.apache.org/jira/browse/GEOMETRY-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519970#comment-17519970
]
Matt Juntunen commented on GEOMETRY-146:
I've thought about it a bit more and I think I might see what you mean by an
inconsistency in the API. By returning {{DistanceOrdering}} from the
subset-selection methods we are assuming that the natural way to access
elements relative to a specific point or within a specific radius is by
increasing or decreasing distance. This is reasonable enough for the current
implementations, but what if this is not the case for future implementations?
What if an implementation incurs a large processing overhead in order to return
points in a specific distance ordering but can return them immediately when the
order does not matter. It would be unfortunate to impose this cost on callers
who only care about the actual points returned and not about their ordering. It
seems to me that we need an API that can perform the following:
- get the single nearest/farthest element from a given point and within an
optional search radius
- get elements in order of increasing or decreasing distance from a given point
and within an optional search radius
- get elements _in any order_ within a search radius of a specified point
Does this match what you're picturing?
> PointSet/Map closest points
> ---
>
> Key: GEOMETRY-146
> URL: https://issues.apache.org/jira/browse/GEOMETRY-146
> Project: Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Fix For: 1.1
>
>
> Add methods to the new {{PointSet}} and {{PointMap}} interfaces to allow
> querying of points in order of distance from a query point.
> {code:java}
> PointSet {
> // find the closest point to pt or null if empty
> P closest(P pt);
> // iterate through points in order, with points closest to pt coming first
> Iterable closestFirst(P pt);
> // find the farthest point from pt or null if emtpy
> P farthest(P pt);
> // iterate through point in order, with points farthest from pt coming
> first
> Iterable farthestFirst(P pt);
> }
> {code}
> {{PointMap}} should have similar methods providing access to the map keys and
> entries.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (GEOMETRY-146) PointSet/Map closest points
[
https://issues.apache.org/jira/browse/GEOMETRY-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519968#comment-17519968
]
Matt Juntunen edited comment on GEOMETRY-146 at 4/9/22 11:45 AM:
-
>From a previous response...
bq. You intentionally hid the internal implementation of PointMap, yet the
"near"/"far" methods make one assume that such an implementation must support
specific iteration "modes"; hence I'm feeling uncomfortable with the
(apparent?) inconsistency, at the "public" level.
Yes, I've made the _near/far_ concepts part of the {{PointMap/Set}} interfaces.
I don't see how this produces any inconsistency. The interfaces describe the
methods that must be available and it is up to the implementations on how they
accomplish that.
bq. For example, from your answers above, I seem to understand that PointMap
and DistanceOrdering are tightly coupled;
I wouldn't say they're "tightly coupled" since they are interfaces; more like
they are closely related.
bq. one wonders: "nearest"/farthest to what? The reference point is
"out-of-scope" (so to speak)...
Yes, intentionally so. The {{DistanceOrdering}} interface defines methods for
accessing a particular subset of the points. It does not answer the question of
what is selected. This is the separation of the _what_ and the _how_ that we
mentioned previously. I could easily picture using this interface in the future
for Euclidean 2D and 3D to access points in order of distance from a line. If
{{DistanceOrdering}} defined the target of the distance computation, this would
be more complicated.
bq. why not make the coupling obvious, as in
I don't see any added benefit in that API. Rather, it doesn't seem as
expressive or readable. Ex:
{code:java}
// I find this ...
Iterable> it = map.entriesFrom(pt).nearToFar();
// easier to read than this ...
Iterable> it = map.entries(pt, DistanceOrdering.ASCENDING);
{code}
bq. I'm also a bit wary of only returning a StreamableIterator interface rather
than e.g. a List, because in the potential use case which I have in mind, the
selected points are rather few (as compared to the map's contents) and the
number of them should be known in order to, for example, compute an
interpolation of the associated values.
{{StreamableIterator}} is returned instead of {{List}} for two reasons:
1. The total number of elements within the area of interest is generally not
known until all of the elements are enumerated. The main exception to this is
when the entire map/set is being iterated.
2. The list could be quite large so it should be up to the caller on whether or
not to incur the cost of allocation.
If a list is needed, it is a one-liner:
{code:java}
List closePts = set.withinDistance(p,
dist).nearToFar().stream().collect(Collectors.toList());
{code}
was (Author: mattjuntunen):
>From a previous response...
bq. You intentionally hid the internal implementation of PointMap, yet the
"near"/"far" methods make one assume that such an implementation must support
specific iteration "modes"; hence I'm feeling uncomfortable with the
(apparent?) inconsistency, at the "public" level.
Yes, I've made the _near/far_ concepts part of the {{PointMap/Set}} interfaces.
I don't see how this produces any inconsistency. The interfaces describe the
methods that must be available and it is up to the implementations on how they
accomplish that.
bq. For example, from your answers above, I seem to understand that PointMap
and DistanceOrdering are tightly coupled;
I wouldn't say they're "tightly coupled" since they are interfaces; more like
they are closely related.
bq. one wonders: "nearest"/farthest to what? The reference point is
"out-of-scope" (so to speak)...
Yes, intentionally so. The {{DistanceOrdering}} interface defines methods for
accessing a particular subset of the points. It does not answer the question of
what is selected. This is the separation of the _what_ and the _how_ that we
mentioned previously. I could easily picture using this interface in the future
for Euclidean 2D and 3D to access points in order of distance from a line. If
{{DistanceOrdering}} defined the target of the distance computation, this would
be more complicated.
bq. why not make the coupling obvious, as in
I don't see any added benefit in that API. Rather, it doesn't seem as
expressive or readable. Ex:
{code:java}
// I find this ...
Iterable> it = map.entriesFrom(pt).nearToFar();
// easier to read than this ...
Iterable> it = map.entries(pt, DistanceOrdering.ASCENDING);
{code}
bq. I'm also a bit wary of only returning a StreamableIterator interface rather
than e.g. a List, because in the potential use case which I have in mind, the
selected points are rather few (as compared to the map's contents) and the
number of them should be known in order to, for example, compute an
interpolation of the associated values.
[jira] [Commented] (GEOMETRY-146) PointSet/Map closest points
[
https://issues.apache.org/jira/browse/GEOMETRY-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519968#comment-17519968
]
Matt Juntunen commented on GEOMETRY-146:
>From a previous response...
bq. You intentionally hid the internal implementation of PointMap, yet the
"near"/"far" methods make one assume that such an implementation must support
specific iteration "modes"; hence I'm feeling uncomfortable with the
(apparent?) inconsistency, at the "public" level.
Yes, I've made the _near/far_ concepts part of the {{PointMap/Set}} interfaces.
I don't see how this produces any inconsistency. The interfaces describe the
methods that must be available and it is up to the implementations on how they
accomplish that.
bq. For example, from your answers above, I seem to understand that PointMap
and DistanceOrdering are tightly coupled;
I wouldn't say they're "tightly coupled" since they are interfaces; more like
they are closely related.
bq. one wonders: "nearest"/farthest to what? The reference point is
"out-of-scope" (so to speak)...
Yes, intentionally so. The {{DistanceOrdering}} interface defines methods for
accessing a particular subset of the points. It does not answer the question of
what is selected. This is the separation of the _what_ and the _how_ that we
mentioned previously. I could easily picture using this interface in the future
for Euclidean 2D and 3D to access points in order of distance from a line. If
{{DistanceOrdering}} defined the target of the distance computation, this would
be more complicated.
bq. why not make the coupling obvious, as in
I don't see any added benefit in that API. Rather, it doesn't seem as
expressive or readable. Ex:
{code:java}
// I find this ...
Iterable> it = map.entriesFrom(pt).nearToFar();
// easier to read than this ...
Iterable> it = map.entries(pt, DistanceOrdering.ASCENDING);
{code}
bq. I'm also a bit wary of only returning a StreamableIterator interface rather
than e.g. a List, because in the potential use case which I have in mind, the
selected points are rather few (as compared to the map's contents) and the
number of them should be known in order to, for example, compute an
interpolation of the associated values.
{{StreamableIterator}} is returned instead of {{List}} for two reasons:
1. The total number of elements within the area of interest is generally not
known until all of the elements are enumerated. The main exception to this is
when the entire map/set is being iterated.
2. The list could be quite large so it should be up to the caller on whether or
not to incur the cost of allocation.
If a list is needed, it is a one-liner:
{{code:java}
List closePts = set.withinDistance(p,
dist).nearToFar().stream().collect(Collectors.toList());
{code}
> PointSet/Map closest points
> ---
>
> Key: GEOMETRY-146
> URL: https://issues.apache.org/jira/browse/GEOMETRY-146
> Project: Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Fix For: 1.1
>
>
> Add methods to the new {{PointSet}} and {{PointMap}} interfaces to allow
> querying of points in order of distance from a query point.
> {code:java}
> PointSet {
> // find the closest point to pt or null if empty
> P closest(P pt);
> // iterate through points in order, with points closest to pt coming first
> Iterable closestFirst(P pt);
> // find the farthest point from pt or null if emtpy
> P farthest(P pt);
> // iterate through point in order, with points farthest from pt coming
> first
> Iterable farthestFirst(P pt);
> }
> {code}
> {{PointMap}} should have similar methods providing access to the map keys and
> entries.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEOMETRY-146) PointSet/Map closest points
[
https://issues.apache.org/jira/browse/GEOMETRY-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519538#comment-17519538
]
Matt Juntunen commented on GEOMETRY-146:
{quote}From this assumption, I'd suggest that the class name reflects its
importance, similarly to the "Navigable" qualifier in the [JDK
{{NavigableMap}}|https://docs.oracle.com/javase/8/docs/api/java/util/NavigableMap.html].
{quote}
It is part of the class name: {{DistanceOrdering}}, which is returned from
several of the methods in my proposed API.
bq. In this case, there may be no reason; but we could imagine another selector
where some part of the computation is performed at instantiation and should not
be repeated for each point.
Yes. I would imagine a separate method in the API for that.
{quote}Could selectors be defined as
class PointMap {
public interface Selector extends Function, P> {};
}
?
{quote}
Do you mean
{code:java}
interface Selector extends Function> {}
{code}
?
In other words, the selector accepts a point and returns a {{PointMap}} view?
There are 2 issues with this:
- This presupposes that the only selection criteria to be used will be a point,
which may not be the case. For example, what if we wanted to select points with
a bounding box? That would not fit this interface.
- Returning another full {{PointMap}} instance as a view of the main map is not
feasible at this point. Doing so would be very complicated with the current
algorithms and I don't believe it would have much use either.
bq. Can the "sub-map" be a "view" of the same data-structure?
That's what I have implemented. {{DistanceOrdering}} is a view of the
underlying {{PointMap/Set}}. It is accessed through selection methods (e.g.
{{PointMap.entriesWithinDistance(P, double)}}), similar to {{Map.entrySet()}}.
{quote}
Given a point "p" of type P, are the 2 iterators (over all points in the
PointMap instance):
in increasing distance from "p"
in decreasing distance
"naturally" (efficiently) defined?
{quote}
Yes.
It would be helpful to me if you could respond to my latest API proposal from
Mar 30. I feel like this both meets some of the requirements that you are
mentioning as well as being similar to the approaches used in {{java.util.Map}}.
> PointSet/Map closest points
> ---
>
> Key: GEOMETRY-146
> URL: https://issues.apache.org/jira/browse/GEOMETRY-146
> Project: Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Fix For: 1.1
>
>
> Add methods to the new {{PointSet}} and {{PointMap}} interfaces to allow
> querying of points in order of distance from a query point.
> {code:java}
> PointSet {
> // find the closest point to pt or null if empty
> P closest(P pt);
> // iterate through points in order, with points closest to pt coming first
> Iterable closestFirst(P pt);
> // find the farthest point from pt or null if emtpy
> P farthest(P pt);
> // iterate through point in order, with points farthest from pt coming
> first
> Iterable farthestFirst(P pt);
> }
> {code}
> {{PointMap}} should have similar methods providing access to the map keys and
> entries.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEOMETRY-146) PointSet/Map closest points
[
https://issues.apache.org/jira/browse/GEOMETRY-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516531#comment-17516531
]
Matt Juntunen commented on GEOMETRY-146:
bq. Discussion can continue on the latter; that does not preclude committing
the former (but please include "WIP" in the commit message, and mark the
relevant codes with "TBD", with a link to here).
Good to know. I'll keep everything on my working branch for now so that we
don't have a bunch of renaming of classes/methods in master.
bq. You did not comment about what was wrong with my proposed API, i.e. one
that would keep iteration an internal part of the "result set".
I agree with your thought of separating these operations into two parts: a
"subset selection" part and an "iteration" part. My main objection to the APi
example you gave is that I didn't see a way to specify the order of iteration.
In your example above, how would one specify that the results should be
returned in order of increasing distance?
{code:java}
PointMap.EntrySetSelector selector =
map.withinDistance(resolution);
// ...
PointMap.EntrySet subSet = selector.apply(v);
// how do I iterate over subSet from near to far?
{code}
Also, the subset selection here seems to be split into two parts: the first to
specify the distance and the second to specify the reference point. I don't see
a reason to separate these.
In my most recent API proposal, I do have a separation between subset selection
and iteration.
{code:java}
PointSet set = EuclideanCollectionUtils.pointSet3D(precision);
// select the subset of points within 1 unit from the origin
DistanceOrdering subset = set.withinDistance(Vector3D.ZERO, 1);
// iterate over the subset from near to far
List subset.nearToFar().stream()
.collect(Collectors.toList());
// get the farthest entry from the origin but still within the maximum distance
Vector3D nearest = subset.nearest();
{code}
bq. You intentionally hid the internal implementation of PointMap, yet the
"near"/"far" methods make one assume that such an implementation must support
specific iteration "modes"; hence I'm feeling uncomfortable with the
(apparent?) inconsistency, at the "public" level.
Yes, I would expect all {{PointMap/Set}} implementations to provide these
near/far iteration modes. I picture this as similar to the iteration order
methods provided by {{java.util.NavigableMap}} but applying to all spaces and
dimensions. Computing distance between points is one of the few things that all
spaces and dimensions provide so I feel that placing these methods in the
public API is appropriate.
bq. Out of curiosity, could you document (in the "examples" module) the actual
use cases that require one or the other iteration direction? That would also
help us test alternative APIs and where to draw the line between "public" and
"internal".
Yes, I am planning on adding examples in the user guide as part of this ticket.
In general, it frequently happens that distance from a certain point is part of
the point selection criteria for geometric algorithms. For example, the first
step in the quickhull algorithm is typically construction of a maximally
spanning tetrahedron. The first edge in this tetrahedron could be constructed
by selecting a point with a minimum x,y, and/or z coordinate and then selecting
the point from the set farthest from that point.
As a more concrete example, consider that a {{PointMap}} is used to represent
geographic locations and meta data. A near-to-far ordering could be used to
locate the nearest city from a specified location with a population of at least
X without requiring all points to be examined. Similarly, a far-to-near
ordering could be used to determine the worst-case distance a package would
need to travel when being shipped to a location from one of a number of cities
containing distribution centers.
In general, I consider that this near/far qualification is important enough to
warrant inclusion in the top-level public API.
> PointSet/Map closest points
> ---
>
> Key: GEOMETRY-146
> URL: https://issues.apache.org/jira/browse/GEOMETRY-146
> Project: Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Fix For: 1.1
>
>
> Add methods to the new {{PointSet}} and {{PointMap}} interfaces to allow
> querying of points in order of distance from a query point.
> {code:java}
> PointSet {
> // find the closest point to pt or null if empty
> P closest(P pt);
> // iterate through points in order, with points closest to pt coming first
> Iterable closestFirst(P pt);
> // find the farthest point from pt or null if emtpy
> P farthest(P pt);
> // iterate through point in order, with points farthest from pt coming
> first
> Iterable farthestFirst(P
[jira] [Commented] (GEOMETRY-146) PointSet/Map closest points
[
https://issues.apache.org/jira/browse/GEOMETRY-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515937#comment-17515937
]
Matt Juntunen commented on GEOMETRY-146:
I now have the internal logic for these operations implemented in all spaces
and dimensions. All that's left now is to decide on the public API, write a few
more tests, and then document it.
I see what you're saying about having a general API but I don't have any more
ideas at this time other than the one I posted more recently. What I'm looking
for is the ability to specify a point with an optional radius and then either
* obtain the single nearest/farthest point, or
* iterate through all available points in nearest to farthest or farthest to
nearest order.
These two operations must be separate since there is a significant performance
benefit to obtaining a single result versus iterating through the available
points. (The single point version can be performed recursively in the
multidimensional cases while iteration requires allocation of queues and other
bookkeeping structures.) Also, I would like the specification of the iteration
order to be explicit and use the terms _near_/_far_ or similar in order to make
things readable and self-documenting. The API I proposed fulfills these
requirements and IMHO provides a pretty good generalization of the operations
in question. Do you have any objections to this API or any alternative
suggestions?
> PointSet/Map closest points
> ---
>
> Key: GEOMETRY-146
> URL: https://issues.apache.org/jira/browse/GEOMETRY-146
> Project: Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Fix For: 1.1
>
>
> Add methods to the new {{PointSet}} and {{PointMap}} interfaces to allow
> querying of points in order of distance from a query point.
> {code:java}
> PointSet {
> // find the closest point to pt or null if empty
> P closest(P pt);
> // iterate through points in order, with points closest to pt coming first
> Iterable closestFirst(P pt);
> // find the farthest point from pt or null if emtpy
> P farthest(P pt);
> // iterate through point in order, with points farthest from pt coming
> first
> Iterable farthestFirst(P pt);
> }
> {code}
> {{PointMap}} should have similar methods providing access to the map keys and
> entries.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEOMETRY-146) PointSet/Map closest points
[
https://issues.apache.org/jira/browse/GEOMETRY-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514757#comment-17514757
]
Matt Juntunen commented on GEOMETRY-146:
How about this?
{code:java}
// interface allowing easy conversion to streams in situations where
// the number of elements is not known ahead of time
interface StreamingIterable extends Iterable {
default Stream stream() {
return StreamSupport.stream(spliterator(), false);
}
}
// represents a view of a collection ordered by distance
// relative to a reference point
interface DistanceOrdering {
T nearest();
T farthest();
StreamingIterable nearToFar();
StreamingIterable farToNear();
}
interface PointSet {
DistanceOrdering from(P pt);
DistanceOrdering withinRadius(P pt, double radius);
}
interface PointMap {
DistanceOrdering> entriesFrom(P pt);
DistanceOrdering> entriesWithinRadius(P pt, double radius);
}
{code}
Usage would then look like this:
{code:java}
// get the entry in the map farthest from the origin
PointMap map = ...
Entry result = map.from(Vector3D.ZERO).farthest();
// find the element nearest to refPt in the set that has a positive x coordinate
// and is not farther away than 3
PointSet set = ...
Vector3D refPt = Vector3D.of(1, 2, 3);
Vector3D result = null;
for (Vector3D pt : set.withinRadius(refPt, 3).nearToFar()) {
if (pt.getX() > 0) {
result = pt;
break;
}
}
// find the k nearest neighbors of pt
PointSet set = ...
Vector3D pt = Vector3D.of(1, 2, 3);
List neighbors = set.from(pt).nearToFar().stream()
.limit(k)
.collect(Collectors.toList());
{code}
> PointSet/Map closest points
> ---
>
> Key: GEOMETRY-146
> URL: https://issues.apache.org/jira/browse/GEOMETRY-146
> Project: Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Fix For: 1.1
>
>
> Add methods to the new {{PointSet}} and {{PointMap}} interfaces to allow
> querying of points in order of distance from a query point.
> {code:java}
> PointSet {
> // find the closest point to pt or null if empty
> P closest(P pt);
> // iterate through points in order, with points closest to pt coming first
> Iterable closestFirst(P pt);
> // find the farthest point from pt or null if emtpy
> P farthest(P pt);
> // iterate through point in order, with points farthest from pt coming
> first
> Iterable farthestFirst(P pt);
> }
> {code}
> {{PointMap}} should have similar methods providing access to the map keys and
> entries.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEOMETRY-146) PointSet/Map closest points
[
https://issues.apache.org/jira/browse/GEOMETRY-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514065#comment-17514065
]
Matt Juntunen commented on GEOMETRY-146:
I'm not sure if we can make this work well. We can definitely make it _work_,
but without access to the private details of the data structures the
{{EntrySetSelector}} interfaces would be left to iterate through the entire map
in order to find the correct entries.
I've thought about the names some more and I've come up with what I consider
better alternatives based on the antonym pair _near_/_far_ (as opposed to
_close_/_far_).
{code:java}
PointSet {
P nearest(P pt);
P nearestWithinRadius(P pt, double radius);
P farthest(P pt);
Collection nearToFar(P pt);
Collection farToNear(P pt);
}
PointMap {
Map.Entry nearestEntry(P pt);
Map.Entry nearestEntryWithinRadius(P pt, double radius);
Map.Entry farthestEntry(P pt);
Collection> entriesNearToFar(P pt);
Collection> entriesFarToNearP pt);
}
{code}
These names are concise and (to me, at least) provide a good mental image of
the operation.
> PointSet/Map closest points
> ---
>
> Key: GEOMETRY-146
> URL: https://issues.apache.org/jira/browse/GEOMETRY-146
> Project: Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Fix For: 1.1
>
>
> Add methods to the new {{PointSet}} and {{PointMap}} interfaces to allow
> querying of points in order of distance from a query point.
> {code:java}
> PointSet {
> // find the closest point to pt or null if empty
> P closest(P pt);
> // iterate through points in order, with points closest to pt coming first
> Iterable closestFirst(P pt);
> // find the farthest point from pt or null if emtpy
> P farthest(P pt);
> // iterate through point in order, with points farthest from pt coming
> first
> Iterable farthestFirst(P pt);
> }
> {code}
> {{PointMap}} should have similar methods providing access to the map keys and
> entries.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEOMETRY-146) PointSet/Map closest points
[
https://issues.apache.org/jira/browse/GEOMETRY-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17513662#comment-17513662
]
Matt Juntunen commented on GEOMETRY-146:
This looks interesting. Could you provide some examples? What would the calling
code look like?
> PointSet/Map closest points
> ---
>
> Key: GEOMETRY-146
> URL: https://issues.apache.org/jira/browse/GEOMETRY-146
> Project: Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Fix For: 1.1
>
>
> Add methods to the new {{PointSet}} and {{PointMap}} interfaces to allow
> querying of points in order of distance from a query point.
> {code:java}
> PointSet {
> // find the closest point to pt or null if empty
> P closest(P pt);
> // iterate through points in order, with points closest to pt coming first
> Iterable closestFirst(P pt);
> // find the farthest point from pt or null if emtpy
> P farthest(P pt);
> // iterate through point in order, with points farthest from pt coming
> first
> Iterable farthestFirst(P pt);
> }
> {code}
> {{PointMap}} should have similar methods providing access to the map keys and
> entries.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEOMETRY-146) PointSet/Map closest points
[
https://issues.apache.org/jira/browse/GEOMETRY-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17513593#comment-17513593
]
Matt Juntunen commented on GEOMETRY-146:
Here is another shot at the API. I've added a {{closestWithinDistance}} method
and the map names all contain the word "entry" in some form to indicate that an
entry is returned (similar to {{entrySet}}). I've also realized that we can
return full {{Collection}} instances from the view methods instead of just
{{Iterable}} since we already know the number of entries. This will make the
returned views easier to work with, especially since callers can convert to a
stream just by calling {{stream()}}.
I am still not sold on the method names. They feel kind of clunky to me so I'm
open to suggestions.
{code:java}
PointSet {
// return the element closest to pt or null if empty
P closest(P pt);
// return the element closest to pt and within the specified
// distance or null if it does not exist
P closestWithinDistance(P pt, double dist);
// return the element farthest from pt or null if empty
P farthest(P pt);
// view of all elements in order of ascending distance from pt
Collection distanceAscending(P pt);
// view of all elements in order of descending distance from pt
Collection distanceDescending(P pt);
}
PointMap {
// return the entry closest to pt or null if empty
Map.Entry closestEntry(P pt);
// return the entry closest to pt and within the specified
// distance or null if it does not exist
Map.Entry closeEntryWithinDistance(P pt, double dist);
// return the entry farthest from pt or null if empty
Map.Entry farthestEntry(P pt);
// view of all entries in order of ascending distance from pt
Collection> entriesByDistanceAscending(P pt);
// view of all entries in order of descending distance from pt
Collection> entriesByDistanceDescending(P pt);
}
{code}
Thoughts?
> PointSet/Map closest points
> ---
>
> Key: GEOMETRY-146
> URL: https://issues.apache.org/jira/browse/GEOMETRY-146
> Project: Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Fix For: 1.1
>
>
> Add methods to the new {{PointSet}} and {{PointMap}} interfaces to allow
> querying of points in order of distance from a query point.
> {code:java}
> PointSet {
> // find the closest point to pt or null if empty
> P closest(P pt);
> // iterate through points in order, with points closest to pt coming first
> Iterable closestFirst(P pt);
> // find the farthest point from pt or null if emtpy
> P farthest(P pt);
> // iterate through point in order, with points farthest from pt coming
> first
> Iterable farthestFirst(P pt);
> }
> {code}
> {{PointMap}} should have similar methods providing access to the map keys and
> entries.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEOMETRY-146) PointSet/Map closest points
[
https://issues.apache.org/jira/browse/GEOMETRY-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17512726#comment-17512726
]
Matt Juntunen commented on GEOMETRY-146:
Working on this here:
https://github.com/darkma773r/commons-geometry/tree/closest
> PointSet/Map closest points
> ---
>
> Key: GEOMETRY-146
> URL: https://issues.apache.org/jira/browse/GEOMETRY-146
> Project: Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Fix For: 1.1
>
>
> Add methods to the new {{PointSet}} and {{PointMap}} interfaces to allow
> querying of points in order of distance from a query point.
> {code:java}
> PointSet {
> // find the closest point to pt or null if empty
> P closest(P pt);
> // iterate through points in order, with points closest to pt coming first
> Iterable closestFirst(P pt);
> // find the farthest point from pt or null if emtpy
> P farthest(P pt);
> // iterate through point in order, with points farthest from pt coming
> first
> Iterable farthestFirst(P pt);
> }
> {code}
> {{PointMap}} should have similar methods providing access to the map keys and
> entries.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEOMETRY-142) Point Set/Map
[ https://issues.apache.org/jira/browse/GEOMETRY-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Juntunen resolved GEOMETRY-142. Resolution: Done > Point Set/Map > - > > Key: GEOMETRY-142 > URL: https://issues.apache.org/jira/browse/GEOMETRY-142 > Project: Commons Geometry > Issue Type: New Feature >Reporter: Matt Juntunen >Assignee: Matt Juntunen >Priority: Major > Fix For: 1.1 > > > It would be very useful to have set and map implementations that accepts > points and vectors as keys and use "fuzzy" look up logic, where values are > compared using a precision context. This would have uses in a number of > situations, including the implementation of GEOMETRY-110. > Options for the implementation of such classes include > * BSP trees (as already implemented) > * k-d trees > * quadtrees/octrees > * r-trees -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEOMETRY-142) Point Set/Map
[ https://issues.apache.org/jira/browse/GEOMETRY-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17512725#comment-17512725 ] Matt Juntunen commented on GEOMETRY-142: Completed in commit 6c6d046532ab6c0c5cd670aaa4dc9ad384190d97. > Point Set/Map > - > > Key: GEOMETRY-142 > URL: https://issues.apache.org/jira/browse/GEOMETRY-142 > Project: Commons Geometry > Issue Type: New Feature >Reporter: Matt Juntunen >Assignee: Matt Juntunen >Priority: Major > Fix For: 1.1 > > > It would be very useful to have set and map implementations that accepts > points and vectors as keys and use "fuzzy" look up logic, where values are > compared using a precision context. This would have uses in a number of > situations, including the implementation of GEOMETRY-110. > Options for the implementation of such classes include > * BSP trees (as already implemented) > * k-d trees > * quadtrees/octrees > * r-trees -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEOMETRY-146) PointSet/Map closest points
[
https://issues.apache.org/jira/browse/GEOMETRY-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17508796#comment-17508796
]
Matt Juntunen commented on GEOMETRY-146:
The general iteration methods are required for the use cases I'm picturing.
Say, for example, you need to find the point closest to a query point that also
satisfies some other condition, such as being associated with a particular
value. This could be accomplished with a map as follows:
{code:java}
PointMap map = EuclideanCollections.pointMap3D(precision);
// add points and values ...
Vector3D queryPt = Vector3D.of(1, 2, 3);
Vector3D resultPt = null;
for (Map.Entry entry : map.closestFirst(queryPt)) {
if (entry.getValue() > 100) {
resultPt = entry.getKey();
break;
}
}
{code}
A similar use case for {{PointSet}} could look like this:
{code:java}
PointSet set = EuclideanCollections.pointSet3D(precision);
// add points ...
Vector3D queryPt = Vector3D.of(1, 2, 3);
Vector3D resultPt = null;
for (Vector3D pt : entry) {
if (pt.getX() > queryPt.getX()) {
resultPt = pt;
break;
}
}
{code}
The {{closestInRange}} methods could actually be implemented using this general
approach.
{code:java}
public List closestInRange(P pt, double dist) {
List result = new ArrayList<>();
for (P setPt : set.closestFirst(pt)) {
if (setPt.distance(pt) > dist) {
break;
}
result.add(setPt);
}
return result;
}
{code}
I'm picturing the implemented iteration operations being lazy (as they are in
the {{RegionBSPTreeXD}} classes) and only pulling values as needed. There then
shouldn't be any wasted resources from this approach.
> PointSet/Map closest points
> ---
>
> Key: GEOMETRY-146
> URL: https://issues.apache.org/jira/browse/GEOMETRY-146
> Project: Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Fix For: 1.1
>
>
> Add methods to the new {{PointSet}} and {{PointMap}} interfaces to allow
> querying of points in order of distance from a query point.
> {code:java}
> PointSet {
> // find the closest point to pt or null if empty
> P closest(P pt);
> // iterate through points in order, with points closest to pt coming first
> Iterable closestFirst(P pt);
> // find the farthest point from pt or null if emtpy
> P farthest(P pt);
> // iterate through point in order, with points farthest from pt coming
> first
> Iterable farthestFirst(P pt);
> }
> {code}
> {{PointMap}} should have similar methods providing access to the map keys and
> entries.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEOMETRY-147) BoundsXD Linecastable
Matt Juntunen created GEOMETRY-147:
--
Summary: BoundsXD Linecastable
Key: GEOMETRY-147
URL: https://issues.apache.org/jira/browse/GEOMETRY-147
Project: Commons Geometry
Issue Type: New Feature
Reporter: Matt Juntunen
Fix For: 1.1
Make the {{Bounds2D}} and {{Bounds3D}} classes implement {{Linecastable}}. Use
the
["slabs"|https://education.siggraph.org/static/HyperGraph/raytrace/rtinter3.htm]
algorithm to determine intersection points.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEOMETRY-146) PointSet/Map closest points
[
https://issues.apache.org/jira/browse/GEOMETRY-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Juntunen updated GEOMETRY-146:
---
Fix Version/s: 1.1
> PointSet/Map closest points
> ---
>
> Key: GEOMETRY-146
> URL: https://issues.apache.org/jira/browse/GEOMETRY-146
> Project: Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Fix For: 1.1
>
>
> Add methods to the new {{PointSet}} and {{PointMap}} interfaces to allow
> querying of points in order of distance from a query point.
> {code:java}
> PointSet {
> // find the closest point to pt or null if empty
> P closest(P pt);
> // iterate through points in order, with points closest to pt coming first
> Iterable closestFirst(P pt);
> // find the farthest point from pt or null if emtpy
> P farthest(P pt);
> // iterate through point in order, with points farthest from pt coming
> first
> Iterable farthestFirst(P pt);
> }
> {code}
> {{PointMap}} should have similar methods providing access to the map keys and
> entries.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEOMETRY-146) PointSet/Map closest points
Matt Juntunen created GEOMETRY-146:
--
Summary: PointSet/Map closest points
Key: GEOMETRY-146
URL: https://issues.apache.org/jira/browse/GEOMETRY-146
Project: Commons Geometry
Issue Type: New Feature
Reporter: Matt Juntunen
Add methods to the new {{PointSet}} and {{PointMap}} interfaces to allow
querying of points in order of distance from a query point.
{code:java}
PointSet {
// find the closest point to pt or null if empty
P closest(P pt);
// iterate through points in order, with points closest to pt coming first
Iterable closestFirst(P pt);
// find the farthest point from pt or null if emtpy
P farthest(P pt);
// iterate through point in order, with points farthest from pt coming first
Iterable farthestFirst(P pt);
}
{code}
{{PointMap}} should have similar methods providing access to the map keys and
entries.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEOMETRY-142) Point Set/Map
[ https://issues.apache.org/jira/browse/GEOMETRY-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17504706#comment-17504706 ] Matt Juntunen commented on GEOMETRY-142: I think I've gotten this as good as I'm going to get it. The [final PR|https://github.com/apache/commons-geometry/pull/194] is submitted and ready for review. Let me know what you think! > Point Set/Map > - > > Key: GEOMETRY-142 > URL: https://issues.apache.org/jira/browse/GEOMETRY-142 > Project: Commons Geometry > Issue Type: New Feature >Reporter: Matt Juntunen >Assignee: Matt Juntunen >Priority: Major > Fix For: 1.1 > > > It would be very useful to have set and map implementations that accepts > points and vectors as keys and use "fuzzy" look up logic, where values are > compared using a precision context. This would have uses in a number of > situations, including the implementation of GEOMETRY-110. > Options for the implementation of such classes include > * BSP trees (as already implemented) > * k-d trees > * quadtrees/octrees > * r-trees -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEOMETRY-142) Point Set/Map
[ https://issues.apache.org/jira/browse/GEOMETRY-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17502028#comment-17502028 ] Matt Juntunen commented on GEOMETRY-142: I've made some performance improvements and added the set implementations and basic tests. Everything should be ready for review at this point on the draft PR, although I still need to add some more unit tests and documentation. > Point Set/Map > - > > Key: GEOMETRY-142 > URL: https://issues.apache.org/jira/browse/GEOMETRY-142 > Project: Commons Geometry > Issue Type: New Feature >Reporter: Matt Juntunen >Assignee: Matt Juntunen >Priority: Major > Fix For: 1.1 > > > It would be very useful to have set and map implementations that accepts > points and vectors as keys and use "fuzzy" look up logic, where values are > compared using a precision context. This would have uses in a number of > situations, including the implementation of GEOMETRY-110. > Options for the implementation of such classes include > * BSP trees (as already implemented) > * k-d trees > * quadtrees/octrees > * r-trees -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEOMETRY-145) GSoC 2022
Matt Juntunen created GEOMETRY-145:
--
Summary: GSoC 2022
Key: GEOMETRY-145
URL: https://issues.apache.org/jira/browse/GEOMETRY-145
Project: Apache Commons Geometry
Issue Type: Wish
Reporter: Matt Juntunen
Placeholder for tasks that could be undertaken in this year's
[GSoC|https://summerofcode.withgoogle.com/].
Ideas:
- Examine and potentially redesign the API and algorithms in the
{{commons-geometry-enclosing}} module. The goal here is to make consistent use
of the newer geometry API and ensure that the algorithms are sound.
- Design and implement a parser/writer for the [PLY file
format|http://paulbourke.net/dataformats/ply/] in the
{{commons-geometry-io-euclidean}} module.
- Design an API for advanced 3D mesh data structures (e.g. halfedge meshes) and
operations (e.g. surface subdivision, smoothing, etc). This may end up being
another module, e.g. {{commons-geometry-mesh}}.
- Create a series of user guides and/or tutorials demonstrating best-practice
use of the library.
- other ideas ... ?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEOMETRY-142) Point Set/Map
[
https://issues.apache.org/jira/browse/GEOMETRY-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17496825#comment-17496825
]
Matt Juntunen commented on GEOMETRY-142:
Just finished implementing spherical 1D and 2D maps. The Euclidean and
spherical 1D maps are based on {{TreeMap}} while all of the multidimensional
maps extend {{{}AbstractBucketPointMap{}}}, which contains the majority of the
code. I still need to add some dimension-specific unit tests and maybe tweak
some things. For example, I think there needs to be some logic that will
rebuild the tree if it gets too out of balance. Adding points in sorted order
currently produces trees with unacceptable performance.
> Point Set/Map
> -
>
> Key: GEOMETRY-142
> URL: https://issues.apache.org/jira/browse/GEOMETRY-142
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Assignee: Matt Juntunen
>Priority: Major
> Fix For: 1.1
>
>
> It would be very useful to have set and map implementations that accepts
> points and vectors as keys and use "fuzzy" look up logic, where values are
> compared using a precision context. This would have uses in a number of
> situations, including the implementation of GEOMETRY-110.
> Options for the implementation of such classes include
> * BSP trees (as already implemented)
> * k-d trees
> * quadtrees/octrees
> * r-trees
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEOMETRY-142) Point Set/Map
[
https://issues.apache.org/jira/browse/GEOMETRY-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17491588#comment-17491588
]
Matt Juntunen commented on GEOMETRY-142:
Thanks for the feedback, [~aherbert] and [~kinow]! I've reorganized things and
moved all of the factory methods to a {{EuclideanCollections}} class. (I used
that name instead of {{PointMaps}} so I can also put the {{PointSet}} factory
methods in there later on.) I've also created a draft PR for easier code
review: https://github.com/apache/commons-geometry/pull/193
> Point Set/Map
> -
>
> Key: GEOMETRY-142
> URL: https://issues.apache.org/jira/browse/GEOMETRY-142
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Assignee: Matt Juntunen
>Priority: Major
> Fix For: 1.1
>
>
> It would be very useful to have set and map implementations that accepts
> points and vectors as keys and use "fuzzy" look up logic, where values are
> compared using a precision context. This would have uses in a number of
> situations, including the implementation of GEOMETRY-110.
> Options for the implementation of such classes include
> * BSP trees (as already implemented)
> * k-d trees
> * quadtrees/octrees
> * r-trees
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEOMETRY-142) Point Set/Map
[
https://issues.apache.org/jira/browse/GEOMETRY-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17491454#comment-17491454
]
Matt Juntunen commented on GEOMETRY-142:
I just completed initial implementations of the {{PointMap}} interface for
Euclidean 1D, 2D, and 3D and pushed them to my working branch
(https://github.com/darkma773r/commons-geometry/tree/point-map). In order to
completely hide the implementation details, I created dimension-specific
interfaces with factory methods that return instances of a package-private
class. For example, this is how you create a 3D point map in the current code:
{code:java}
Precision.DoubleEquivalence precision =
Precision.doubleEquivalenceOfEpsilon(1e-6);
// PointMap3D is an interface; the returned instance is of the package-private
class PointMap3DImpl
PointMap3D map = PointMap3D.of(precision);
{code}
I'm not totally sure of this design. It seems kind of odd to have a factory
method on an interface and I feel like the factory method name "of" isn't quite
right. However, I know that the map implementation will most likely undergo
optimizations and so needs to isolated from the public API.
In terms of the implementations, the 1D point map uses a JDK {{TreeMap}}
internally while the 2D and 3D maps use a base class that implements the
quadtree/octree approach that was the winner of the algorithm performance tests.
Feedback is welcome. I'm picturing the next step to be implementing maps for
spherical 1D and 2D. I won't be able to use the same algorithms there as for
Euclidean. I'm thinking a modified {{TreeMap}} for 1D and a BSP-based data
structure for 2D.
> Point Set/Map
> -
>
> Key: GEOMETRY-142
> URL: https://issues.apache.org/jira/browse/GEOMETRY-142
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Assignee: Matt Juntunen
>Priority: Major
> Fix For: 1.1
>
>
> It would be very useful to have set and map implementations that accepts
> points and vectors as keys and use "fuzzy" look up logic, where values are
> compared using a precision context. This would have uses in a number of
> situations, including the implementation of GEOMETRY-110.
> Options for the implementation of such classes include
> * BSP trees (as already implemented)
> * k-d trees
> * quadtrees/octrees
> * r-trees
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEOMETRY-143) AngularInterval missclassify max boundary at 2pi- as outside
[
https://issues.apache.org/jira/browse/GEOMETRY-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Juntunen reassigned GEOMETRY-143:
--
Assignee: Matt Juntunen
> AngularInterval missclassify max boundary at 2pi- as outside
> -
>
> Key: GEOMETRY-143
> URL: https://issues.apache.org/jira/browse/GEOMETRY-143
> Project: Apache Commons Geometry
> Issue Type: Bug
> Components: Spherical 1D
>Reporter: Ron Goldman
>Assignee: Matt Juntunen
>Priority: Major
> Fix For: 1.1
>
> Attachments: patch
>
>
> When a AngularInterval has maxBoundary smaller than 2pi and equivalent to 2pi
> within precision, then the interval has false wrapZero but the upper boundary
> is classified by minBoundary as positive. as a result the point is classified
> as outside the interval instead of on the boundary.
> can be confirmed with the test:
> checkInterval(AngularInterval.of(6,Double.parseDouble("0x1.921fb54442c8ep2"),TEST_PRECISION),6,Double.parseDouble("0x1.921fb54442c8ep2"));
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEOMETRY-143) AngularInterval missclassify max boundary at 2pi- as outside
[
https://issues.apache.org/jira/browse/GEOMETRY-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Juntunen updated GEOMETRY-143:
---
Fix Version/s: 1.1
> AngularInterval missclassify max boundary at 2pi- as outside
> -
>
> Key: GEOMETRY-143
> URL: https://issues.apache.org/jira/browse/GEOMETRY-143
> Project: Apache Commons Geometry
> Issue Type: Bug
> Components: Spherical 1D
>Reporter: Ron Goldman
>Priority: Major
> Fix For: 1.1
>
> Attachments: patch
>
>
> When a AngularInterval has maxBoundary smaller than 2pi and equivalent to 2pi
> within precision, then the interval has false wrapZero but the upper boundary
> is classified by minBoundary as positive. as a result the point is classified
> as outside the interval instead of on the boundary.
> can be confirmed with the test:
> checkInterval(AngularInterval.of(6,Double.parseDouble("0x1.921fb54442c8ep2"),TEST_PRECISION),6,Double.parseDouble("0x1.921fb54442c8ep2"));
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEOMETRY-110) 3D Convex Hull
[ https://issues.apache.org/jira/browse/GEOMETRY-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Juntunen updated GEOMETRY-110: --- Fix Version/s: 1.1 > 3D Convex Hull > -- > > Key: GEOMETRY-110 > URL: https://issues.apache.org/jira/browse/GEOMETRY-110 > Project: Apache Commons Geometry > Issue Type: New Feature >Reporter: Matt Juntunen >Priority: Major > Fix For: 1.1 > > > We currently only have a 2D convex hull generator implementation. We should > add a 3D convex hull implementation, perhaps based on the > [Quickhull|https://en.wikipedia.org/wiki/Quickhull] algorithm. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEOMETRY-110) 3D Convex Hull
[ https://issues.apache.org/jira/browse/GEOMETRY-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Juntunen reassigned GEOMETRY-110: -- Assignee: Matt Juntunen > 3D Convex Hull > -- > > Key: GEOMETRY-110 > URL: https://issues.apache.org/jira/browse/GEOMETRY-110 > Project: Apache Commons Geometry > Issue Type: New Feature >Reporter: Matt Juntunen >Assignee: Matt Juntunen >Priority: Major > Fix For: 1.1 > > > We currently only have a 2D convex hull generator implementation. We should > add a 3D convex hull implementation, perhaps based on the > [Quickhull|https://en.wikipedia.org/wiki/Quickhull] algorithm. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEOMETRY-142) Point Set/Map
[ https://issues.apache.org/jira/browse/GEOMETRY-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Juntunen updated GEOMETRY-142: --- Fix Version/s: 1.1 > Point Set/Map > - > > Key: GEOMETRY-142 > URL: https://issues.apache.org/jira/browse/GEOMETRY-142 > Project: Apache Commons Geometry > Issue Type: New Feature >Reporter: Matt Juntunen >Assignee: Matt Juntunen >Priority: Major > Fix For: 1.1 > > > It would be very useful to have set and map implementations that accepts > points and vectors as keys and use "fuzzy" look up logic, where values are > compared using a precision context. This would have uses in a number of > situations, including the implementation of GEOMETRY-110. > Options for the implementation of such classes include > * BSP trees (as already implemented) > * k-d trees > * quadtrees/octrees > * r-trees -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEOMETRY-142) Point Set/Map
[ https://issues.apache.org/jira/browse/GEOMETRY-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Juntunen reassigned GEOMETRY-142: -- Assignee: Matt Juntunen > Point Set/Map > - > > Key: GEOMETRY-142 > URL: https://issues.apache.org/jira/browse/GEOMETRY-142 > Project: Apache Commons Geometry > Issue Type: New Feature >Reporter: Matt Juntunen >Assignee: Matt Juntunen >Priority: Major > > It would be very useful to have set and map implementations that accepts > points and vectors as keys and use "fuzzy" look up logic, where values are > compared using a precision context. This would have uses in a number of > situations, including the implementation of GEOMETRY-110. > Options for the implementation of such classes include > * BSP trees (as already implemented) > * k-d trees > * quadtrees/octrees > * r-trees -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEOMETRY-143) AngularInterval missclassify max boundary at 2pi- as outside
[
https://issues.apache.org/jira/browse/GEOMETRY-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17484236#comment-17484236
]
Matt Juntunen commented on GEOMETRY-143:
Merged in commit e13f15213d9dc46c96759d87660f8dbb05155811
> AngularInterval missclassify max boundary at 2pi- as outside
> -
>
> Key: GEOMETRY-143
> URL: https://issues.apache.org/jira/browse/GEOMETRY-143
> Project: Apache Commons Geometry
> Issue Type: Bug
> Components: Spherical 1D
>Reporter: Ron Goldman
>Priority: Major
> Attachments: patch
>
>
> When a AngularInterval has maxBoundary smaller than 2pi and equivalent to 2pi
> within precision, then the interval has false wrapZero but the upper boundary
> is classified by minBoundary as positive. as a result the point is classified
> as outside the interval instead of on the boundary.
> can be confirmed with the test:
> checkInterval(AngularInterval.of(6,Double.parseDouble("0x1.921fb54442c8ep2"),TEST_PRECISION),6,Double.parseDouble("0x1.921fb54442c8ep2"));
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEOMETRY-143) AngularInterval missclassify max boundary at 2pi- as outside
[
https://issues.apache.org/jira/browse/GEOMETRY-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Juntunen resolved GEOMETRY-143.
Resolution: Fixed
> AngularInterval missclassify max boundary at 2pi- as outside
> -
>
> Key: GEOMETRY-143
> URL: https://issues.apache.org/jira/browse/GEOMETRY-143
> Project: Apache Commons Geometry
> Issue Type: Bug
> Components: Spherical 1D
>Reporter: Ron Goldman
>Priority: Major
> Attachments: patch
>
>
> When a AngularInterval has maxBoundary smaller than 2pi and equivalent to 2pi
> within precision, then the interval has false wrapZero but the upper boundary
> is classified by minBoundary as positive. as a result the point is classified
> as outside the interval instead of on the boundary.
> can be confirmed with the test:
> checkInterval(AngularInterval.of(6,Double.parseDouble("0x1.921fb54442c8ep2"),TEST_PRECISION),6,Double.parseDouble("0x1.921fb54442c8ep2"));
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEOMETRY-143) AngularInterval missclassify max boundary at 2pi- as outside
[
https://issues.apache.org/jira/browse/GEOMETRY-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480670#comment-17480670
]
Matt Juntunen commented on GEOMETRY-143:
Sounds good. I'll wait a couple of days to see if anyone else has feedback and
then I'll go ahead and merge it.
> AngularInterval missclassify max boundary at 2pi- as outside
> -
>
> Key: GEOMETRY-143
> URL: https://issues.apache.org/jira/browse/GEOMETRY-143
> Project: Apache Commons Geometry
> Issue Type: Bug
> Components: Spherical 1D
>Reporter: Ron Goldman
>Priority: Major
> Attachments: patch
>
>
> When a AngularInterval has maxBoundary smaller than 2pi and equivalent to 2pi
> within precision, then the interval has false wrapZero but the upper boundary
> is classified by minBoundary as positive. as a result the point is classified
> as outside the interval instead of on the boundary.
> can be confirmed with the test:
> checkInterval(AngularInterval.of(6,Double.parseDouble("0x1.921fb54442c8ep2"),TEST_PRECISION),6,Double.parseDouble("0x1.921fb54442c8ep2"));
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEOMETRY-142) Point Set/Map
[ https://issues.apache.org/jira/browse/GEOMETRY-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480558#comment-17480558 ] Matt Juntunen commented on GEOMETRY-142: Cool. Thanks, [~kinow]! > Point Set/Map > - > > Key: GEOMETRY-142 > URL: https://issues.apache.org/jira/browse/GEOMETRY-142 > Project: Apache Commons Geometry > Issue Type: New Feature >Reporter: Matt Juntunen >Priority: Major > > It would be very useful to have set and map implementations that accepts > points and vectors as keys and use "fuzzy" look up logic, where values are > compared using a precision context. This would have uses in a number of > situations, including the implementation of GEOMETRY-110. > Options for the implementation of such classes include > * BSP trees (as already implemented) > * k-d trees > * quadtrees/octrees > * r-trees -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEOMETRY-143) AngularInterval missclassify max boundary at 2pi- as outside
[
https://issues.apache.org/jira/browse/GEOMETRY-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480557#comment-17480557
]
Matt Juntunen commented on GEOMETRY-143:
I've created a PR for this: https://github.com/apache/commons-geometry/pull/192
The main change is to define and document a set of rules for how to classify
points in {{CutAngle}} when the cut angle, the test point, or both lie very
close to zero. I also added a method in {{Point1S}} named {{eqZero}} for
checking if a point is equivalent to zero. This is functionally the same as the
calling the existing {{eq}} method with {{Point1S.ZERO}} but I realized that we
did not need to perform any floating point operations (other than a comparison)
when checking against zero. I originally had this special case as a private
method in {{CutAngle}} but thought it would be useful to have in the public API.
[~rongoldman], this PR is a superset of the changes you had in your patch. I've
included your test case in the PR. Please review and let me know what you think.
> AngularInterval missclassify max boundary at 2pi- as outside
> -
>
> Key: GEOMETRY-143
> URL: https://issues.apache.org/jira/browse/GEOMETRY-143
> Project: Apache Commons Geometry
> Issue Type: Bug
> Components: Spherical 1D
>Reporter: Ron Goldman
>Priority: Major
> Attachments: patch
>
>
> When a AngularInterval has maxBoundary smaller than 2pi and equivalent to 2pi
> within precision, then the interval has false wrapZero but the upper boundary
> is classified by minBoundary as positive. as a result the point is classified
> as outside the interval instead of on the boundary.
> can be confirmed with the test:
> checkInterval(AngularInterval.of(6,Double.parseDouble("0x1.921fb54442c8ep2"),TEST_PRECISION),6,Double.parseDouble("0x1.921fb54442c8ep2"));
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEOMETRY-143) AngularInterval missclassify max boundary at 2pi- as outside
[
https://issues.apache.org/jira/browse/GEOMETRY-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480422#comment-17480422
]
Matt Juntunen commented on GEOMETRY-143:
I've been looking at this for the past couple of days and I believe the issue
is deeper than just this one case. The behavior of {{CutAngle.classify}} is not
well defined in general with input values close to zero. I'm using the
submitted patch as a starting point, adding additional unit tests, and trying
to settle on an implementation. I hope to have a PR ready for review soon.
> AngularInterval missclassify max boundary at 2pi- as outside
> -
>
> Key: GEOMETRY-143
> URL: https://issues.apache.org/jira/browse/GEOMETRY-143
> Project: Apache Commons Geometry
> Issue Type: Bug
> Components: Spherical 1D
>Reporter: Ron Goldman
>Priority: Major
> Attachments: patch
>
>
> When a AngularInterval has maxBoundary smaller than 2pi and equivalent to 2pi
> within precision, then the interval has false wrapZero but the upper boundary
> is classified by minBoundary as positive. as a result the point is classified
> as outside the interval instead of on the boundary.
> can be confirmed with the test:
> checkInterval(AngularInterval.of(6,Double.parseDouble("0x1.921fb54442c8ep2"),TEST_PRECISION),6,Double.parseDouble("0x1.921fb54442c8ep2"));
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEOMETRY-142) Point Set/Map
[
https://issues.apache.org/jira/browse/GEOMETRY-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17477344#comment-17477344
]
Matt Juntunen commented on GEOMETRY-142:
I tried a few more optimizations and it looks like {{varoctree}} is still the
best algorithm, especially since I improved the {{remove}} performance. The
final results are below.
||Benchmark||(dist)||(impl)||(randomSeed)||(shape)||Mode||Cnt||Score||Error||Units||
|get|random|treemap|1|teapot|avgt|5|8201248.381|± 885353.659|ns/op|
|get|random|varoctree|1|teapot|avgt|5|9954012.963|± 1467457.747|ns/op|
|get|random|kdtree|1|teapot|avgt|5|12047536.590|± 3986439.960|ns/op|
|get|random|rebuilding-kdtree|1|teapot|avgt|5|11241847.287|± 4950094.941|ns/op|
|get|random|bucket-kdtree|1|teapot|avgt|5|14269957.001|± 2984764.586|ns/op|
|get|random|bucket-leaf-kdtree|1|teapot|avgt|5|12613411.642|± 1912904.807|ns/op|
|put|random|treemap|1|teapot|avgt|5|4466342.881|± 829095.368|ns/op|
|put|random|varoctree|1|teapot|avgt|5|6498643.402|± 1110163.867|ns/op|
|put|random|kdtree|1|teapot|avgt|5|7788556.065|± 1568465.224|ns/op|
|put|random|rebuilding-kdtree|1|teapot|avgt|5|6924748.449|± 1312331.439|ns/op|
|put|random|bucket-kdtree|1|teapot|avgt|5|8580674.695|± 3265464.066|ns/op|
|put|random|bucket-leaf-kdtree|1|teapot|avgt|5|6440019.212|± 3284091.562|ns/op|
|remove|random|treemap|1|teapot|avgt|5|160111.447|± 14035.741|ns/op|
|remove|random|varoctree|1|teapot|avgt|5|191145.633|± 45804.812|ns/op|
|remove|random|kdtree|1|teapot|avgt|5|164994.365|± 78422.804|ns/op|
|remove|random|rebuilding-kdtree|1|teapot|avgt|5|197497.579|± 86483.448|ns/op|
|remove|random|bucket-kdtree|1|teapot|avgt|5|226619.480|± 69024.069|ns/op|
|remove|random|bucket-leaf-kdtree|1|teapot|avgt|5|188944.887|±
84743.239|ns/op|
Unless there are any objections or additional ideas, I'm going to start working
on {{PointMap}} implementations for Euclidean 2D and 3D based on this algorithm.
> Point Set/Map
> -
>
> Key: GEOMETRY-142
> URL: https://issues.apache.org/jira/browse/GEOMETRY-142
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
>
> It would be very useful to have set and map implementations that accepts
> points and vectors as keys and use "fuzzy" look up logic, where values are
> compared using a precision context. This would have uses in a number of
> situations, including the implementation of GEOMETRY-110.
> Options for the implementation of such classes include
> * BSP trees (as already implemented)
> * k-d trees
> * quadtrees/octrees
> * r-trees
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEOMETRY-143) AngularInterval missclassify max boundary at 2pi- as outside
[
https://issues.apache.org/jira/browse/GEOMETRY-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17477338#comment-17477338
]
Matt Juntunen commented on GEOMETRY-143:
bq. There is a patch attached to this report.
Ha! Totally missed that :-) It looks simple enough. I'd like to take a closer
look before merging it in. I should have time within the next few days for
that.
> AngularInterval missclassify max boundary at 2pi- as outside
> -
>
> Key: GEOMETRY-143
> URL: https://issues.apache.org/jira/browse/GEOMETRY-143
> Project: Apache Commons Geometry
> Issue Type: Bug
> Components: Spherical 1D
>Reporter: Ron Goldman
>Priority: Major
> Attachments: patch
>
>
> When a AngularInterval has maxBoundary smaller than 2pi and equivalent to 2pi
> within precision, then the interval has false wrapZero but the upper boundary
> is classified by minBoundary as positive. as a result the point is classified
> as outside the interval instead of on the boundary.
> can be confirmed with the test:
> checkInterval(AngularInterval.of(6,Double.parseDouble("0x1.921fb54442c8ep2"),TEST_PRECISION),6,Double.parseDouble("0x1.921fb54442c8ep2"));
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEOMETRY-143) AngularInterval missclassify max boundary at 2pi- as outside
[
https://issues.apache.org/jira/browse/GEOMETRY-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17477208#comment-17477208
]
Matt Juntunen commented on GEOMETRY-143:
Hello! Thank you for the bug report! I may not have time to take a close look
at this for a few days. If you find a fix in the meantime, feel free to submit
a PR on github.
> AngularInterval missclassify max boundary at 2pi- as outside
> -
>
> Key: GEOMETRY-143
> URL: https://issues.apache.org/jira/browse/GEOMETRY-143
> Project: Apache Commons Geometry
> Issue Type: Bug
> Components: Spherical 1D
>Reporter: Ron Goldman
>Priority: Major
> Attachments: patch
>
>
> When a AngularInterval has maxBoundary smaller than 2pi and equivalent to 2pi
> within precision, then the interval has false wrapZero but the upper boundary
> is classified by minBoundary as positive. as a result the point is classified
> as outside the interval instead of on the boundary.
> can be confirmed with the test:
> checkInterval(AngularInterval.of(6,Double.parseDouble("0x1.921fb54442c8ep2"),TEST_PRECISION),6,Double.parseDouble("0x1.921fb54442c8ep2"));
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEOMETRY-142) Point Set/Map
[
https://issues.apache.org/jira/browse/GEOMETRY-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17467761#comment-17467761
]
Matt Juntunen commented on GEOMETRY-142:
I've added another implementation named {{BucketKDTree}} that stores single
entries in splitting nodes as well as in leaf nodes as lists. However, the
performance is worse than the other implementations. The best implementation
for {{get}} and {{put}} performance is {{varoctree}}, although it does terribly
with {{remove}}. I think the next step is to explore {{varoctree}} a bit more
and see if this can be improved.
||Benchmark||(impl)||(pointDist)||(randomSeed)||(randomized)||Mode||Cnt||Score||Error||Units||
|PointMapDataStructurePerformance.get|treemap|block|1|true|avgt|5|2535086.177|±
196957.459|ns/op|
|PointMapDataStructurePerformance.get|varoctree|block|1|true|avgt|5|3835217.249|±
106874.863|ns/op|
|PointMapDataStructurePerformance.get|kdtree|block|1|true|avgt|5|5918314.090|±
433275.740|ns/op|
|PointMapDataStructurePerformance.get|rebuilding-kdtree|block|1|true|avgt|5|5046805.168|±
397529.992|ns/op|
|PointMapDataStructurePerformance.get|bucket-kdtree|block|1|true|avgt|5|6028908.768|±
598811.980|ns/op|
|PointMapDataStructurePerformance.put|treemap|block|1|true|avgt|5|1543477.168|±
59915.220|ns/op|
|PointMapDataStructurePerformance.put|varoctree|block|1|true|avgt|5|1721624.355|±
31012.494|ns/op|
|PointMapDataStructurePerformance.put|kdtree|block|1|true|avgt|5|7977304.891|±
122840.849|ns/op|
|PointMapDataStructurePerformance.put|rebuilding-kdtree|block|1|true|avgt|5|5687657.624|±
132680.481|ns/op|
|PointMapDataStructurePerformance.put|bucket-kdtree|block|1|true|avgt|5|76366216.557|±
964906.841|ns/op|
|PointMapDataStructurePerformance.remove|treemap|block|1|true|avgt|5|54016.786|±
22942.461|ns/op|
|PointMapDataStructurePerformance.remove|varoctree|block|1|true|avgt|5|1513340.914|±
40069.462|ns/op|
|PointMapDataStructurePerformance.remove|kdtree|block|1|true|avgt|5|61120.730|±
11036.797|ns/op|
|PointMapDataStructurePerformance.remove|rebuilding-kdtree|block|1|true|avgt|5|79552.232|±
10029.806|ns/op|
|PointMapDataStructurePerformance.remove|bucket-kdtree|block|1|true|avgt|5|91491.103|±
14820.207|ns/op|
> Point Set/Map
> -
>
> Key: GEOMETRY-142
> URL: https://issues.apache.org/jira/browse/GEOMETRY-142
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
>
> It would be very useful to have set and map implementations that accepts
> points and vectors as keys and use "fuzzy" look up logic, where values are
> compared using a precision context. This would have uses in a number of
> situations, including the implementation of GEOMETRY-110.
> Options for the implementation of such classes include
> * BSP trees (as already implemented)
> * k-d trees
> * quadtrees/octrees
> * r-trees
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
