Re: reduction funs optimizations + min/max question

[Jaroslav Hajek]

On Tue, Feb 17, 2009 at 8:56 AM, Jaroslav Hajek <address@hidden> wrote:
> On Mon, Feb 16, 2009 at 8:10 PM, Søren Hauberg <address@hidden> wrote:
>> man, 16 02 2009 kl. 09:23 +0100, skrev Jaroslav Hajek:
>>> On Fri, Feb 13, 2009 at 9:22 PM, Jaroslav Hajek <address@hidden> wrote:
>>> > hi,
>>> >
>>> > this changeset: http://hg.savannah.gnu.org/hgweb/octave/rev/53b4fdeacc2e
>>> > reimplements the reduction and cumulative reduction "cores" sum, prod,
>>> > sumsq, cumsum and cumprod
>>> > for better performance.
>>> >
>>>
>>>
>>> Following similar ideas, I optimized also min/max reductions and
>>> any/all.
>>
>> Some time back there was a request for 'cummin' and 'cummax' (cumulative
>> min and max), but it wasn't trivial to implement. Is it easier to
>> implement such functions with your recent changes?
>>
>> Søren
>
> Well, it would take some work, but seems relatively straightforward.
> We'd need to settle on a specification, though.
> So, my idea:
> y = cummax (x, dim);
> returns cumulative maximum along dimension dim. If dim is omitted,
> operates along the first non-singleton dimension.
> [y, i] = cummax (x);
> returns also cumulative maximum indices.
> cummin is analogical.
>
> So, the question is: Is it worth doing this for 3.2?
>
> It seems to me that this function cannot be reasonably simulated in
> m-code without using a loop or sacrificing the O(N) complexity. Can
> anyone elaborate on expected usage?
>
> cheers
>

OK, it really was quite straightforward (though there were subtle
issues in the implementation
details), so cummin/cummax are now implemented with the functionality
described above:
http://hg.savannah.gnu.org/hgweb/octave/rev/724c0f46d9d4

I'll be glad if someone writes some tests for these and/or improve the docs.

cheers

-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz