Deprecate nfields function?

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

Deprecate nfields function?

Rik-4
3/1/14

All,

Would anyone be heartbroken if we deprecated the nfields function in
version 4.2?  It is not used in any m-files in the core and I didn't even
realize it existed until I was trolling through the documentation.  nfields
returns the number of fieldnames in a structure and can be easily replaced
with 'numel (fieldnames (x))'.

My desire is motivated by trying to clean up and condense the global
namespace.  Using octave-stable, I can find the number of functions with

list = [__builtins__ ; __list_functions__ ];
numel (list)
1607

That is a lot of primary functions to remember exist and to avoid name
collisions with.

Matlab doesn't have this function so there is no compatibility hit.  Also,
they seem to have realized the error of their earlier ways in
differentiating functions by simply creating names.  They are now trying to
condense their namespace as well.  Instead of delaunay, delaunay3,
delaunayn they have gotten rid of delaunay3 and just have delaunay for 2-D
and 3-D and delaunayn for N-D.  Similarly, they used to have a lot of
different quadrature routines and now they are pushing just integral,
integral2, and integral3 which accept a 'method' argument to change the
internal algorithm.

--Rik

Reply | Threaded
Open this post in threaded view
|

Re: Deprecate nfields function?

Carnë Draug-2
On 1 March 2014 16:21, Rik <[hidden email]> wrote:
> Would anyone be heartbroken if we deprecated the nfields function in
> version 4.2?  It is not used in any m-files in the core and I didn't even
> realize it existed until I was trolling through the documentation.  nfields
> returns the number of fieldnames in a structure and can be easily replaced
> with 'numel (fieldnames (x))'.

I just gave a quick check on Octave Forge and couldn't find any usage
of this function. I agree with removing it.

Carnë
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate nfields function?

John W. Eaton
Administrator
In reply to this post by Rik-4
On 03/01/2014 11:21 AM, Rik wrote:

> 3/1/14
>
> All,
>
> Would anyone be heartbroken  if we deprecated the nfields function in
> version 4.2?  It is not used in any m-files in the core and I didn't even
> realize it existed until I was trolling through the documentation.  nfields
> returns the number of fieldnames in a structure and can be easily replaced
> with 'numel (fieldnames (x))'.
>
> My desire is motivated by trying to clean up and condense the global
> namespace.  Using octave-stable, I can find the number of functions with
>
> list = [__builtins__ ; __list_functions__ ];
> numel (list)
> 1607
>
> That is a lot of primary functions to remember exist and to avoid name
> collisions with.
>
> Matlab doesn't have this function so there is no compatibility hit.  Also,
> they seem to have realized the error of their earlier ways in
> differentiating functions by simply creating names.  They are now trying to
> condense their namespace as well.  Instead of delaunay, delaunay3,
> delaunayn they have gotten rid of delaunay3 and just have delaunay for 2-D
> and 3-D and delaunayn for N-D.  Similarly, they used to have a lot of
> different quadrature routines and now they are pushing just integral,
> integral2, and integral3 which accept a 'method' argument to change the
> internal algorithm.

These changes seem OK to me.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Deprecate nfields function?

Lukas Reichlin-4
In reply to this post by Rik-4
On 01.03.2014, at 17:21, Rik <[hidden email]> wrote:

> Would anyone be heartbroken if we deprecated the nfields function in
> version 4.2?

Yes, I'm using it in the control package and I think it's a handy function.

Lukas

Reply | Threaded
Open this post in threaded view
|

Re: Deprecate nfields function?

Juan Pablo Carbajal-2
On Sat, Mar 1, 2014 at 7:06 PM, Lukas Reichlin
<[hidden email]> wrote:
> On 01.03.2014, at 17:21, Rik <[hidden email]> wrote:
>
>> Would anyone be heartbroken if we deprecated the nfields function in
>> version 4.2?
>
> Yes, I'm using it in the control package and I think it's a handy function.
>
> Lukas
>

Lukas would it be possible to define a private function implementing it?
Seems quite a trivial function and cleaning the namespace seems important.
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate nfields function?

