[R] R imperfections? -- was: repeated searching of no-missing values

[Bert Gunter]

Replies inline below.

Best regards,
-- Bert
_______________________________


From: macrakis at gmail.com [mailto:macrakis at gmail.com] On Behalf Of Stavros
Macrakis
Sent: Thursday, December 11, 2008 10:53 AM
To: Bert Gunter
Cc: Patrizio Frederic; r-help at r-project.org
Subject: Re: [R] repeated searching of no-missing values


On Wed, Dec 10, 2008 at 6:39 PM, Bert Gunter <gunter.berton at 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.

****
Rationale? -- you'll have to ask the developers. As for deprecating (or
changing) tapply: do you have any idea how much code that could break?! I
think that is probably a wholly unrealistic suggestion.

The way forward is through efforts like Hadley's plyr package.  Among other
things, that's what packages are for. Indeed, as you probably know, packages
like R.oo and proto allow one to use a whole different programming
language/paradigm within R, while still taking advantage of all of R's
existing built-in functionality. Except for possible performance penalties,
I don't see how you can ask for much more than that.

So, no, R is certainly not perfect. I'm sure that if they could go back 20
years with today's knowledge and experience, the developers would do some
things differently. That's life -- and progress! But I think any objective
assessment -- and certainly those of us who use it day in and day out in our
work -- would consider R a truly amazing software product, warts or no. 

Hence, may I suggest that instead of merely pointing out its (often well
known,btw) imperfections and inelegancies,  you instead move to the
developers' forum and contribute improvements. This is, I believe, a
standard way for people with programming expertise like yourself to
contribute to open source development. Although the developers may be a bit
crotchety at times (I think often appropriately so given the extraordinary
effort they've put in), I think you would find that they would welcome
sincere efforts to help them improve R.

***



	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.
***
Of course!
***
 

	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.

***
No doubt. That's progress. Are you going to write this future version? I
certainly am not -- and CAN not (being a bear of but little brain)!
***

           -s