sis-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Charles Karney (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SIS-386) Deprecate DefaultEllipsoid.orthodromicDistance(…) method
Date Sat, 20 Jan 2018 17:47:00 GMT

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

Charles Karney commented on SIS-386:
------------------------------------

Thanks for pointing out that {{GeographicLib-Java}} already requires Java version 1.6.  The
next version will remove {{epsilon}}, {{min}}, {{hypot}}, {{log1p}}, {{copysign}}, and {{cbrt}}
from the {{GeoMath}} class.

Almost certainly, it's OK in practice to just use {{sin}} and {{cos}} functions directly.
 I would worry with long doubles (with a 64-bit fraction), since then {{sin(pi) < 0}}.
 But with doubles {{sin(pi) > 0}}.

Also, almost certainly, it's OK to use ordinary summation instead of my Accumulator class.
 I use Accumulator to sum the (canceling) contributions to the area of a polygon.  However,
I'm not sure this gains much in practice.

I do have a bone to pick with you about {{DoubleAccumulator}} (or {{DoubleAdder}}).  The following
code
{code:java}
  Accumulator a = new Accumulator(0.0);
  a.Add(5.0);
  a.Add(1e-20);
  a.Add(2e-20);
  a.Add(-3.0);
  a.Add(-2.0);
  DoubleAccumulator b = new DoubleAccumulator((x, y) -> x + y, 0.0);
  b.accumulate(5.0);
  b.accumulate(1e-20);
  b.accumulate(2e-20);
  b.accumulate(-3.0);
  b.accumulate(-2.0);
  System.out.println(a.Sum() + " " + b.get());
{code}
prints out {{3.0e-20 0.0}}.  So evidently DoubleAccumulator (unlike Accumulator) isn't doing
anything other than ordinary (1-double) addition.


> Deprecate DefaultEllipsoid.orthodromicDistance(…) method
> --------------------------------------------------------
>
>                 Key: SIS-386
>                 URL: https://issues.apache.org/jira/browse/SIS-386
>             Project: Spatial Information Systems
>          Issue Type: Bug
>          Components: Referencing
>    Affects Versions: 0.4, 0.5, 0.6, 0.7, 0.8
>            Reporter: Martin Desruisseaux
>            Priority: Major
>             Fix For: 1.0
>
>
> The {{DefaultEllipsoid.orthodromicDistance}} method has the following problems:
> * Could have a better name.
> * It does not converge in some situations.
> * The wraparound over some non-convergence problems is itself erroneous.
> Charles Karney kindly listed the problems [on the developer mailing list|https://lists.apache.org/thread.html/eee29fc53123e94b74c22737413b2572d3e4c9e4f111847fefb6a3af@%3Cdev.sis.apache.org%3E].
A possible action would be to deprecate {{orthodromicDistance}}, to be replaced by the same
{{GeodeticCalculator}} (or any other name) class than the one proposed for SIS-385.
> *Historical note:* {{orthodromicDistance}} was defined in the {{DefaultEllipsoid}} class
because it made easy to override the method with code optimized for the spherical case. A
future version could also override the method with code for triaxial ellipsoid. But experience
in the Geotk project suggest that this method is almost never used, since {{GeodeticCalculator}}
is used instead.
> As an alternative to deprecate {{DefaultEllipsoid.orthodromicDistance}}, we could keep
it (after renaming), fix the issues identified by Charles, and design {{GeodeticCalculator}}
as a class that use {{DefaultEllipsoid}} under the hood instead than re-implementing its own
algorithm.



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

Mime
View raw message