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

[Philip Nienhuis]

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

Hmm, post cut off. Try #2

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/