Re: data structure for simulation

[Jaroslav Hajek]

On Tue, Mar 17, 2009 at 11:12 PM, Francesco Potorti`
<address@hidden> wrote:
>>> This is an issue with cell arrays, in fact.  I realise that my question
>>> can be reformulated more simply like this:
>>>
>>> octave> a=cell(1e6,1);
>>> octave> a(1e6)=1;
>>> octave> whos a
>>> Variables in the current scope:
>>>
>>>  Attr Name         Size                     Bytes  Class
>>>  ==== ====         ====                     =====  =====
>>>       a      1000000x1                          8  cell
>>>
>>> Total is 1000000 elements using 8 bytes
>>>
>>> So Octave internally knows that only an element in the cell array is
>>> nonempty and does not allocate memory for the whole array.
>>
>>No, that assumption is wrong. The whos output apparently does not
>>include memory for array and octave_value internals.
>>What you have in memory is indeed an array of million octave_value objects.
>
> I see.  Maybe whos should be more realistic?  I normally use it to know
> how much memory my variables need, so I think it is not useful if whos
> tells me much less than the real memory usage.
>

Maybe, but that is not so easy; because values and arrays can share
memory, so you can easily get even far more than the real memory
usage. What who does now, I think, is really just summing up calls to
byte_size (). So maybe we can just adjust the byte_size calculations.

>>> But if I want to know the index of the nonempty cell, doing
>>>
>>> find (! cellfun (@isempty, a))
>>>
>>> needs a non-negligible computing time, because cellfun goes through all
>>> elements, be they empty or not.  I hoped there was an efficient way of
>>> knowing indexes of nonempty elements.
>>
>>Well, you really need to go through all the elements, there's no way
>>avoiding it. This expression
>>is slow because you pass in a function handle, even though it's a
>>built-in function.
>
> I see.
>
>>Cellfun allows also specifying certain mappers as special string, so you may 
>>try
>>
>>find (cellfun ("prodofsize", a))
>>
>>which seems to be specialized and thus significantly faster.
>
> Yes, it is *much* faster, indeed, thanks!
>
> This is undocumented, right?

I see it in "help cellfun".

Still, IMHO the call to cellfun (@isempty is way too slow. Perhaps
there's a way to speed it up.

cheers

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