Daniel Sebald
In reply to this post by Lukas Reichlin-4
On 03/01/2014 12:06 PM, Lukas Reichlin wrote:
> On 01.03.2014, at 17:21, Rik<[hidden email]>  wrote:
>
>> Would anyone be heartbroken if we deprecated the nfields function in
>> version 4.2?
>
> Yes, I'm using it in the control package and I think it's a handy function.

I'm indifferent about the shortcut being in the core (it's so short,
doesn't seem to hurt), but why nfields() as opposed to numfield() to be
more consistent with numel()?

Dan
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate nfields function?

Carnë Draug
In reply to this post by Lukas Reichlin-4
On 1 March 2014 16:49, Carnë Draug <[hidden email]> wrote:
> On 1 March 2014 16:21, Rik <[hidden email]> wrote:
>> Would anyone be heartbroken if we deprecated the nfields function in
>> version 4.2?  It is not used in any m-files in the core and I didn't even
>> realize it existed until I was trolling through the documentation.  nfields
>> returns the number of fieldnames in a structure and can be easily replaced
>> with 'numel (fieldnames (x))'.
>
> I just gave a quick check on Octave Forge and couldn't find any usage
> of this function. I agree with removing it.

On 1 March 2014 18:06, Lukas Reichlin <[hidden email]> wrote:
> Yes, I'm using it in the control package and I think it's a handy function.

Ups. My apologies. I forgot to update the repositories before saying
that it is not used in octave Forge. It seems you started to use it
recently.

After updating all the repositories, it seems only the control package
uses this function, and only to check if a struct is empty, not to
actually get the number of fields. Note that isempty in an empty
struct actually returns false:

octave-cli-3.8.0:1> s = struct ();
octave-cli-3.8.0:2> isempty (s)
ans = 0

Carnë
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate nfields function?

John W. Eaton
Administrator
On 03/01/2014 01:54 PM, Carnë Draug wrote:

> After updating all the repositories, it seems only the control package
> uses this function, and only to check if a struct is empty, not to
> actually get the number of fields.

To avoid confusion, I wouldn't say that it is checking to see whether
the struct is empty.  I'd say that it is checking to see whether the
structure has any fields.  Although the fields can be thought of as an
additional "dimension" of a structure array, they are not considered
when doing operations on dimensions (isempty, reshape, size, etc.).

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Deprecate nfields function?

John W. Eaton
Administrator
In reply to this post by Daniel Sebald
On 03/01/2014 01:15 PM, Daniel J Sebald wrote:

> On 03/01/2014 12:06 PM, Lukas Reichlin wrote:
>> On 01.03.2014, at 17:21, Rik<[hidden email]>  wrote:
>>
>>> Would anyone be heartbroken if we deprecated the nfields function in
>>> version 4.2?
>>
>> Yes, I'm using it in the control package and I think it's a handy
>> function.
>
> I'm indifferent about the shortcut being in the core (it's so short,
> doesn't seem to hurt), but why nfields() as opposed to numfield() to be
> more consistent with numel()?

I suspect nfields is older than numel (a name that was invented by TMW
because length was already taken and defined in a strange way that is
not equivalent to numel).  And I just chose nfields because it seemed
like a good idea the time.  It's easy to look back and say that a past
decision wasn't perfect.  It's much harder to know whether a decision
you make now will still seem like a good idea 20 years later...

jwe



Reply | Threaded
Open this post in threaded view
|

Re: Deprecate nfields function?

Rik-4
On 03/01/2014 11:07 AM, John W. Eaton wrote:

> On 03/01/2014 01:15 PM, Daniel J Sebald wrote:
>> On 03/01/2014 12:06 PM, Lukas Reichlin wrote:
>>> On 01.03.2014, at 17:21, Rik<[hidden email]>  wrote:
>>>
>>>> Would anyone be heartbroken if we deprecated the nfields function in
>>>> version 4.2?
>>>
>>> Yes, I'm using it in the control package and I think it's a handy
>>> function.
>>
>> I'm indifferent about the shortcut being in the core (it's so short,
>> doesn't seem to hurt), but why nfields() as opposed to numfield() to be
>> more consistent with numel()?
>
> I suspect nfields is older than numel (a name that was invented by TMW
> because length was already taken and defined in a strange way that is not
> equivalent to numel).  And I just chose nfields because it seemed like a
> good idea the time.  It's easy to look back and say that a past decision
> wasn't perfect.  It's much harder to know whether a decision you make now
> will still seem like a good idea 20 years later...

