[Top][All Lists]

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

Re: movXXX performance

From: Carnë Draug
Subject: Re: movXXX performance
Date: Mon, 7 Jan 2019 00:29:39 +0000

On Fri, 4 Jan 2019 at 18:25, Rik <address@hidden> wrote:
> On Fri, 4 Jan 2019 at 03:01 AM, Michael Leitner wrote:
>> [...] if this movfun is not intended to be called with arbitrary
>> user-supplied functions, but only with mean, median, std, sum, var,
>> max, min to provide the mov*-functions introduced in Matlab R2016a
>> (the first two comments in
>> https://blogs.mathworks.com/loren/2016/04/15/moving-along/ seem to
>> imply that Matlab does not provide movfun), then I would change the
>> architecture of movfun to do a common preprocessing, but then a
>> switch-statement, [...]
> [...]
> Thanks for looking at this so carefully.  movfun is an
> Octave-specific enhancement over Matlab intended to apply to any
> user function.  As such, I prefer not to introduce a large switch
> statement decoding which of many possible functions called it
> (movmax, movmin, movmad, ...).

We had the same thing in the image package with spacial filters, there
was one function that did them all.  But with time we have now been
writing them all again with algorithms better adjusted.

Makes sense to not have movfun full of switch statements for
specialised cases.  But if there's functions for such specialised
cases, such as movmean, they can have their own specialised algorithm
instead of relying on movfun which only solves it with the naive

Common code can go into multiple private functions which the multiple
mov* functions can call instead of a single movfun full of branches
that does all the work for all the cases.

reply via email to

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