[GitHub] [solr] danrosher commented on pull request #940: SOLR-16292 : NVector for alternative great-circle distance calculations

[GitBox <gi...@apache.org>]

danrosher commented on PR #940:
URL: https://github.com/apache/solr/pull/940#issuecomment-1191522782

   Thanks for looking into this more @madrob . 
   
   I wasn't aware of SloppyMath. If we assume Math.acos correct, then to get the same accuracy with FastInvTrig to within 40cm, I've tested it takes 17 terms, which after running a benchmark means that:
   
   ```
   Benchmark                                   (num_points)  Mode  Cnt    Score   Error  Units
   FastInvTrigBenchmark.acosBM10                    2000000  avgt    2   44.149          ms/op
   FastInvTrigBenchmark.acosBM17                    2000000  avgt    2   67.977          ms/op
   FastInvTrigBenchmark.fastMathAcosBM              2000000  avgt    2  252.578          ms/op
   FastInvTrigBenchmark.haversineBM                 2000000  avgt    2  288.209          ms/op
   FastInvTrigBenchmark.mathAcosBM                  2000000  avgt    2  300.509          ms/op
   FastInvTrigBenchmark.mathAsin                    2000000  avgt    2  320.407          ms/op
   FastInvTrigBenchmark.sloppyAsin                  2000000  avgt    2   50.152          ms/op
   FastInvTrigBenchmark.sloppyHaversinMeters        2000000  avgt    2  134.309          ms/op
   FastInvTrigBenchmark.sloppyHaversinSortKey       2000000  avgt    2   82.845          ms/op
   ```
   So then:
   
   SloppyMath.HaversinSortKey is 1.9x slower than FastInvTrig with 10 terms  (as you found)
   SloppyMath.HaversinSortKey is 1.2x slower than FastInvTrig with 17 terms
   
   However I also noticed that SloppyMath has an asin implementation, and with pi/2-asin(x) = acos(x)
   
   https://www.wolframalpha.com/input?i2d=true&i=%5C%2840%29Divide%5Bpi%2C2%5D-asin%5C%2840%29x%5C%2841%29%5C%2841%29-acos%5C%2840%29x%5C%2841%29
   
   after adding this into the benchmark, using nvector and this identity ^  for acos then:
   
   FastInvTrig with 17 terms is 1.3x slower than SloppyMath.asin !
   
   The caveat is that SloppyMath.asin uses more memory for caching values I think.
   
   So I'm wondering now whether to abandon the FastInvTrig series expansion, and use SloppyMath.asin for NVector? What do you think ?
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org