Why does Octave ignore additional input arguments ?

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

Why does Octave ignore additional input arguments ?

jbect
Hello everyone,

I was wondering whether there is a specific reason why Octave silently
ignores additional input arguments in a function.

For instance:

 >> F = @(x) x^2;  F(2, 3)
ans =  4

while in Matlab I get a "Too many input arguments" error.

@++
Julien

Reply | Threaded
Open this post in threaded view
|

Re: Why does Octave ignore additional input arguments ?

Olaf Till-2
On Mon, Feb 08, 2016 at 06:59:27PM +0100, Julien Bect wrote:

> Hello everyone,
>
> I was wondering whether there is a specific reason why Octave silently
> ignores additional input arguments in a function.
>
> For instance:
>
> >> F = @(x) x^2;  F(2, 3)
> ans =  4
>
> while in Matlab I get a "Too many input arguments" error.
>
> @++
> Julien
This was discussed in the thread starting with:

http://lists.gnu.org/archive/html/help-octave/2009-08/msg00037.html

Summarizing, this behaviour of Octave might have been introduced
without a strong reason, but it has regarded as to be useful.

As an example, the optim package has functions which call user
functions under certain circumstances with an additional informational
input argument, which users probalbly only rarely need. Matlabs
behaviour would require users to always account for this additional
argument in their function interfaces.

Olaf

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Why does Octave ignore additional input arguments ?

jbect
Le 08/02/2016 21:57, Olaf Till a écrit :

> On Mon, Feb 08, 2016 at 06:59:27PM +0100, Julien Bect wrote:
>> >Hello everyone,
>> >
>> >I was wondering whether there is a specific reason why Octave silently
>> >ignores additional input arguments in a function.
>> >
>> >For instance:
>> >
>>>> > >>F = @(x) x^2;  F(2, 3)
>> >ans =  4
>> >
>> >while in Matlab I get a "Too many input arguments" error.
>> >
>> >@++
>> >Julien
> This was discussed in the thread starting with:
>
> http://lists.gnu.org/archive/html/help-octave/2009-08/msg00037.html
>
> Summarizing, this behaviour of Octave might have been introduced
> without a strong reason, but it has regarded as to be useful.

Thanks for the link, Olaf. I assumed this would have been discussed but
I had failed to find the relevant thread.

I have to confess that I'm not really convinced by the reasons given to
keep the current behaviour...

But this has already been discussed, so let's leave things as they are.

@++
Julien



Reply | Threaded
Open this post in threaded view
|

Re: Why does Octave ignore additional input arguments ?

nrjank


On Feb 8, 2016 4:38 PM, "Julien Bect" <[hidden email]> wrote:
>
> Le 08/02/2016 21:57, Olaf Till a écrit :
>>
>> On Mon, Feb 08, 2016 at 06:59:27PM +0100, Julien Bect wrote:
>>>
>>> >Hello everyone,
>>> >
>>> >I was wondering whether there is a specific reason why Octave silently
>>> >ignores additional input arguments in a function.
>>> >
>>> >For instance:
>>> >
>>>>>
>>>>> > >>F = @(x) x^2;  F(2, 3)
>>>
>>> >ans =  4
>>> >
>>> >while in Matlab I get a "Too many input arguments" error.
>>> >
>>> >@++
>>> >Julien
>>
>> This was discussed in the thread starting with:
>>
>> http://lists.gnu.org/archive/html/help-octave/2009-08/msg00037.html
>>
>> Summarizing, this behaviour of Octave might have been introduced
>> without a strong reason, but it has regarded as to be useful.
>
>
> Thanks for the link, Olaf. I assumed this would have been discussed but I had failed to find the relevant thread.
>
> I have to confess that I'm not really convinced by the reasons given to keep the current behaviour...
>
> But this has already been discussed, so let's leave things as they are.
>
> @++
> Julien
>
>
>

I think I remember the thought process being something like: what works in MATLAB produce the same output in Octave, but some things that work in Octave might not work in MATLAB, and that's ok when it is useful. And although it might be considered sloppy, some people have made use of that feature.

Nick j.

Reply | Threaded
Open this post in threaded view
|

Re: Why does Octave ignore additional input arguments ?

jbect
Le 09/02/2016 00:46, Nicholas Jankowski a écrit :

>
> > I have to confess that I'm not really convinced by the reasons given
> to keep the current behaviour...
> >
> > But this has already been discussed, so let's leave things as they are.
> >
> > @++
> > Julien
>
> I think I remember the thought process being something like: what
> works in MATLAB produce the same output in Octave, but some things
> that work in Octave might not work in MATLAB, and that's ok when it is
> useful. And although it might be considered sloppy, some people have
> made use of that feature.
>

