[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #48774] Functions for moving statistics

From: Rik
Subject: [Octave-bug-tracker] [bug #48774] Functions for moving statistics
Date: Fri, 21 Dec 2018 11:33:51 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Linux i586; rv:31.0) Gecko/20100101 Firefox/31.0

Follow-up Comment #31, bug #48774 (project octave):

@Juan: I find that is very hard to speculate about performance and that one is
usually wrong.  The only way to be certain is to benchmark the two
alternatives.  I have been testing with a matrix that I created with randi
(1e3, 1000, 1000) and then saved to a file so the results are reproducible. 
Here is an example benchmark which shows that "discard" is currently the very
fastest of the endpoint options.

octave:1> load movmin.var
octave:2> tic; y = movfun (@mean, x, 51, "Endpoints", "shrink"); toc
Elapsed time is 6.17102 seconds.
octave:3> tic; y = movfun (@mean, x, 51, "Endpoints", "shrink"); toc
Elapsed time is 6.07471 seconds.
octave:4> tic; y = movfun (@mean, x, 51, "Endpoints", "fill"); toc
Elapsed time is 0.600617 seconds.
octave:5> tic; y = movfun (@mean, x, 51, "Endpoints", "fill"); toc
Elapsed time is 0.628939 seconds.
octave:6> tic; y = movfun (@mean, x, 51, "Endpoints", "discard"); toc
Elapsed time is 0.25172 seconds.
octave:7> tic; y = movfun (@mean, x, 51, "Endpoints", "discard"); toc
Elapsed time is 0.268769 seconds.

I would set up your own dataset and then check the timing pre/post-conversion
to a dispatch structure.

Regarding copyright, I don't believe using a single line, in this case the
call to movfun, qualifies the entire file as a derivative work.  Particularly,
as there is only one real way to call the movfun function.  But, I'm not a
lawyer so I think we need to get the advice of the Free Software Foundation. 
I would have you ask jwe on how to proceed.

The author and creation date fields were more useful when we had primitive
version control systems, or none at all.  Now, the author and modification
date of every change is captured by Mercurial, including the original file
creation, and these are less necessary.  I occasionally remove them when I
come across them, but I haven't done a full purge.

Regarding __parser_movargs__, I think it depends on whether any further movXXX
functions will be added.  I anticipated that there might be more, and so I
placed __parser_movargs__.m together with movslice.m and movfun.m.  If there
will only ever be statistics versions of sliding window functions then it can
be made a private function in the statistics/ directory. 


Reply to this item at:


  Message sent via Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]