>>>>> "Jim" == Jim Lindsey <jlindsey at
alpha.luc.ac.be> writes:
Jim> I am still struggling with broken libraries after the changes in
Jim> lists in 0.63 (as is my son who says he has abandoned lists
Jim> altogether!). A user can supply a vector (say one time series), a
Jim> matrix (several series as balanced repeated measures), or a list
Jim> (unbalanced repeated measures). I used to check with is.vector,
Jim> is.matrix, and is.list. This no longer works because a list is now
Jim> a vector.
This is not different from S...
There really is a terminology problem hidden here which uses to confuse
(almost) everyone from time to time :
What is a "vector"? <<-->> "How should
as.vector() / is.vector() behave?
~~~~~~~~~~~~~~~~~~~
1) For most people with some math background, it is very natural that
c(2,3,5) or c("A","BC", "DE") is a vector.
2) Then one learns that the S language
[in the broad ESS sense, R being a dialect, S3 and S4 as well],
allows for names (often called "tags" R internally],
one would expect that c(a=2,b=3,c=5) is a vector as well, namely just
c(2,3,5) with a names attribute.
However, in S 3 and S 4,
3) a "vector" is a ``simple object'' in the sense of S, i.e.
is.vector(c(a=2)) #>> FALSE
whereas it stil gives TRUE in R [0.63.1]. However, we have been having a
hot and not yet resolved discussion within the R core team on whether
we want to keep it as it is now...
[[And yes, there are more problems with as.vector() / is.vector()]]
Maybe we should discuss this more in the R-devel mailing list.
Even more `strangely' in the sense of "1)" above,
is.vector(list(1, list(3, list(4:6)))) ## >> TRUE
in S 3 or S 4, and now also in R 0.63 [but not in R 0.62].
Another argument for this behavior is the R (and S?) internal
implementation of list()s, as so called ``generic vectors''.
I.e., here "vector" is used as ``generic vector''.
BTW: ?is.vector in S-plus 5.0 (rel2) contains
>> BUGS:
>> A list may have names and still test TRUE with is.vector,
>> but atomic objects with names will test FALSE.
What I don't know if this is a bug that anyone [JMC?] plans to fix or one
that has been in place for ever (in S) and will be kept (in S) for backwards
compatibility ((and I personally would really not want to adopt in R))...
In (partial) summary, we currently have
( ll <- list(a=1, list(b=3, list(cc=4:6))) )
( vv <- unlist(ll, recursive = TRUE) )
is.vector(ll) # TRUE
is.vector(vv) # FALSE in S [incl. S+5 rel 2] TRUE in R
-----------------------------------
Jim> The vector must allow calculations so can be integer,
Jim> double, or logical. So I set the mode in is.vector. Try the
Jim> following:
Jim> mode(c(23,42))
# "numeric"
typeof(c(23,42))
or storage.mode(c(23,42))
both give
"double"
[which is compatible to S 3 (S+ 3.x, 4.x)
but not S 4 (S+ 5.0++) which now uses integer for integer
literals]
Jim> is.vector(c(23,42),mode="numeric")
FALSE
This *is* a bug, [and not the only with is.vector/as.vector, see above].
However,
> is.vector(c(23,42),mode="numeric")
TRUE
Jim>
is.vector(c(23,42),mode=c("integer","double","logical"))
Jim> Of course, in 0.62.4, things were no more coherent than this;
Jim> is.vector(list(1))
Jim> is.vector(list(1),mode="list")
---
As a matter of fact, my current recommendation:
Don't use is.vector() at all at least not until we [and the S authors?]
know what is desired?
Instead, use
is.list()
and/or is.atomic() is.recursive() is.array()
Martin Maechler <maechler at stat.math.ethz.ch>
http://stat.ethz.ch/~maechler/
Seminar fuer Statistik, ETH-Zentrum SOL G1; Sonneggstr.33
ETH (Federal Inst. Technology) 8092 Zurich SWITZERLAND
phone: x-41-1-632-3408 fax: ...-1086 <><
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-help 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-help-request at
stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._