Can we deprecate/remove extra arguments currently accepted by numel?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Can we deprecate/remove extra arguments currently accepted by numel?

John W. Eaton
Administrator
Octave's numel function accepts extra arguments:

octave:1> help numel
'numel' is a built-in function from the file libinterp/corefcn/data.cc

  -- numel (A)
  -- numel (A, IDX1, IDX2, ...)
      Return the number of elements in the object A.

      Optionally, if indices IDX1, IDX2, ... are supplied, return the
      number of elements that would result from the indexing

           A(IDX1, IDX2, ...)

      Note that the indices do not have to be scalar numbers.  For
      example,

           A = 1;
           B = ones (2, 3);
           numel (A, B)

      will return 6, as this is the number of ways to index with B.  Or
      the index could be the string ":" which represents the colon
      operator.  For example,

           A = ones (5, 3);
           numel (A, 2, ":")

      will return 3 as the second row has three column entries.

      This method is also called when an object appears as lvalue with
      cs-list indexing, i.e., 'object{...}' or 'object(...).field'.


Does Matlab still accept this usage?  It does not appear to be
documented now.  There is a question on Matlab Central about it here:

https://www.mathworks.com/matlabcentral/answers/169310-what-does-2nd-argument-mean-in-numel-function

that indicates that it was documented around 5-6 years ago.  I didn't
find anything in the release notes
(https://www.mathworks.com/help/matlab/release-notes.html) about it
being removed.

Is the function numArgumentsFromSubsctript somehow related to this
(apparently obsolete) way of calling numel?

If it is not needed in Matlab, do we need it in Octave?  Does any code
in Octave rely on it now?  Can we safely remove it now, or should we
deprecate/warn for a couple of releases first?

If you think this is not enough questions, I can probably find a way to
ask more.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Can we deprecate/remove extra arguments currently accepted by numel?

apjanke-floss


On 3/15/19 12:34 AM, John W. Eaton wrote:
> Octave's numel function accepts extra arguments:
>
> octave:1> help numel
> 'numel' is a built-in function from the file libinterp/corefcn/data.cc
>
>   -- numel (A)
>   -- numel (A, IDX1, IDX2, ...)
>       Return the number of elements in the object A.
 > [...snip...]
>
> Does Matlab still accept this usage?  It does not appear to be
> documented now.

It may not be documented, but I believe that this calling form is still
implicitly used by the Matlab runtime in conjunction with overloaded
subsref and/or subsasgn for user-defined classes. (Remember when we were
discussing subref/sugsasgn semantics in IRC a week or so ago and you
were like, "WTF?"?) So, it's not just accepted, but required in some
cases, WRT classdef classes.

> Is the function numArgumentsFromSubsctript somehow related to this
> (apparently obsolete) way of calling numel?

I believe it is, but I'm not aware of any doco specifying how it works,
or how it interacts with numel().

Cheers,
Andrew

Reply | Threaded
Open this post in threaded view
|

Re: Can we deprecate/remove extra arguments currently accepted by numel?

John W. Eaton
Administrator
On 3/15/19 1:04 AM, Andrew Janke wrote:

>
>
> On 3/15/19 12:34 AM, John W. Eaton wrote:
>> Octave's numel function accepts extra arguments:
>>
>> octave:1> help numel
>> 'numel' is a built-in function from the file libinterp/corefcn/data.cc
>>
>>   -- numel (A)
>>   -- numel (A, IDX1, IDX2, ...)
>>       Return the number of elements in the object A.
>  > [...snip...]
>>
>> Does Matlab still accept this usage?  It does not appear to be
>> documented now.
>
> It may not be documented, but I believe that this calling form is still
> implicitly used by the Matlab runtime in conjunction with overloaded
> subsref and/or subsasgn for user-defined classes. (Remember when we were
> discussing subref/sugsasgn semantics in IRC a week or so ago and you
> were like, "WTF?"?) So, it's not just accepted, but required in some
> cases, WRT classdef classes.

Yeah, I remember now.  Thanks for the info.  Could we check somehow
whether this is still supported and whether it ultimately calls
numArgumentsFromSubscript?  It would be nice to get rid of this calling
form if it is undocumented and not needed.  But apparently you are
saying it may be needed in some cases...

BTW, this is related to the overloaded virtual warnings since internally
we have two different forms of numel in the octave_value class hierarchy
and both forms are not always overloaded in derived classes.  So I was
trying to decide whether we could get rid of the undocumented version,
rename it to something other than numel, or just add using declarations
like I have done now for a few other classes.

>> Is the function numArgumentsFromSubsctript somehow related to this
>> (apparently obsolete) way of calling numel?
>
> I believe it is, but I'm not aware of any doco specifying how it works,
> or how it interacts with numel().

Hmm.  OK.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Can we deprecate/remove extra arguments currently accepted by numel?

siko1056
In reply to this post by John W. Eaton
On Fri, Mar 15, 2019 at 5:38 AM John W. Eaton <[hidden email]> wrote:
Octave's numel function accepts extra arguments:

[...] For example,

           A = 1;
           B = ones (2, 3);
           numel (A, B)

      will return 6, as this is the number of ways to index with B.  Or
      the index could be the string ":" which represents the colon
      operator.  For example,

           A = ones (5, 3);
           numel (A, 2, ":")

      will return 3 as the second row has three column entries [...]

Does Matlab still accept this usage?  It does not appear to be
documented now.

Both examples still work in R2018b with the same results (the second example with ':' single quotes).

The documentation is not really clear about how numel is used today, but in the context with classes the ML docs clearly suggest to use "numArgumentsFromSubscript", even if a numel-method is present:

"If classes implement a numArgumentsFromSubscript method, MATLAB calls it instead of numel to determine the number of elements returned by indexed expressions that return comma-separated lists." [2].

Kai