commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Juntunen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (GEOMETRY-29) Plane API cleanup
Date Wed, 13 Mar 2019 15:55:00 GMT

    [ https://issues.apache.org/jira/browse/GEOMETRY-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16791829#comment-16791829
] 

Matt Juntunen commented on GEOMETRY-29:
---------------------------------------

{quote}I don't see the use cases for hashCode and equals for values based on doubles.
{quote}
I agree that in many situations fuzzy comparison of doubles is preferred, but I don't think
that means we should not implement these methods. A situation where I might rely on these
methods is when reuniting split subhyperplanes in order to generate the boundary of a BSP
tree. Each subhyperplane has a hyperplane that embeds it, and there may be many subhyperplanes
in the tree with exactly equal hyperplanes. In this case, I would actually use the hyperplanes
as keys in a map in order to find all subhyperplanes that lie in the same hyperplane.

 

In regard to fuzzy comparisons, the {{Vector?D}} classes allow this functionality through
an overloaded {{equals}} method that takes a {{DoublePrecisionContext}}. We have not implemented
this in any of the hyperplane classes since it hasn't seemed to be needed at this point. It's
also a bit complicated by the fact that the hyperplane classes include their own {{DoublePrecisionContext}}
so there isn't an immediately obvious method overload opportunity, not to mention the issue
of which hyperplane's precision context to use when performing the comparison.

> Plane API cleanup
> -----------------
>
>                 Key: GEOMETRY-29
>                 URL: https://issues.apache.org/jira/browse/GEOMETRY-29
>             Project: Apache Commons Geometry
>          Issue Type: Improvement
>            Reporter: Matt Juntunen
>            Priority: Major
>
> The following changes should be made to the {{o.a.c.g.euclidean.threed.Plane}} class:
>  * make the class immutable
>  * use well-named factory methods instead of constructor overloads
>  * provide a factory method to create a plane with user-supplied {{u}} and {{v}} axes.
The current implementation allows the normal to be provided but chooses its own planar axes
(see {{setFrame}}).
>  * add {{equals}}, {{hashCode}}, and {{toString}} methods.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message