Re: liboctave capacity, length, nemel, and numel

[Rik]

On 05/21/2015 12:04 PM, address@hidden wrote:

Subject:

Re: liboctave capacity, length, nemel, and numel

From:

"John W. Eaton" <address@hidden>

Date:

05/21/2015 12:04 PM

To:

Carnë Draug <address@hidden>, octave maintainers mailing list <address@hidden>

List-Post:

<mailto:address@hidden>

Content-Transfer-Encoding:

quoted-printable

Precedence:

list

MIME-Version:

1.0

References:

<address@hidden>

In-Reply-To:

<address@hidden>

Message-ID:

<address@hidden>

Content-Type:

text/plain; charset=utf-8; format=flowed

Message:

8

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.

jwe

It might be worth checking in the Sparse array implementation to make utterly certain that there is no difference between numel and capacity; it's there that I would expect to find a difference if it exists.

Otherwise, I really support cleaning things up.  C++ isn't meant to be an evocative language rich with nearly identical words.  In English I can compliment a woman by calling her attractive, beautiful, pretty, comely, etc.  It's nice to have that flexibility in the spoken language, but I'm not romancing my computer and I find it confusing that the same procedure could be called out by four different names.

A minor wish is that eventually the C++ code can look close to the standard m-file syntax and that anyone who knows Octave syntax would be able to read, at least for understanding, what is happening in the C++ code.  For that reason, I also would preserve numel() since it mirrors the Octave language.

Also, you can use the GCC_ATTR_DEPRECATED at the end of a function, like capacity, that will eventually be removed.  This produces a nice warning when code that uses it is compiled.  It would certainly be a good thing to put that in place and use the warnings to weed out any instances in the core.

--Rik