octave patch

[John W. Eaton]

On 25-Jan-2008, Jaroslav Hajek wrote:

| hello all developers,
| I have noticed that while Octave handles Ranges (l:s:u) as special
| objects in a smart way,
| they are still being converted to integer vectors whenever used for indexing.
| The behaviour can easily be observed using a System Monitor which shows 
memory:
| do
| n = 4e7; a = ones(n,1); b = ones(n,1);
| now, the sysmon shows that a statement
| a(1:n) = b;
| allocates several mbytes of memory, while
| a(:) = b;
| does not.
| 
| The problem seems to be that idx_vector is not specialized to hold an
| integer range (just single colon).
| I have modified the idx_vector_rep class so to be specialized for
| ranges (i.e. instead of data array,
| store only base and step). The attached two patches (made with diff
| -cp as advised in Octave's manual)
| show the changes against the "Development" sources from
| ftp://ftp.octave.org/pub/octave/bleeding-edge/octave-3.0.0.tar.bz2
| Compiled and "make check"ed, all tests pass normally (only my normal
| 12 fails with test-sparse occur, caused probably
| by miscompilation of some of the UMFPACK et al. sparse libraries...]
| 
| The redundant allocation problem described above disappears.
| 
| I don't know about any octave benchmarks, but there might (hopefully)
| be some positive performance impact.

I applied this patch and checked it in with the following ChangeLog
entry.  In the future, it would help if you included the ChangeLog
entry along with your patch.

I also added explicit initialization in all the constructors for the
new range_base and range_step data members and fixed some formatting
to match the conventions used in the rest of Octave.  Do you have your
editor set to interpret TAB characters as being two spaces wide?  If
so, I'd recommend not doing that for code you send to others, as they
are not likely to use the same settings.

Thanks,

jwe