Re: [Rd] [R] Semantics of sequences in R

From: Berwin A Turlach <>
Date: Tue, 24 Feb 2009 00:12:47 +0800

On Mon, 23 Feb 2009 13:27:08 +0100
Wacek Kusnierczyk <> wrote:

> Berwin A Turlach wrote:
> <snip>
> >> can you give one concrete example, and suggest how to estimate how
> >> much old code would involve the same issue?
> >>
> >
> > Check out the svn source of R, run configure, do whatever change you
> > want to sort.list, "make", "make check FORCE=FORCE". That should
> > give you an idea how much would break.
> >
> it's not just making changes to sort.list, berwin. sort.list calls
> .Internal order, and this one would have to be modified in order to
> accommodate for the additional comparator argument. [...]

Well, you could start of with an R only implementation and then start to move things to compiled code as needed for efficiency ....

> > Additionally, you could try to install all CRAN packages with your
> > modified version and see how many of them break when their
> > examples/demos/&c is run.
> >
> that's not a good benchmark; this are third-party stuff, and where
> people are willing to rely on poor design they should be prepared to
> suffer. [...]

I do not believe that those developers are relying on poor design. Rather, they rely on things to work as documented (and how they are used for them to work) and that the behaviour is not gratuitously changed just because it is considered bad design by some.

> [...]
> judging from your question, you couldn't possibly see sorting routines
> in other languages.

Quite likely, or the other languages that I regularly use (C, Fortran) have even more primitive sorting facilities.

> > No, if that is what you want. And I guess it is one way of sorting
> > a list. The question is what should be the default way?
> one possible answer is: none. (i have already given this answer
> previously, if you read carefully it's still there). sort.list
> *should* demand an additional comparator argument. at least, it
> should demand it if the argument to be sorted is a list, rather than
> a non-list vector (if you still need to use sort.list on non-lists).

So when are you sending your patch to implement this facility?

> > The point is rather that by commenting only one will not achieve
> > much, in particular if the comments look more like complaints and
> > the same comments are done again and again (along with dragging up
> > previous comments or comments received on previous comments).
> >
> again and again because you seem to be immune to critique.

You obviously do not know me.

> open you mind, and it will suffice complain just once. besides, i am
> certainly *not* just complaining. i am providing concrete arguments,
> examples, and suggestions. you're being unreasonably unfair.

I gladly admit that I am not reading every thread in which you are active, so these comments might have been based on a biased a sample.

> > R is open source. Check out the svn version, fix what you consider
> > needs fixing, submit a patch, convince R core that the patch fixes a
> > real problem/is an improvement/does not break too much. Then you
> > have a better chance in achieving something.
> no, berwin. this is a serious bug in thinking. people should be
> allowed -- *encouraged* -- to discuss the design *before* they even
> attempt to write patches.

And what makes you believe this is not the case? I have seen over the years e-mails to R-devel along the lines "I am thinking of a change along [lots of details and reasoning for the change]; would patches that implement this be accepted?" and these e-mails were discussed more often than not. However, in the end, the only people who can commit changes to the R code are the members of R-core, thus they will have the final word of design issues (and, as I assume, they discuss, among other things, design issues on the private mailing list of R-core member). But you can discuss this issues before writing a patch.

> writing one patch which will never be considered -- well, never
> responded to -- is about enough to stop people from sending patches.

While it is unfortunate if this happens, and such persons might just be too thin-skinned, worse can happen; e.g. being flamed for sending in a patch that is considered not to address any problems and with a sloppy description of what it tries to address (happened to me).

Yes, patches are ignored; patches are gratefully acknowledged and applied; patches are completely re-written and still attributed to the provider of the patch... That does not mean that I stop sending in a patch if I feel it is warranted...

And I am sure that if you had sent an e-mail to r-devel pointing out that the binary operator <, when called in the non-standard way '<'(1,2,3), does not check the number of arguments while other binary operators (e.g. '+'(1,2,3) or '*'(1,2,3)) do such checks, and provided a patch that implemented such a check for '<' (and presumably other comparison operators), then that patch would have been acknowledged and applied.

> maybe that's what you want, anyway -- the fewer incoming patches the
> more you're entitled to think your product is just great.

If the "you"s and "your" are referring to me, then you are completely off track.

IIRC, this discussion started off because I was not enthused of having words put into my month in a public forum. But then it turned into another opportunity to correct your misunderstandings about the ways in which the R community works. Let me assure you, one you figure that one out, you will be able to interact more productively/satisfactorily with that community. And, again, it does not help to say "this is how the culture should be and I behave as if it is this way". As the saying goes, when in Rome do as the Romans.

> >>>> scary! it's much preferred to confuse new users.
> >>>>
> >>> I usually learn a lot when I get confused about some
> >>> issues/concept. Confusion forces one to sit down, think deeply
> >>> and, thus, gain some understanding. So I am not so much
> >>> concerned with new users being confused. It is, of course, a
> >>> problem if the new user never comes out of his or her confusion.
> >>>
> >> the problem, is, r users have to learn lots [...]
> >>
> >
> > Indeed, and I guess in this age of instant gratification that that
> > is a real bummer for new users.
> >
> why be rude to your users? "I am not so much concerned with new users
> being confused." is an explanation -- but maybe you really should?

As I said, I believe confusion is a great way of gaining understanding and knowledge and in that sense I am not so much concerned with new users being confused. I acknowledged that it is a problem if they never come out of their confusion.

Also, r-help would only be half the fun without confused (new) users. :)


        Berwin mailing list Received on Mon 23 Feb 2009 - 15:20:46 GMT

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Mon 23 Feb 2009 - 19:31:36 GMT.

Mailing list information is available at Please read the posting guide before posting to the list.

list of date sections of archive