There was definitely no criticism on my part.  These things do evolve and
it is hard to pick exactly the correct strategy both for today and for 20
years from today.  Do we want to rename nfields to something else
(numfields, numfld, numflds) or remove it entirely?

--Rik
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate nfields function?

Daniel Sebald
On 03/01/2014 02:03 PM, Rik wrote:

> On 03/01/2014 11:07 AM, John W. Eaton wrote:
>> On 03/01/2014 01:15 PM, Daniel J Sebald wrote:
>>> On 03/01/2014 12:06 PM, Lukas Reichlin wrote:
>>>> On 01.03.2014, at 17:21, Rik<[hidden email]>   wrote:
>>>>
>>>>> Would anyone be heartbroken if we deprecated the nfields function in
>>>>> version 4.2?
>>>>
>>>> Yes, I'm using it in the control package and I think it's a handy
>>>> function.
>>>
>>> I'm indifferent about the shortcut being in the core (it's so short,
>>> doesn't seem to hurt), but why nfields() as opposed to numfield() to be
>>> more consistent with numel()?
>>
>> I suspect nfields is older than numel (a name that was invented by TMW
>> because length was already taken and defined in a strange way that is not
>> equivalent to numel).  And I just chose nfields because it seemed like a
>> good idea the time.  It's easy to look back and say that a past decision
>> wasn't perfect.  It's much harder to know whether a decision you make now
>> will still seem like a good idea 20 years later...
>
> There was definitely no criticism on my part.  These things do evolve and
> it is hard to pick exactly the correct strategy both for today and for 20
> years from today.  Do we want to rename nfields to something else
> (numfields, numfld, numflds) or remove it entirely?

If any, I like the second, numfld().  It's short to match the shortness
of numel().

The justification for such a function is that a structure is a
fundamental class and where it is straightforward to get the number of
elements of classes with numel(), it seems slightly clumsy to do 'numel
(fieldnames (x))' to get the number of fields.

I wanted to be careful that such a function makes sense in various
situations, and in trying a few things here--unless my copy of Octave is
too far out of date--I've found something buggish when removing a
structure field.  It may not be a bug but just reporting a successful
operation as opposed to an error message.  Try the following:

octave-cli:26> foo.f1 = 'abc';
octave-cli:27> foo.f2 = 1;
octave-cli:28> foo(2).f1 = 'xyz';
octave-cli:29> foo(2).f2 = '2';
octave-cli:30> foo(2)
ans =

   scalar structure containing the fields:

     f1 = xyz
     f2 = 2

octave-cli:31> rmfield(foo(2), 'f2')
ans =

   scalar structure containing the fields:

     f1 = xyz

octave-cli:32> foo(2)
ans =

   scalar structure containing the fields:

     f1 = xyz
     f2 = 2

octave-cli:33>

The "bug" is that removing the field in the second last command suggests
that field 'f2' has been removed from the second element of the
structure array when in fact that might not be a valid thing to do.

Dan
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate nfields function?

Daniel Sebald
On 03/01/2014 02:33 PM, Daniel J Sebald wrote:

> octave-cli:31> rmfield(foo(2), 'f2')
> ans =
>
> scalar structure containing the fields:
>
> f1 = xyz
...
> The "bug" is that removing the field in the second last command suggests
> that field 'f2' has been removed from the second element of the
> structure array when in fact that might not be a valid thing to do.

Wait, that's not a bug.  There's no assignment.  Sorry.

Dan
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate nfields function?

John W. Eaton
Administrator
In reply to this post by Rik-4
On 03/01/2014 03:03 PM, Rik wrote:

> There was definitely no criticism on my part.  These things do evolve and
> it is hard to pick exactly the correct strategy both for today and for 20
> years from today.  Do we want to rename nfields to something else
> (numfields, numfld, numflds) or remove it entirely?

If we decide to keep it, I'd say just leave it alone.

But if everyone thinks that nfields is a horrible name, then I prefer
numfields.  numfld and numflds don't seem any better than nfields to me
while numfields is at least similar to numel.

jwe