[ 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)