[Rd] several bugs (PR#918) lists and matrices

John Chambers jmc@research.bell-labs.com
Tue, 24 Apr 2001 10:02:18 -0400 (EDT)

> Date: Mon, 23 Apr 2001 15:51:48 -0700 (PDT)
> From: Thomas Lumley <tlumley@u.washington.edu>
> cc: <r-devel@stat.math.ethz.ch>
> Sender: owner-r-devel@stat.math.ethz.ch
> Precedence: SfS-bulk
>
> On 24 Apr 2001, Peter Dalgaard BSA wrote:
>
> > Thomas Lumley <tlumley@u.washington.edu> writes:
> >
> > > This is a more difficult question.  You can't put a list into a matrix.
> > > Matrices handle homogenous data; they are vectors with a dimension
> > > attribute.  Lists with an arbitrary dimension attribute are, as Rob
> > > pointed out, an unimplemented bug.

The original idea of a matrix in S was that it was a vector with a
dim attribute (in fact, just a special case of an array, when the
length of the dim was 2).

In S (S3, or any other vintage) a "list" is a vector, so in the sense
of an array it is "homogeneous" enough to be a matrix.  Of course,
it's a vector where each element can be an arbitrary object, which
makes the code for printing and other things trickier.

In R, there are two kinds of "list" objects.  And the implementation
is much more indebted to the Lisp family of languages.  A list in the
traditional sense of an object with a head and a tail is very useful
for recursive computations, but not (IMO) particularly suitable to
be treated as an S vector, let alone a matrix.

So, part of the difficulty may be terminology.  It's only the S sense
of "list" that is likely to be useful as a matrix or array.

> > Ummm. I'd have to say that it is an implemented bug if a bug at all.
> > tapply() does this all the time (although most often by accident), and
> > is even documented to do so. If one can have a list with a dim(), not
> > being able to index such a beast does look like a bug to me...
>
> Strange. I had assumed that an array of mode list looked like a vector of
> LISTSXPs, but it seems that it looks like a list with dimensions.
>
> You can index it, with [[]]
> > a<-list(1,2,3,4)
> > dim(a)<-c(2,2)
> > a
>      [,1]        [,2]
> [1,] "Numeric,1" "Numeric,1"
> [2,] "Numeric,1" "Numeric,1"
> > a[2,1]
> [[1]]
> NULL
>
> > a[[2,1]]
> [1] 2
> which is weird. The question is then what a[2,1] thinks it's
> returning.

Gee, it doesn't seem weird to me :-)

Each element of a is a numeric vector.  Any [[]] operation returns a
single element, namely the numeric vector.

The natural interpretation of single [] is that it operates to return
a vector (in general, optionally still an array if a rectangular
subset is selected) of the same mode as the original; i.e., in the
case of a[2,1] presumably a list of length 1 containing a numeric
vector (accidentally, also of length 1).

>
> You still can't stick a list into an array of numbers, which is what Rich
> needs, and is better handled with data frames.

Yes, I'd agree (pending a convincing example) that fixing bugs for
traditional S arrays of mode list is not a high priority item.

We're in the process of discussing data frames and where they might go
in the future.  That would be a good context for examining whatever
practical needs people have.

> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
> r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
> Send "info", "help", or "[un]subscribe"
> (in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
> _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
>

John

--
John M. Chambers                  jmc@bell-labs.com
Bell Labs, Lucent Technologies    office: (908)582-2681
700 Mountain Avenue, Room 2C-282  fax:    (908)582-3340
Murray Hill, NJ  07974            web: http://www.cs.bell-labs.com/~jmc
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._