On 11/08/2014, 10:26 AM, Martin Maechler wrote:
>>>>>> Duncan Murdoch <murdoch.dun...@gmail.com>
>>>>>> on Fri, 8 Aug 2014 10:51:10 -0400 writes:
>
> Thank you, Duncan (read inline)
>
> > On 07/08/2014, 4:51 AM, Martin Maechler wrote:
> >> This is not at all something new(*). As maintainer of the
> >> Matrix package, I don't like this inconsistency of base
> >> R's diag(). We have had the following -- forever, almost
> >> surely inherited from S and S+ :
> >>
> >> diag(x) preserves the storage mode of x for 'complex' and
> >> 'double' precision, but converts integer and logicals to
> >> double :
> >>
> >> > storage.mode(x <- 1i + 1:7); storage.mode(diag(x)) [1]
> >> "complex" [1] "complex" > storage.mode(x <- 0 + 1:7);
> >> storage.mode(diag(x)) [1] "double" [1] "double"
> >>
> >> > storage.mode(x <- 1:7); storage.mode(diag(x)) [1]
> >> "integer" [1] "double" > storage.mode(x <- 1:7 > 3);
> >> storage.mode(diag(x)) [1] "logical" [1] "double"
> >>
> >> and so it is actually a bit cumbersome (and a memory
> >> waste in the case of large matrices) to create a diagonal
> >> integer or logical matrix.
> >>
> >> The help page does not mention the current behavior,
> >> though you may say it alludes to the fact that logicals
> >> are treated as 0/1 implicitly (**)
> >>
>
> > I think the change to preserve integer makes sense, but
> > preserving logical does not. A diagonal matrix has zeros
> > off the diagonal, and they are not logical.
>
> That's true if you come from the usual mathematical thinking
> about matrices; and the same would extend to triangular
> matrices, too.
I'm not objecting to having a logical matrix, I'm objecting to saying
that a matrix with FALSE off the diagonal is a diagonal matrix. A
diagonal matrix is one with zeros off the diagonal.
>
> In (S and) R however, matrices and array()s have always been
> more general than in applied math (and have allowed any atomic (and even
> more general) content).
>
> > Having diag() sometimes return a matrix with FALSE off the diagonal just
> > looks wrong.
>
> [... if you have never seen them ..]
> OTOH, sparse matrices (in the Matrix package) and also sparse
> and dense triangular matrices (all with their classes) have
> always (in the Matrix package) had their logical counter parts,
>
> > Diagonal(5)
> 5 x 5 diagonal matrix of class "ddiMatrix"
> [,1] [,2] [,3] [,4] [,5]
> [1,] 1 . . . .
> [2,] . 1 . . .
> [3,] . . 1 . .
> [4,] . . . 1 .
> [5,] . . . . 1
> > Diagonal(5) > 0
> 5 x 5 diagonal matrix of class "ldiMatrix"
> [,1] [,2] [,3] [,4] [,5]
> [1,] TRUE . . . .
> [2,] . TRUE . . .
> [3,] . . TRUE . .
> [4,] . . . TRUE .
> [5,] . . . . TRUE
That is completely different, and I have no objection to it. Where I
would have an objection is if you got that result from
diag(rep(TRUE, 5))
or
Diagonal(rep(TRUE, 5))
Duncan Murdoch
> >
>
> and if you consider any sparseness for logical matrices, typical
> application cases would have the TRUE to be rare rather than the
> FALSE... and then of course, we have had the as.numeric(<logical>)
> behavior of S and R, all this leading to
> the usual FALSE <==> 0 mapping
>
>
> >> If I change this behavior such that logical and integer x
> >> are preserved,
> >>
> >> make check-all
> >>
> >> which includes all checks, including those of all
> >> recommended packages (including Matrix!) successfully
> >> runs through; so at least base + Recommended R never
> >> relies on the current behavior, nor should any "well
> >> programmed" R code ...
> >>
> >> Hence my proposal, somewhat tentative for now, to change
> >> this diag(.) behavior.
> >>
> >> Martin Maechler
> >>
> >> *) and possibly something we "can not" change in R,
> >> because too much code implicitely may be depending on it,
> >> but now I hope we can still...
> >>
> >> **) BTW, also including the somewhat amusing case of
> >> diag(c("A","B")).
> >>
> >> ______________________________________________
> >> R-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>
>
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
