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-11) Replace tolerance with GeometryContext
Date Fri, 21 Dec 2018 12:43:00 GMT

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

Matt Juntunen commented on GEOMETRY-11:
---------------------------------------

I'm thinking of taking the general approach described at the end of this article: [https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/.|https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/]
Basically, we'll use absolute epsilon comparisons first followed by maxUlp comparisons to
compare two numbers. The {{Precision}} class already has both of the capabilities so this
will basically just be wrapping those functions with a class that stores the epsilon and maxUlp
values. This is more related to general floating point math than geometry, so I think we should
put this class in commons-numbers-core. The name could be something like {{DoublePrecision}}.
We could then use this class directly in commons-geometry and add a {{getDefaultPrecision}}
method to the {{Geometry}} class to return an instance designed to work well in the majority
of cases. I'm not sure what those default values would be exactly, though. Any input on that
would be great.

> Replace tolerance with GeometryContext
> --------------------------------------
>
>                 Key: GEOMETRY-11
>                 URL: https://issues.apache.org/jira/browse/GEOMETRY-11
>             Project: Apache Commons Geometry
>          Issue Type: Wish
>            Reporter: Matt Juntunen
>            Priority: Major
>             Fix For: 1.0
>
>
> All of the partitioning-related concrete classes (ex: Plane, PolygonsSet, PolyhedronsSet,
etc) use a double value named tolerance in order to address issues with floating point accuracy.
For example, when determining if a point lies in a plane, the point does not need to lie exactly
on the plane but just be within +- tolerance distance from it. Code testing values against
each other using this toleranceĀ isĀ repeated throughout the code base (ex: x >= y - tolerance).
We should abstract the concept of the tolerance into a GeometryContext class and provide methods
for testing values against each other using the tolerance. This will reduce the chance of
bugs and will also allow for more sophisticated handling of floating point accuracy later
on.
> The GeometryContext class would be similar to the MathContext class used by BigDecimal
but would contain the logic for making comparisons in addition to the configuration for the
comparisons.
> {code:java}
> public class GeometryContext {
>    public GeometryContext(tolerance){...}
>    public double getTolerance(){ ... }
>    // return -1, 0, +1
>    public int compare(double a, double b) { ... }
> }{code}



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

Mime
View raw message