[Top][All Lists]

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

Re: more diag() changes

From: Rik
Subject: Re: more diag() changes
Date: Tue, 29 Mar 2011 18:01:13 -0700

On 03/29/2011 03:23 PM, John W. Eaton wrote:
> On 29-Mar-2011, Rik wrote:
> | There is a bug open regarding the behavior of diag when the input vector
> | has a null dimension (https://savannah.gnu.org/bugs/?32901).  From the
> | documentation it seems that diag(x) should build a diagonal matrix from x
> | if x is a vector.  When x is a matrix then diag should extract the diagonal
> | instead.  Under the current code there is a corner case if the input is 1x0
> | or 0x1.  Octave always returns the empty matrix.  However, Matlab treats
> | this as a vector (albeit empty) and can return a matrix when the second
> | argument to diag is not zero.  For example, under Matlab
> | diag (ones (1, 0), 2)
> | => 0 0
> |    0 0
> | This makes sense to me, as the user is requesting to put an empty vector on
> | the second super-diagonal and that would be equivalent to zeroes (2,2).
> | The attached patch changes the behavior of diag to match that of Matlab,
> | but do people agree that it makes sense in this case?
> I've never liked that diag does two conflicting tasks, but there's not
> much we can do about that.  The behavior might as well match Matlab in
> this case.  I suppose I didn't realize that a 1x0 or 0x1 array would
> be considered a vector.
> | The attached patch passes 'make check' except for 1 regression in
> | wilkinson.m that would need examination.
> I think the following change should be made to wilkinson.m.
I applied both my patch and yours.  While looking at diag.cc in
src/DLD-FUNCTIONS I see that there is a completely undocumented 3-input
form of diag [diag (v,r,c)] which apparently creates a diagonal matrix from
the vector v and then immediately resizes it to size (r, c).  Can we ditch
this?  I just commented out the code and the only thing that failed were
explicit %!tests in diag.cc.  Nothing else in the code base seems to use it
and Matlab doesn't support this calling form either.


> jwe

reply via email to

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