[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Octave-patch-tracker] [patch #8827] mapping package: new functions wrap
From: |
Philip Nienhuis |
Subject: |
[Octave-patch-tracker] [patch #8827] mapping package: new functions wrapTo 360, 2Pi, 180, Pi |
Date: |
Tue, 29 Dec 2015 14:05:01 +0000 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0 SeaMonkey/2.38 |
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/
- [Octave-patch-tracker] [patch #8827] mapping package: new functions wrapTo 360, 2Pi, 180, Pi, (continued)
- [Octave-patch-tracker] [patch #8827] mapping package: new functions wrapTo 360, 2Pi, 180, Pi, Philip Nienhuis, 2015/12/22
- [Octave-patch-tracker] [patch #8827] mapping package: new functions wrapTo 360, 2Pi, 180, Pi, Philip Nienhuis, 2015/12/24
- [Octave-patch-tracker] [patch #8827] mapping package: new functions wrapTo 360, 2Pi, 180, Pi, Andreas Weber, 2015/12/24
- [Octave-patch-tracker] [patch #8827] mapping package: new functions wrapTo 360, 2Pi, 180, Pi, CarnĂ« Draug, 2015/12/24
- [Octave-patch-tracker] [patch #8827] mapping package: new functions wrapTo 360, 2Pi, 180, Pi, Philip Nienhuis, 2015/12/24
- [Octave-patch-tracker] [patch #8827] mapping package: new functions wrapTo 360, 2Pi, 180, Pi, Philip Nienhuis, 2015/12/24
- [Octave-patch-tracker] [patch #8827] mapping package: new functions wrapTo 360, 2Pi, 180, Pi, Philip Nienhuis, 2015/12/25
- [Octave-patch-tracker] [patch #8827] mapping package: new functions wrapTo 360, 2Pi, 180, Pi, anonymous, 2015/12/28
- [Octave-patch-tracker] [patch #8827] mapping package: new functions wrapTo 360, 2Pi, 180, Pi, Philip Nienhuis, 2015/12/28
- [Octave-patch-tracker] [patch #8827] mapping package: new functions wrapTo 360, 2Pi, 180, Pi, anonymous, 2015/12/28
- [Octave-patch-tracker] [patch #8827] mapping package: new functions wrapTo 360, 2Pi, 180, Pi,
Philip Nienhuis <=
- [Octave-patch-tracker] [patch #8827] mapping package: new functions wrapTo 360, 2Pi, 180, Pi, Philip Nienhuis, 2015/12/29
- [Octave-patch-tracker] [patch #8827] mapping package: new functions wrapTo 360, 2Pi, 180, Pi, Philip Nienhuis, 2015/12/29