Re: Too many arguments?

[Michael Martins]

Am Donnerstag 06 August 2009 11:39:27 schrieb Carlo de Falco:
> On 6 Aug 2009, at 10:16, Olaf Till wrote:
> > On Wed, Aug 05, 2009 at 10:23:22PM -0400, John W. Eaton wrote:
> >> I don't remember exactly why I chose to make Octave silently accept
> >> extra arguments.  Maybe I didn't have an easy way to implement this
> >> feature at the time.
> >>
> >> In any case, some people might think this difference with Matlab is a
> >> minor bug.  It would probably not be hard to make Octave generate an
> >> error in this case, so it might happen in the future.  If you don't
> >> want that, then can you explain clearly why it makes sense for Octave
> >> to silently accept extra arguments that are not used?
> >
> > Because then a function can be called with some extra last arguments,
> > no matter whether the called function has listed them in its
> > header. This makes sense if it can vary which function is called,
> > e.g. if the function to be called is configurable. If extra arguments
> > do not cause an error, one can change the interface of the function
> > call at the caller side without changing each existing called
> > function.
> >
> > Example: In Octave-Forge, for main/optim/leasqr.m the user has to
> > supply a user-function and may supply a second function to compute its
> > Jacobian. If the user doesn't supply the latter, a generic function is
> > used to estimate the Jacobian with difference quotients (dfdp.m). Now
> > I would like to introduce maximal or minimal values for parameter
> > estimation into leasqr.m. These maximal or minimal values should for
> > some reason also be respected by dfdp.m. So I would like to pass an
> > additional argument which contains the maximal or minimal values from
> > leasqr.m to dfdp.m. But users may already have used leasqr.m before
> > with their own Jacobian-functions, which do not have the extra
> > argument in the interface (and BTW probably do not need to honour it
> > anyway, since they do not compute difference quotients). If Octave
> > does not accept extra arguments, these users have to change the
> > interface of their functions after the interface-change in leasqr.m.
> >
> > Olaf
>
> Just my two cents,
> why don't you implement this "backward compatible" behaviour using a
> try/catch block?
> e.g.:
>
> try
>   user_function (more, arguments, than, expected);
> catch
>   warning (lasterr ());
>   warning ("the interface for user defined functions has changed, see
> package docs for details");
>   user_function (fewer, arguments);
> end
>
> This way you will not depend on the current behaviour of Octave wrt
> extra parameters.
> I cannot test it right now but I believe this would be compatible with
> matlab as well...
> HTH,
> c.

The current behavior of octave makes more sence then the matlab behavior; this 
is at least my opinion. Why should very usefull things change, only to be 
compatible with matlab. One should not include all disadvantages of matlab.

Michael

-- 
|\  /| PD Dr. Michael Martins, Universitaet Hamburg
| \/ | Institut fuer Experimentalphysik    Tel.: +49-40-8998-3121
| |\/| Luruper Chaussee 149
| |  | D-22761 Hamburg         Email: address@hidden