On Wed, Dec 10, 2008 at 6:39 PM, Bert Gunter <gunter.ber...@gene.com> wrote:
> ...?tapply says that the first argument is an **atomic** vector. A factor
> is not an atomic vector. So tapply interprets it as such by looking only at
> its representation, which is as integer values.
>
What is the rationale for this? If it is just backwards compatibility with
some long-ago implementation decision, perhaps tapply should be deprecated
and replaced by something cleaner (perhaps plyr). If it is something deeper
than that, it would be useful to know what.
I admit that these details are somewhat obscure and even annoying -- but
> they **are** documented.
>
No question that it is a good thing that things like this are documented.
> I think that's all we can expect. Some have lamented the lack of the
> language's perfect consistency in these matters, but I cannot understand how
> that would be possible given its nature, intended, as it is, to be
> **easily** used for high level data manipulation, graphics,statistical
> analysis etc. as well as programming.
As a general rule, consistency makes it *easier* to learn and use a
language.
> There are just too many possible data structures to expect logical
> consistency in their handling throughout...
I am not sure what you mean here. There has been a lot of work in the
programming language community on consistent handling of abstract structures
of various types. Some of their insights may be applicable to future
versions of R.
-s
[[alternative HTML version deleted]]
______________________________________________
R-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