Accepting additional arguments silently seems to me like a dangerous
feature for non-expert users, who will not be informed of potential
syntax errors.

Unless of course every developper adds a check for nargin > nargin_max.  
This is what I do in the stk package, since I have to, but I find it
annoying (and I would be perfectly happy with a default non-customized
error message).

No other langage that I know of (R, Scilab, Python, Scilab, Julia) does
that.

But as I said, this has already been discussed, and apparently no one is
complaining, so I will keep adding checks for nargin > nargin_max
everywhere.

@++
Julien

Reply | Threaded
Open this post in threaded view
|

Re: Why does Octave ignore additional input arguments ?

Colin Macdonald-2
On 08/02/16 23:56, Julien Bect wrote:
> but I find it annoying (and I would be perfectly happy with a default
> non-customized error message).

+1 for annoying.

I hadn't paid attention to this problem until recently; *not* looking
forward to doing this everywhere:

if (nargin > ...)
  print_usage ();
endif

Colin

Reply | Threaded
Open this post in threaded view
|

Re: Why does Octave ignore additional input arguments ?

John W. Eaton
Administrator
On 02/09/2016 04:11 AM, Colin Macdonald wrote:

> On 08/02/16 23:56, Julien Bect wrote:
>> but I find it annoying (and I would be perfectly happy with a default
>> non-customized error message).
>
> +1 for annoying.
>
> I hadn't paid attention to this problem until recently; *not* looking
> forward to doing this everywhere:
>
> if (nargin > ...)
>    print_usage ();
> endif

I think it would be fairly easy to make exactly that happen automatically.

The question is whether there is some legitimate reason to keep the
existing behavior.  I'm not convinced that there is, but maybe I'm
wrong?  It would help me if I see an example of where the current
behavior is useful.

jwe



Reply | Threaded
Open this post in threaded view
|

Re: Why does Octave ignore additional input arguments ?

jbect
Le 09/02/2016 11:29, John W. Eaton a écrit :

> On 02/09/2016 04:11 AM, Colin Macdonald wrote:
>> On 08/02/16 23:56, Julien Bect wrote:
>>> but I find it annoying (and I would be perfectly happy with a default
>>> non-customized error message).
>>
>> +1 for annoying.
>>
>> I hadn't paid attention to this problem until recently; *not* looking
>> forward to doing this everywhere:
>>
>> if (nargin > ...)
>>    print_usage ();
>> endif
>
> I think it would be fairly easy to make exactly that happen
> automatically.
>
> The question is whether there is some legitimate reason to keep the
> existing behavior.  I'm not convinced that there is, but maybe I'm
> wrong?  It would help me if I see an example of where the current
> behavior is useful.

I think that essentially two reasons have been invoked to justify
keeping the existing behavior :

1) The existing behavior makes it possible to issue customized error
message when nargin > nargin_max.

2) In a situation where a package requires its users to provide a handle
to a function, say F(x), and then decides to extend the interface with
an additional argument, say F(x, y), the existing behavior makes it
possible for the package developer to switch to the new interface
unconditionally, without requiring the user to modify its own functions.

For the first point there isn't much to say except that, as I said
earlier, I would be perfectly happy with a default error message for
this.  I am not aware of a situation where a customized error message is
really needed.

For the second point, Olaf Till had an example involving the optim
package.  See
http://lists.gnu.org/archive/html/help-octave/2009-08/msg00074.html.

Carlo de Falco has proposed a try-catch based solution to Olaf's
problem, which I think is fine:
http://lists.gnu.org/archive/html/help-octave/2009-08/msg00077.html 
(especially if the error is accompanied with an error identifier that
makes it possible to deal with it cleanly).

But Olaf seemed to think to the try-catch approach wouldn't do:
http://lists.gnu.org/archive/html/help-octave/2009-08/msg00078.html.

@++
Julien


Reply | Threaded
Open this post in threaded view
|

Re: Why does Octave ignore additional input arguments ?

Olaf Till-2
On Tue, Feb 09, 2016 at 11:49:10AM +0100, Julien Bect wrote:

> Le 09/02/2016 11:29, John W. Eaton a écrit :
> ...
> >It would help me if I see an example of where the current behavior is
> >useful.
> ...
> 2) In a situation where a package requires its users to provide a handle to
> a function, say F(x), and then decides to extend the interface with an
> additional argument, say F(x, y), the existing behavior makes it possible
> for the package developer to switch to the new interface unconditionally,
> without requiring the user to modify its own functions.
> ...
> For the second point, Olaf Till had an example involving the optim package.
> See http://lists.gnu.org/archive/html/help-octave/2009-08/msg00074.html.
For an example I would rather point to the second post of this current
thread. Or are there more details needed?

Olaf

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc (836 bytes) Download Attachment