Re: [Rd] as.vector() broken on a matrix or array of type "list"
> Hervé Pagès
> on Tue, 25 Sep 2018 23:27:19 -0700 writes:
> Hi, Unlike on an atomic matrix, as.vector() doesn't drop
> the "dim" attribute of matrix or array of type "list":
>m <- matrix(list(), nrow=2, ncol=3)
>m
># [,1] [,2] [,3]
># [1,] NULL NULL NULL
># [2,] NULL NULL NULL
>
>as.vector(m)
># [,1] [,2] [,3]
># [1,] NULL NULL NULL
># [2,] NULL NULL NULL
as documented and as always, including (probably all) versions of S and S-plus.
>is.vector(as.vector(m))
># [1] FALSE
as bad is that looks, that's also "known" and has been the case
forever as well...
I agree that the semantics of as.vector(.) are not what you
would expect, and probably neither what we would do when
creating R today. *)
The help page {the same for as.vector() and is.vector()}
mentions that as.vector() behavior more than once, notably at
the end of 'Details' and its 'Note's
... with one exception where you have a strong point, and the documenation
is incomplete at least -- under the heading
Methods for 'as.vector()':
... follow the conventions of the default method. In particular
...
...
...
• ‘is.vector(as.vector(x, m), m)’ should be true for any mode ‘m’,
including the default ‘"any"’.
and you are right that this is not fulfilled in the case the
list has a 'dim' attribute.
But I don't think we "can" change as.vector(.) for that case
(where it is a no-op).
Rather possibly is.vector(.) should not return FALSE but TRUE -- with
the reasoning (I think most experienced R programmers would
agree) that the foremost property of 'm' is to be
- a list() {with a dim attribute and matrix-like indexing possibility}
rather than
- a 'matrix' {where every matrix entry is a list()}.
At the moment my gut feeling would propose to only update the
documentation, adding that one case as "an exception for historic reasons".
Martin
-
*) {Possibly such an R we would create today would be much closer to
julia, where every function is generic / a multi-dispach method
"a la S4" and still be blazingly fast, thanks to JIT
compilation, method caching and more smart things.}
But as you know one of the strength of (base) R is its stability
and reliability. You can only use something as a "the language
of applied statistics and data science" and rely that published
code still works 10 years later if the language is not
changed/redesigned from scratch every few years ((as some ... are)).
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Stability and reliability of R (comment on Re: as.vector() broken on a matrix or array of type "list")
With regard to Martin's comment about the strength of (base) R:
I have R code I wrote 15+ years ago that has been used regularly ever since
with only a few minor changes needed due to changes in R. Within that code, I
find particularly impressive for its stability a simple custom GUI that uses
the tcltk package that has needed no updates whatsoever in all that time.
Such stability and reliability have been extremely valuable to me.
-Don
--
Don MacQueen
Lawrence Livermore National Laboratory
7000 East Ave., L-627
Livermore, CA 94550
925-423-1062
Lab cell 925-724-7509
On 9/26/18, 12:41 AM, "R-devel on behalf of Martin Maechler"
wrote:
[-- most of original message omitted, so as to comment on the following --]
-
*) {Possibly such an R we would create today would be much closer to
julia, where every function is generic / a multi-dispach method
"a la S4" and still be blazingly fast, thanks to JIT
compilation, method caching and more smart things.}
But as you know one of the strength of (base) R is its stability
and reliability. You can only use something as a "the language
of applied statistics and data science" and rely that published
code still works 10 years later if the language is not
changed/redesigned from scratch every few years ((as some ... are)).
__
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
Re: [Rd] Stability and reliability of R (comment on Re: as.vector() broken on a matrix or array of type "list")
On 2018-09-26 10:32, MacQueen, Don via R-devel wrote:
With regard to Martin's comment about the strength of (base) R:
I have R code I wrote 15+ years ago that has been used regularly ever since
with only a few minor changes needed due to changes in R. Within that code, I
find particularly impressive for its stability a simple custom GUI that uses
the tcltk package that has needed no updates whatsoever in all that time.
Such stability and reliability have been extremely valuable to me.
How much of R's stability is due to the unit tests encouraged by
the examples in the help pages, the vast majority of which are run
repeatedly with each new change?
More generally, what are the lessons the computer science
discipline can take from R's experience in this regard?
I discussed this eight years ago in an article on "Package
development process" that I posted to Wikipedia eight years ago that
has attracted 9 views per day since. I also added a table discussing
this to the Wikipedia article on "Software repository". That article has
attracted over 300 views per day for at least the past 3 years. Both
these articles could doubtless be improved by someone more knowledgeable
than I.
Many thanks and kudos to Ross Ihaka, Bob Gentleman, Martin
Maechler and the rest of the R Core team, who have managed this project
so successfully for more than two decades now.
Spencer Graves
-Don
--
Don MacQueen
Lawrence Livermore National Laboratory
7000 East Ave., L-627
Livermore, CA 94550
925-423-1062
Lab cell 925-724-7509
On 9/26/18, 12:41 AM, "R-devel on behalf of Martin Maechler"
wrote:
[-- most of original message omitted, so as to comment on the following --]
-
*) {Possibly such an R we would create today would be much closer to
julia, where every function is generic / a multi-dispach method
"a la S4" and still be blazingly fast, thanks to JIT
compilation, method caching and more smart things.}
But as you know one of the strength of (base) R is its stability
and reliability. You can only use something as a "the language
of applied statistics and data science" and rely that published
code still works 10 years later if the language is not
changed/redesigned from scratch every few years ((as some ... are)).
__
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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] as.vector() broken on a matrix or array of type "list"
Hi Martin,
On 09/26/2018 12:41 AM, Martin Maechler wrote:
Hervé Pagès
on Tue, 25 Sep 2018 23:27:19 -0700 writes:
> Hi, Unlike on an atomic matrix, as.vector() doesn't drop
> the "dim" attribute of matrix or array of type "list":
m <- matrix(list(), nrow=2, ncol=3)
m
# [,1] [,2] [,3]
# [1,] NULL NULL NULL
# [2,] NULL NULL NULL
as.vector(m)
# [,1] [,2] [,3]
# [1,] NULL NULL NULL
# [2,] NULL NULL NULL
as documented and as always, including (probably all) versions of S and S-plus.
is.vector(as.vector(m))
# [1] FALSE
as bad is that looks, that's also "known" and has been the case
forever as well...
I agree that the semantics of as.vector(.) are not what you
would expect, and probably neither what we would do when
creating R today. *)
The help page {the same for as.vector() and is.vector()}
mentions that as.vector() behavior more than once, notably at
the end of 'Details' and its 'Note's
... with one exception where you have a strong point, and the documenation
is incomplete at least -- under the heading
Methods for 'as.vector()':
... follow the conventions of the default method. In particular
...
...
...
• ‘is.vector(as.vector(x, m), m)’ should be true for any mode ‘m’,
including the default ‘"any"’.
and you are right that this is not fulfilled in the case the
list has a 'dim' attribute.
But I don't think we "can" change as.vector(.) for that case
(where it is a no-op).
Rather possibly is.vector(.) should not return FALSE but TRUE -- with
the reasoning (I think most experienced R programmers would
agree) that the foremost property of 'm' is to be
- a list() {with a dim attribute and matrix-like indexing possibility}
rather than
- a 'matrix' {where every matrix entry is a list()}.
Note that this change would break all the code around that uses
is.vector() to distinguish between an array (of mode "atomic" or
"list") and a non-array. Arguably is.array() should preferably be
used for that but I'm sure there is a lot of code around that uses
is.vector().
The bottom of the problem is that as.vector() doesn't drop attributes
that is.vector() sees as "vector breakers" i.e. as breaking the vector
nature of an object. So for example is.vector() considers the "dim"
attribute to be a vector breaker but as.vector() doesn't drop it.
So yes in order to bring is.vector() and as.vector() in agreement you
can either change one or the other, or both. My gut feeling though is
that it would be less disruptive to not change what is.vector() thinks
about the "dim" attribute and to make sure that as.vector() **always**
drops it (together with "dimnames" if present). How much code around
could there be that calls as.vector() on an array and expects the "dim"
attribute to be dropped **except** when the mode() of the array is
"list"? It is more likely that the code around that calls as.vector()
on an array doesn't expect such exception and so is broken. This was
actually the case for my code ;-)
Thanks,
H.
At the moment my gut feeling would propose to only update the
documentation, adding that one case as "an exception for historic reasons".
Martin
-
*) {Possibly such an R we would create today would be much closer to
julia, where every function is generic / a multi-dispach method
"a la S4" and still be blazingly fast, thanks to JIT
compilation, method caching and more smart things.}
But as you know one of the strength of (base) R is its stability
and reliability. You can only use something as a "the language
of applied statistics and data science" and rely that published
code still works 10 years later if the language is not
changed/redesigned from scratch every few years ((as some ... are)).
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Bug in printing array of type "list"
Hi, This array is of type "list" but print() reports otherwise: a1 <- array(list(1), 2:0) typeof(a1) # [1] "list" a1 # <2 x 1 x 0 array of character> # [,1] # [1,] # [2,] No such problem with an array of type "logical": a2 <- array(NA, 2:0) typeof(a2) # [1] "logical" a2 # <2 x 1 x 0 array of logical> # [,1] # [1,] # [2,] Thanks, H. -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
