This is another example of the general preference of the designers of R for
convenience over consistency.
In my opinion, this is a design flaw even for non-programmers, because I
find that inconsistencies make the system harder to learn. Yes, the naive
user may stumble over the difference between m[[1,1]] and m[1,1] a few times
before getting it, but once he or she understands the principle, it is
general.
-s
On Fri, May 29, 2009 at 5:33 PM, Jason Vertrees <j...@cs.dartmouth.edu> wrote:
> Hello,
>
> First, let me say I'm an avid fan of R--it's incredibly powerful and I
> use it all the time. I appreciate all the hard work that the many
> developers have undergone.
>
> My question is: why does the paradigm of changing the type of a 1D
> return value to an unlisted array exist? This introduces boundary
> conditions where none need exist, thus making the coding harder and
> confusing.
>
> For example, consider:
> > d = data.frame(a=rnorm(10), b=rnorm(10));
> > typeof(d); # OK;
> > typeof(d[,1]); # Unexpected;
> > typeof(d[,1,drop=F]); # Oh, now I see.
>
> This is indeed documented in the R Language specification, but why is it
> there in the first place? It doesn't make sense to the average
> programmer to change the return type based on dimension.
>
> Here it is again in 'sapply':
> > sapply
> > function (X, FUN, ..., simplify = TRUE, USE.NAMES = TRUE)
> > {
> > [...snip...]
> > if (common.len == 1)
> > unlist(answer, recursive = FALSE)
> > else if (common.len > 1)
> > array(unlist(answer, recursive = FALSE),
> > dim = c(common.len,
> > length(X)), dimnames = if (!(is.null(n1 <-
> > names(answer[[1]])) &
> > is.null(n2 <- names(answer))))
> > list(n1, n2))
> > [...snip...]
> > }
>
> So, in 'sapply', if your return value is one-dimensional be careful,
> because the return type will not the be same as if it were otherwise.
>
> Is this legacy or a valid, rational design decision which I'm not yet a
> sophisticated enough R coder to enjoy?
>
> Thanks,
>
> -- Jason
>
> --
>
> Jason Vertrees, PhD
>
> Dartmouth College : j...@cs.dartmouth.edu
> Boston University : jas...@bu.edu
>
> PyMOLWiki : http://www.pymolwiki.org/
>
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
