c: fix "a", revert to 2-iter exact#55
Conversation
Commits cd7a6a4 killed the 2-iter exact algo. This commit brings it back.
adclose
left a comment
adclose
left a comment
There was a problem hiding this comment.
Changes are all non-breaking. and should provide a significant improvement in performance.
c/transform.c
Outdated
|
|
||
| void transform(double x, double y, double *lat, double *lng) { | ||
| double xy = x * y; | ||
| double absX = sqrt(fabs(x)); |
There was a problem hiding this comment.
better name for this should be sqrtX not absX
c/transform.c
Outdated
| pLng = gcjLng + dLng; | ||
| double dLat, dLng; | ||
| // n_iter=2: centimeter precision, n_iter=5: double precision | ||
| const int n_iter = 2; |
There was a problem hiding this comment.
If your going to drop the threshold check I suggest 3 or 4 iterations not just 2 as my tests showed that to get to the right precision most times, I iterated 3 times.
| delta(*wgsLat, *wgsLng, &dLat, &dLng); | ||
| *wgsLat = gcjLat - dLat; | ||
| *wgsLng = gcjLng - dLng; | ||
| } |
There was a problem hiding this comment.
The I'm glad to see this method changed as it's so much faster.
There was a problem hiding this comment.
Side note... It would be really nice to see consistency between versions and variable names. X_Pi,xPi,yPi,MPi.....
and consistent definitions across implementations mPi = 3000Pi/180; xPi = xmPi for example..
exact transform implemented via cajun method everywhere... or left as half distance method, and mars2wgs as cajin. Just so long as it's all consistent.
There was a problem hiding this comment.
The C impl is actually the first instance where a caijun-esque method is introduced to eviltransform. Like I said in the PR, it's ditched in an "optimize" commit, the only productive part of which is fixing a "fabs" declaraction.
There was a problem hiding this comment.
And yeah the whole varname thing is crazy. We probably don't even need all those, as many of them like x*pi and sqrt(fabs(x)) are really subexpression optimizations that can be done automatically by the compiler as long as you allow it to do associative math on floats.
Yeah, right, good call -- let me think really hard about putting some pragmas to tell the compilers…
There was a problem hiding this comment.
I like defining subexpressions or constants that otherwise would be recalculated multiple times later , to limit the clock cycles needed for repetitive calculations. I just like to see consistent naming.
Quite frankly I would like to see these all dealt with in some -fassociative-math pragma
2 participants
Commits cd7a6a4 killed the 2-iter exact algo. This commit brings it back.