[Rd] [R] Semantics of sequences in R

[Wacek Kusnierczyk]

Berwin A Turlach wrote:
>
>> 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 ....
>
>   

sure.  this would be a rewrite rather than a modification, though.  but
surely a possibility.  thanks for pointing this out.

>>> 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. 
>   

you're right.  they're willing to rely on the existing design, often
unconscious of its flaws. 


>   
>> [...]
>> 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, this was an unacceptably imprecise expression, which i
realized too late.  i meant that you must have never used sorting
routines in a language from the class that r purports to belong to --
high level functional programming languages.  i was sort of clear than
you must have used c and fortran, and i had no intention to say that you
haven't used *any* other language.

for your interest, here are two relevant examples.  scheme is older than
r, and yet already its developers got the idea that lists of arbitrary
objects could be subject to sorting (by whatever magic).  you only need
to provide a comparator, e.g.:

    mit-scheme <<< "(sort (list 1 '(2 3) (lambda () '())) (lambda (x y)
(> (random 2) 0)))"
    # (#[compound-procedure] (2 3) 1)

(which is a convoluted approach to using sort to actually scramble the
list.)  see, e.g., sec. 7.9 miscellaneous list operations in the mit
scheme reference manual [1].

python folks -- be it guido van rossum or whoever else -- have gone even
further, letting you sort lists of arbitrary items with a default
comparator:

    python <<< 'print sorted([1, (2, 3), lambda x: x])'
    # [1, <function <lambda> at 0x81a1f44>, [2, 3]]

the point being:  when you're trying to sell the idea that sorting lists
of arbitrary items is a silly idea, it's silly.

[1] http://www.gnu.org/software/mit-scheme/documentation/mit-scheme-ref/


> [...]
>   
>>> 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.  telling me i have a
chip on my shoulder is rather unhelpful.


> [...]
>   
>>> 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.
>   

obviously, i can judge only from what you write. 


<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?  i've been on r-devel for six months,
and haven't seen many.  (maybe i just haven't noticed.)
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.


>   
>> 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).  
>   

well, conscious people choose the way they respond to others.


> 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.
>   

it has been fixed immediately by martin. 

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.

>   
>> 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.
>   

no, it was a general reflection.

> 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.
>   

objection.  exactly the same as to 'when in norway act as norwegians'.


>   
>>>>>> 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.
>   

you should start developing in malbolge instead of r.  your users would
undoubtedly gain immense understanding.

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

it would be without me, and you'de be able to continue your great work
in piece.  maybe it's worth it?

vQ