[Rd] [R] Semantics of sequences in R

[Berwin A Turlach]

On Mon, 23 Feb 2009 13:27:08 +0100
Wacek Kusnierczyk <Waclaw.Marcin.Kusnierczyk at idi.ntnu.no> 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. :)

Cheers,
	
	Berwin