[Octave-patch-tracker] [patch #8827] mapping package: new functions wrapTo 360, 2Pi, 180, Pi

[Philip Nienhuis]

Follow-up Comment #19, patch #8827 (project octave):

@Oscar:
(a somewhat long post, but I am very grateful for your continued interest and
perseverance)

My wrapTo180 is correct, but the devil is in the details. From the test
suite:

>> c = [-721.1, -718.9, -481.3, -479.99, -361, -359, -200, -180-(1e-14), -180,
...
     -180-(2e-14), -160, -eps, 0, eps, 160, 180, 180+(1e-14), 180+(2e-14),
200];
c =
 Columns 1 through 6:
  -721.10000  -718.90000  -481.30000  -479.99000  -361.00000  -359.00000
 Columns 7 through 12:
  -200.00000  -180.00000  -180.00000  -180.00000  -160.00000    -0.00000
 Columns 13 through 18:
     0.00000     0.00000   160.00000   180.00000   180.00000   180.00000
 Column 19:
   200.00000
>> [c; wrapTo180(c)]
ans =
 Columns 1 through 6:
  -721.10000  -718.90000  -481.30000  -479.99000  -361.00000  -359.00000
    -1.10000     1.10000  -121.30000  -119.99000    -1.00000     1.00000
 Columns 7 through 12:
  -200.00000  -180.00000  -180.00000  -180.00000  -160.00000    -0.00000
   160.00000  -180.00000  -180.00000   180.00000  -160.00000    -0.00000
 Columns 13 through 18:
     0.00000     0.00000   160.00000   180.00000   180.00000   180.00000
     0.00000     0.00000   160.00000   180.00000   180.00000  -180.00000
 Column 19:
   200.00000
  -160.00000


Entry 18 *looks* wrong, but as you can see in the definition of "c", it is
deliberately set to a value just a tiny little bit over the numerical accuracy
treshold > 180. You don't see that due to rounding in the output.
FYI, the treshold (numerical accuracy) is outlined in comment #13, for values
near 180 and -180 it amounts to ~1e-14. The 18th entry of "c" is 180+2e-14 so
is larger => should wrap around.
Similarly for entry #10 (-180-2e-14).
Your version apparently doesn't pick up that tiny difference.

I think I'll use my versions, my motives are as follows (comments welcome
nevertheless), in decreasing order of importance:

1. Code should be correct - in this case "Matlab-correct" and I do think
there's a fair case for Matlab's peculiar interval end point behavior;

2. Code should be maintainable;

3. Code should be fast.

(yeah the order of 2. and 3. leave room for discussion :-) )

As to 1:
After a fair bit of experimenting and thinking over I do not see how to
reliably obtain Matlab's end point behavior in a symmetrical way without a
statement containing "abs(x) > {positive_endpoint}" plus some call to sign(),
so that the entire interval incl. endpoints is not affected (wrapped).

As to 2: 
I find my own code a tiny little easier to follow than your code :-) but it is
entirely possible that my perception will wear out over time. I therefore
leave your contributions here with a "postponed" until some later mapping
package release so that it can be further polished.

As to 3:
I had no idea of performance of either set of versions so I tried:

## Get 10^8 random numbers evenly distributed in [-1 1]
>> testarr = 2 * (rand (10000) - 0.5);
## Transform to [-3*pi .. 3*pi]
>> c = 3 * pi * testarr;
>> mean (c(:))
ans =  -6.9368e-004
>> max (c(:))
ans =  9.4248
>> min (c(:))
ans = -9.4248
>> numel (find (c < 0))
ans =  50006525
>> numel (find (c > 0))
ans =  49993475
>> 2 * mean (c(find (c > 0)))
ans =  9.4250
>> 2 * mean (c(find (c < 0)))
ans = -9.4251
-verbatim+

... so the results appear to be evenly distributed in [-3*pi .. 3*pi].

Then, with my wrapTo2Pi.m version:

>> tic; wrapTo2Pi (c); toc
Elapsed time is 6.84839 seconds.
>> tic; wrapTo2Pi (c); toc
Elapsed time is 6.9144 seconds.
>> tic; wrapTo2Pi (c); toc
Elapsed time is 6.86239 seconds.
-verbatim+

and with yours:

>> tic; wrapTo2Pi (c); toc
Elapsed time is 9.71456 seconds.
>> tic; wrapTo2Pi (c); toc
Elapsed time is 9.68055 seconds.
>> tic; wrapTo2Pi (c); toc
Elapsed time is 9.68155 seconds.


and as your wrapTo2Pi is called by your other wrapTo... functions I suppose
those must be slower still due to function call overhead.


Early next year I'll push my versions to the repo, maybe after a little more
polishing. 
FYI I'm still busy with GIS raster file I/O + speeding up .shp file drawing
(esp. filled polygons), one that works sufficiently reliably I'll make a new
release. Once there I'll set status to "postponed".


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/patch/?8827>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/