octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: nfields replaced by numfields on default branch


From: Rik
Subject: Re: nfields replaced by numfields on default branch
Date: Mon, 03 Mar 2014 07:10:41 -0800

On 03/03/2014 12:36 AM, Lukas Reichlin wrote:
> 
> On 03.03.2014, at 09:25, Lukas Reichlin <address@hidden> wrote:
> 
>> On 02.03.2014, at 22:01, Rik <address@hidden> wrote:
>>
>>> 3/2/14
>>>
>>> All,
>>>
>>> I deprecated nfields and added the new function numfields (in analogy with
>>> numel) to replace it.  This probably won't make a difference to most people
>>> since it was under-utilized.  I changed some core m-files to now use
>>> numfields which made the code cleaner and simpler.  The changeset is here
>>> (http://hg.savannah.gnu.org/hgweb/octave/rev/fcd87f68af4f).
>>>
>>> --Rik
>>
>> I don't quite get it. First you want to delete nfields, a function 
>> introduced in Octave 3.4 (!) because it is not widely used (yet). Then you 
>> rename it to numfields in analogy to numel. What about ndims or nnz? Should 
>> it be "numdims" or "numnz" then as well?
>>

Dan and jwe convinced me that structs, as first-class objects like
matrices, really should have their own way of determining the number of
elements.

Matlab already has numel, ndims, and nnz so there is no possibility for
renaming those and staying compatible.  On the other hand, The Mathworks
does not offer a numfields function so we are free to make our own,
hopefully smart, naming decision.

>> The reason why I object to your change is that I want to keep the control 
>> package's dependency on Octave's version number as low as possible. 
>> Currently it's 3.6.0 and I don't want to raise it for no obvious reason.
>>
>> In order to not exclude users (e.g. Debian and Ubuntu), I would have to 
>> create a DEFUN_DLD "nfields2" or the like such that there are no conflicts 
>> in Octave 3.6 and 3.8 as well as 4.0 and later. Then I'd have to keep 
>> oct-file "nfields2" in the control package until some show-stopping bug or 
>> important feature requires me to raise the dependency to Octave 4.0 or later.
>>

It's simple to write code that is portable to 3.0 and 4.0.  Just use

number_of_fields = numel (fieldnames (obj));

This doesn't depend on any internal Octave function and is the only way one
has to do it in Matlab.

I only deprecated nfields in 4.2 which means there is still years before
you need to make any changes to code or versioning requirements.

>> Lukas
> 
> PS: I think that you've just introduced a bug in "imwrite" on line 103 with 
> changeset fcd87f68af4f225f911daf47e2642fc0f6f1d12a.
> 

Yes, I think so too.  I reversed the sense of the if test in this changeset
(http://hg.savannah.gnu.org/hgweb/octave/rev/7b60d0d9f0f2).

--Rik



reply via email to

[Prev in Thread] Current Thread [Next in Thread]