octave-maintainers
[Top][All Lists]
Advanced

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

implementing gallery() - fix matlab bugs or keep compatibility?


From: Carnë Draug
Subject: implementing gallery() - fix matlab bugs or keep compatibility?
Date: Tue, 7 May 2013 05:46:31 +0100

Hi

I'm implementing the function gallery, using Nicholas Higham's test
matrix toolbox (version 3.0 released in 1995). His toolbox did not
have a license but I contacted him, told him I want to use it to
implement gallery for Octave, and he gave me permission to use it
under the GPL 3 or later.

He says that his code on this toolbox was the basis for matlab's
gallery function. What I noticed while porting the code is that it has
very little input checking. For example:

* in the condex matrix, the value of theta is supposed to be a scalar,
but a matrix of size n by n, with a K value of 4, will not give any
error.

* in the cycol matrix, n is supposed to be a 2 element vector that
will define the size of the output matrix. The two elements are
extracted with n(1) and n(max(size(n))). This means that anything is
valid, even a string or a N dimensional matrix. The second value may
not even be the second or the last element of the matrix.

There are many other similar cases of these and apparently matlab has
propagated them (all undocumented. My guess is they must have simply
copied and paste Higham's code). Because of this I haven't been
changing them to what I'd expect it to be. I am, however, adding some
input check for cases where otherwise an error would occur anyway. For
example:

* in the condex matrix, the value of K must be the value 1, 2, 3, or
4. Since there is no input check, if other value is given, there is an
error, not because of an unknown K, but because the variable that
would be generated on that block was never initialized.

* in most of the functions, a string character can be used instead of
a numeric scalar and it will work fine. In some few cases, it will
generate an error. I'm adding a check only for those.

I can simply copy and paste the original code, make no changes
whatsoever, and that would probably be maximum matlab compatibility
and less work for me. Or should I change the behaviour by checking for
what is actually documented? Should these be considered bugs to fix,
or peculiarities that we must keep for matlab compatibility?

Carnë


reply via email to

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