Re: Octave 2.1.61 available for ftp

[David Bateman]

According to John W. Eaton <address@hidden> (on 11/09/04):
> |   * Concatenation of simple matrix objects should use a more memory
> |     efficient method as was done in earlier versions of Octave (but
> |     the new code has the distinct advantage of allowing concatenation
> |     for user-defined types, so we can't simply revert to the previous
> |     method).
> 
> David Bateman improved the concat functions, but it is still not clear
> to me whether the current method is as efficient as the original
> method for concatenation of the built-in matrix objects (real,
> complex, character) as the current method still appears to work
> pair-wise for expressions like
> 
>   [a, b, c, d, e]
> 
> so more temporaries are formed than should be needed if we were
> working on the entire list at once (the original code scanned the
> entire list to determine the size and type of the result, then created
> an object to hold it, then filled it with a series of insert
> operations).  I understand that this won't work well for user-defined
> types and {horz,vert}cat functions, but perhaps it could still be used
> if the list only contains the built-in matrix types.

The code is effectively no different than the previous concatenation code
now, with two exceptions. 

We don't resize the first argument and concatenate the others into as
previous, but resize to zero, then the right size and concatenate all
of the objects into this empty matrix. I did this as it turns out that
resize_no_fill is slower than insert, due to the fact that
resize_no_fill does a large amount of error checking of the indexes.

Secondly, previously in pt-mat.cc the copy of the final matrix was
defined locally and all other matrices concatenated into
this. However, now this matrix is passed to catop, so as you say a
temporary copy of the octave_value container of this matrix is
made. However the underlying ArrayRep value should be the same and so,
the overhead should be minimal.

As for speed, I still have a copy of 2.1.50 and comparing that for
speed against the code in the CVS I see the current code as much faster.
Taking ten trial and only considering the fastest one I get the following

octave-2.1.50:3> a = randn(1,1e6); tic; b = [a;a]; toc
ans = 0.37588

octave-cvs:6> a = randn(1,1e6); tic; b = [a;a]; toc
ans = 0.31921

So, yes there is a little memory overhead for the octave_value containers
of the temporary values, but its not too great. Also the speed of the new
code is about 20% faster for the "[]" operator due to the fact it doesn't
use resize_no_fill..

Cheers
David

-- 
David Bateman                                address@hidden
Motorola CRM                                 +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax) 
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary