Re: liboctave capacity, length, nemel, and numel

[Carnë Draug]

On 21 May 2015 at 20:04, John W. Eaton <address@hidden> wrote:
> On 05/21/2015 01:56 PM, Carnë Draug wrote:
>
>> at the moment, we have 4 Array:: methods to get the current number of
>> elements.  They are capacity, length, nemel, and numel.  What's the idea
>> behind them?  Are subclasses supposed to overload some of them
>> differently?
>> I couldn't find any documentation for that.
>>
>> We recently got a bug about Array::length not behaving the same length()
>> at
>> the interpreter, which I think makes sense.  Changing the behaviour of
>> Array::length() would be bad for backwards compatibility but maybe not
>> having it at all would be a good idea.
>>
>> Just like we deprecate stuff at the Octave interpreter because there's
>> other
>> functions that do the same thing, should we be doing the same in
>> liboctave?
>
>
> Long ago, I think there was the idea that capacity might mean something
> different from length if the allocated size of the underlying array was
> different from the current number of elements that were "in use".
>
> I think numel was introduced just so the name could match numel from Matlab.
>
> I don't know why nelem (number of elements) was introduced.
>
> Since they all currently mean the same thing, I don't have a problem
> deprecating all but one.  I guess at this point it would be best to keep
> numel and (eventually) remove the rest.
>

I have pushed the last changeset that deprecates and replaces all usage
of length(), nelem(), and capacity() for Array and Sparse.

There are other cases of two methods that return the same.  Example,
DiagArray::diag_lengh and DiagArray::length, so I plan to do the same
for those over time.

Carnë