Wed 30 Mar 2011 01:00:02 AM UTC, comment #7:
Octave has been changed to behave like Matlab for this instance. The changeset is here (http://hg.savannah.gnu.org/hgweb/octave/rev/ea3a4bf39048). You will need to download and build from the Mercurial repository to see this fix, or wait for the 3.4.1 release.
|
Tue 29 Mar 2011 07:19:02 PM UTC, comment #6:
I'm opening a discussion on the octave-maintainers list about the desired behavior for this boundary case.
|
Tue 29 Mar 2011 10:06:42 AM UTC, comment #5:
Before any modification, I think we should consider whether
should coincide with v for any column vector v (or with v.' for any row vector v) and any integer k. This is actually true for length(v)>=1. It is not true for v=zeros(1,0) (or v=zeros(0,1)) and k=1 in Matlab and never true in Octave. Later, the behaviour of spdiags should be the same of diag when creating matrices. This is actually not always true, both in Matlab and Octave, with the bad guys zeros(1,0) and zeros(0,1).
Marco
|
Mon 28 Mar 2011 10:42:13 PM UTC, comment #4:
> What is the Matlab behavior for the following...
Matlab says:
for all k=0,2,3,4,5,..., and
I don't think this is inconsistent.
Matlab sees ones(k,0) as a matrix, not as a vector,
so in this case, it really tries to extract the second super-diagonal and hence yields [].
On the other hand, ones(1,0) has only one singleton
dimension (0 being non-singleton), so it's a vector by definition, and diag switches to the create-a-matrix-mode.
> we are open-source numerical computing software which is
> generally compatible with Matlab, but we don't follow
> them slavishly where it doesn't appear to make sense
I see. I can only speak from a pure user's viewpoint here. At the moment, this incompatibility forces me to include another if-exists(OCTAVE_VERSION)-switch in my code. But finally, it's up to the developers to balance the reasons.
|
Mon 28 Mar 2011 06:05:07 PM UTC, comment #3:
>> Well, I remember reading somewhere that every deviation from Matlab behavior (besides extensions like #-comments, +=, etc..) is considered a bug in Octave. So valid Matlab code should run in Octave as well.
Actually, the Octave philosophy is that we are not a clone of Matlab. Rather, we are open-source numerical computing software which is generally compatible with Matlab, but we don't follow them slavishly where it doesn't appear to make sense; 100% compatibility is not the goal of Octave.
>>The cited command asks for a zero matrix whos first super-diagonal is empty. Returning [0] here seems consistent to me:
What is the Matlab behavior for the following:
If I understand their interpretation the result should be the equivalent of 'zeros (2,2)'.
|
Mon 28 Mar 2011 11:44:37 AM UTC, comment #2:
> Are there any good reasons to adopt Matlab's behavior?
Well, I remember reading somewhere that every deviation from Matlab behavior (besides extensions like #-comments, +=, etc..) is considered a bug in Octave. So valid Matlab code should run in Octave as well.
> It seems slightly bizarre that asking for the
> elements on the diagonal of an empty matrix
> should return anything other than the empty set.
Yes, but I'm not doing that. The cited command asks for a zero matrix whos first super-diagonal is empty. Returning [0] here seems consistent to me:
For k=1,2,3...
+verbose+
diag(zeros(1,k),1)
-verbose-
returns
+verbose+
zeros(k+1)
-verbose-
hence it should also do so for k=0 (as Matlab does).
|
Sat 26 Mar 2011 03:55:20 AM UTC, comment #1:
It doesn't seem to be a regression. Octave versions 3.4, 3.2.4, and 3.0.5 all return [] in this case. Perhaps the 2.9.X series returned 0, but those are very old.
Are there any good reasons to adopt Matlab's behavior? It seems slightly bizarre that asking for the elements on the diagonal of an empty matrix should return anything other than the empty set.
|
Thu 24 Mar 2011 03:32:04 PM UTC, original submission:
From a octave session:
In matlab, it looks like this:
I'm quite sure octave also returned 0 in earlier versions, so this seems to be a regression. I'm using a build from my distributor (openSUSE 11.3, Packman-repository, octave 3.4.0-1.pm.1.7).
|