[Rd] [R] Semantics of sequences in R

[Berwin A Turlach]

On Mon, 23 Feb 2009 20:27:23 +0100
Wacek Kusnierczyk <Waclaw.Marcin.Kusnierczyk at idi.ntnu.no> wrote:

> Berwin A Turlach wrote:

> >> [...]
> >> 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. 
> >   
> 
> i apologize, [...]

Apology accepted.

[...]
> >>> 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?
> 
> as i said, you seem to have a severe bug in thinking about
> collaborative development.
> 
> i am sending *no* patch for this.  the issue has to be first discussed
> on the design level, and only then, if accepted, should anyone -- me,
> for example -- make an attempt to implement it.  tell me you want to
> listen to what i have to say, and we can discuss.  

I could tell you that I will listen and we can discuss this until the
cows come home.  This will not change one iota since neither of us have
the power to implement changes in R.  You keep barking up the wrong
tree.  

So far I have seen only one posting of an R-core member in this thread
(but perhaps he has started further discussion on the R-core mailing
list to which we are not privy), but if you want to have discussion and
acceptance before you do anything, you have to get R core involved.

Since for the kind of work for which I am using R a facility for
sorting lists is not crucial, I am rather indifferent about whether
such a facility should exist and, if so, how it should be designed.

> telling me i have a chip on my shoulder is rather unhelpful.

Well, then stop acting as if you are running around with chips on your
shoulders.  Behaving in such a manner is rather counter productive in
the R community (at least from my experience/observation).  The same
with publicly stating that you do certain things with the purpose of
annoying certain persons.  I am just pointing out that your behaviour
is counter productive but it is really up to you on whether you change
or want to continue in your ways.

There is a nice German proverb that sums all this up "wie man in den
Wald reinruft so schallt es heraus".  Unfortunately, an equivalent
English proverb does not exist, but perhaps the Norwegians have
something similar....

> <snip>
> >   
> >>> 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. 
> 
> how many such mails have you seen?  

A few over the years, but the more R progresses/matures the less of
such e-mail happens.

> i've been on r-devel for six months, and haven't seen many.  

Well, six month is a rather narrow sampling window....

> on the other hand, i have seen quite a few responses that were
> bashing a user for reporting a non-existent bug or submitting an
> annoying patch.

In didactic terms those are "negative motivations/reinforcements";
opinion differ on how effective they are to reach certain learning
outcomes.   

> > 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.
> >   
> 
> it has been fixed immediately by martin. 

Yes, and, again, you could not help yourself telling the developers
what you think they should do, could you?  As I try to tell you, that
is not the way it works.  R comes already with extensive tests that are
run with "make check".  If you think some are missing, you could send a
script and propose that they are included.  But telling others that
they should write such tests is unlikely to make it happen.

> a few months back my immediate reaction would be to send a bug
> report. what i have learned here, though, is that first you send a
> polite question, because the word 'bug' makes you hot.

I do not remember that people have been criticised for calling a bug a
bug when reporting it; especially not if a patch to fix the bug was
included.  

Reporting documented behaviour as bug is a totally different matter.  
  
[...]
> you should start developing in malbolge instead of r. 

Once you bring that system onto the level of R with the functionality I
need, I might consider this.

Best wishes,

	Berwin