Skip to content

peculiar matrices

6 messages · Marc Schwartz (via MN), Bert Gunter, Gabor Grothendieck +2 more

Original
Ben Bolker
# 
As far as I can tell from reading The Fine Documentation
(R Language Definition and Intro to R), matrices are supposed
to be of homogeneous types.  Yet giving matrix() an inhomogeneous
list seems to work, although it produces a peculiar object:

v = list(1:3,4,5,"a")
m = matrix(v,nrow=2)
m

     [,1]      [,2]
[1,] Integer,3 5
[2,] 4         "a"


m[1,]

[[1]]
[1] 1 2 3

[[2]]
[1] 3

 (this is R 2.1.1, running under Linux)
  Should there be a check/error? Or is this just analogous to
the joke about going to the doctor and saying "it hurts when
I do this", and the doctor saying "well then, don't do that"?

  Ben Bolker
Marc Schwartz (via MN)
#
On Fri, 2005-10-21 at 21:32 +0000, Ben Bolker wrote:
Ben,

If you review the structure of 'm' note:
List of 4
 $ : int [1:3] 1 2 3
 $ : num 4
 $ : num 5
 $ : chr "a"
 - attr(*, "dim")= int [1:2] 2 2

that it is actually a list, even though:
[1] "matrix"


Also:
[1] "list"
[1] "list"


If you remove the dim attributes, you get:
[[1]]
[1] 1 2 3

[[2]]
[1] 4

[[3]]
[1] 5

[[4]]
[1] "a"


So I would argue that it is consistent with the documentation in that,
while the printed output is that of a matrix, it is a list, which of
course can handle heterogeneous data types.

This is Version 2.2.0 Patched (2005-10-20 r35979).
Maybe more like:

"Doctor, my eye hurts when I drink my tea." and the doctor says, "Well,
remove the spoon from the cup before you drink."

;-)

Regards,

Marc Schwartz
Bert Gunter
# 
matrix coerces it's arguments to a single mode first. Try mode(m) -- iit's a
list (with a dim attribute). If you print each entry of m separately, you'll
find they're all lists.

As the docs say, if either of nrow or ncol aren't given, it tries to "infer"
what they should be from the data and other parameter. Haven't a clue what
the algorithm does, but given your data, it made a guess. What would you
have wanted it to give that makes any more sense?

-- Bert Gunter
Genentech Non-Clinical Statistics
South San Francisco, CA
 
"The business of the statistician is to catalyze the scientific learning
process."  - George E. P. Box
Gabor Grothendieck
# 
The reference manual of 2.2.0 says in section
2.2 that "Matrices and arrays are simply vectors
with the attribute dim and optionally dimnames."

Now earlier in section 2.1 it discusses vectors
and I think that that is where the confusing part lies.
Section 2.1 starts out saying that "Vectors
can be thought of as contiguous cells containing
homogeneous data." and that "R has six basic
('atomic') vector types: logical, integer, real,
complex, string (or character) and raw".   There
is no inkling yet that this is an incomplete
thought.

Its only later in the section that we find out that
atomic vectors are only one sort of vector: "Lists
are vectors, and the basic vector types are
referred to as atomic vectors where it is
necessary to exclude lists."

I think this section should be rewritten to
clearly state up front that there are atomic
vectors and generic vectors and then define each
of these.
On 10/21/05, Ben Bolker <bolker at ufl.edu> wrote:
Brian Ripley
# 
Just to add to what others have said, don't confuse how an object is 
printed with its structure.  This must be intentional as the internal code 
has a specific section just to print list arrays/matrices.

?matrix has the first argument as

     data: an optional data vector.

and a list is a vector.


I did find the following incorrect statement in R-lang:

   As the elements of a vector or matrix must be of the same type there are
   multiple types of @code{NA} values.

That is missing `atomic' before `vector'.  Some parts of the R 
documentation were written before lists were vectors and so assume vectors 
are atomic, but instances of that assumption as rare nowadays.  If you 
find one, please report it.
On Fri, 21 Oct 2005, Ben Bolker wrote:

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    
1 day later

    

      
      

        


  

        

      Ben Bolker
    

    

      
      #
    

  


  

      
thanks all; this makes sense now.  For what
it's worth, this came up in the context of
mapply(...,SIMPLIFY=TRUE), which returned a
matrix as requested, but an odd-looking one.

  cheers
    Ben Bolker