Re: [Rd] [R] Semantics of sequences in R
On Mon, 23 Feb 2009 20:27:23 +0100 Wacek Kusnierczyk waclaw.marcin.kusnierc...@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
Re: [Rd] [R] Semantics of sequences in R
Berwin A Turlach wrote: 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. i am barking on the list; whoever is the appropriate person to react, has the chance to read and react. i don't think it's appropriate to send my messages to x or y personally. what is the right tree, you say? 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. i discussed these things with you, because you responded. this made me think you were not indifferent, but anyway i kept ccing to the list precisely because because i don't think you're the right person to make a decision or suggest the next steps. 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). why not read some fortunes? When a Certain Guru rips strips off people (God knows he's done it to me often enough) on this list, there's a damned good reason for it. -- Rolf Turner (in a discussion about whether a friendly mailing list with more 'customer service' attitude than R-help was needed) R-help (December 2003) when gurus are ripped strips off on this list, there's a damned good reason for it. (and i'm actually not doing it.) or: You may have not been long enough on this list to see that some of the old-time gurus have reached a demigod like status. Demigods have all rights to be 'rude' (that's almost a definition of a demi-deity). -- Jari Oksanen (in a discussion on whether answers on R-help should be more polite) R-help (December 2004) which certainly documents a very productive approach to communication with users. snip 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. a few over the years? i've been on r-devel for six months, and haven't seen many. Well, six month is a rather narrow sampling window your sampling window does not seem to provide better results. 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. ah, so what's the difference between the way i pinpoint design flaws and the way r gurus respond to people, so that i am running with a chip on my shoulder, and they are being 'negatively motivating/reinforcing' in didactic terms? (am i correct, is the 'negative motivation/reinforcement' the same stuff jari oksanen talked about?) 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? was this really running with a chip: shouldn't the tests have captured it? i think you should have a
Re: [Rd] [R] Semantics of sequences in R
Berwin A Turlach wrote: On Tue, 24 Feb 2009 09:39:51 +0100 Wacek Kusnierczyk waclaw.marcin.kusnierc...@idi.ntnu.no wrote: Berwin A Turlach wrote: [...] why not read some fortunes? I am well aware of those fortunes and maybe you missed the one: fortune(Watson) Getting flamed for asking dumb questions on a public mailing list is all part of growing up and being a man/woman. -- Michael Watson (in a discussion on whether answers on R-help should be more polite) R-help (December 2004) I am actually wondering where the corresponding fortunes from December 2005, December 2006, December 2007 and December 2009 are since they started of be produced on an annual basis. [...] 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. ah, so what's the difference between the way i pinpoint design flaws and the way r gurus respond to people, so that i am running with a chip on my shoulder, and they are being 'negatively motivating/reinforcing' in didactic terms? [...] Your goal is, presumably, that you want to have the design flaws fixed/discussed/c. The goal of the R gurus is to avoid having to waste their time on unproductive issues because people do not read documentation/behave contrary to how they are asked to behave/c. To reach your goal, the controversial approach is counter productive. To reach their goal, the controversial approach can be quite effective. in my opinion the point of the whole discussion could be summarized by the question, what is a design flaw? This is totally subjective, and it happens almost everywhere in life. Take human languages as an example and in particular, English. I do not know the history of the English language but I can guess at some point some people decided that the past tense for give should be gave and not gived according to the standard rule, possibly because they thought it has better acoustic. Is this a design flaw of English? Some might argue yes, maybe they would think gived does not have a that bad acoustic or they could have come up with another possibility than gave. Does this confuse new users of English? Of course it does -- I had to spent many hours learning the past tense and past particle of the irregular verbs. Should it be changed? Then almost all existing code (i.e., English texts) should be rewritten, which I think demonstrates why some people are a bit reluctant in design changes. To close I'd like to share with you a Greek saying (maybe also a saying in other parts of the world) that goes, for every rule there is an exception. The important thing, in my opinion, is that these exceptions are documented. Best, Dimitris [...] 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? was this really running with a chip: Look up what running with a chip on your shoulder means and reflect on the occasions in which I suggested to you that you give the impression of doing so. On this occasion nobody said that you were running around with a chip on your shoulder. shouldn't the tests have captured it? i think you should have a check for every feature following from the docs. to which marting responded yes, we should But he also made it clear that it would be unlikely that he or any other R-core member would write those tests and that this would probably be left to you; with any contribution being welcome. Consider yourself lucky that this exchange was with Martin, other members of R core might have communicated a similar message in quite another way. That exchange is very much confirming my understanding of the culture of the R community. 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. haven't done the thing. Come on, read your own quote above: Shouldn't the tests have captured this? I think you should have a check for every feature following from the docs, If this is not telling others that they should write such test, then what is? Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Dimitris Rizopoulos Assistant Professor Department of Biostatistics Erasmus University Medical Center Address: PO Box 2040, 3000 CA Rotterdam, the Netherlands Tel: +31/(0)10/7043478 Fax: +31/(0)10/7043014 __ R-devel@r-project.org mailing list
Re: [Rd] [R] Semantics of sequences in R
Dimitris Rizopoulos wrote: in my opinion the point of the whole discussion could be summarized by the question, what is a design flaw? This is totally subjective, and it happens almost everywhere in life. Take human languages as an example and in particular, English. I do not know the history of the English language but I can guess at some point some people decided that the past tense for give should be gave and not gived according to the standard rule, possibly because they thought it has better acoustic. Is this a design flaw of English? Some might argue yes, maybe they would think gived does not have a that bad acoustic or they could have come up with another possibility than gave. Does this confuse new users of English? Of course it does -- I had to spent many hours learning the past tense and past particle of the irregular verbs. Should it be changed? Then almost all existing code (i.e., English texts) should be rewritten, which I think demonstrates why some people are a bit reluctant in design changes. To close I'd like to share with you a Greek saying (maybe also a saying in other parts of the world) that goes, for every rule there is an exception. The important thing, in my opinion, is that these exceptions are documented. all this is true; however, programming languages are not natural languages, there are substantial differences, and conclusions valid for natural languages are not necessarily valid for programming languages. vQ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Semantics of sequences in R
G'day Dimitris, On Tue, 24 Feb 2009 11:19:15 +0100 Dimitris Rizopoulos d.rizopou...@erasmusmc.nl wrote: in my opinion the point of the whole discussion could be summarized by the question, what is a design flaw? This is totally subjective, and it happens almost everywhere in life. [...] Beautifully summarised and I completely agree. Not surprisingly, others don't. [...] To close I'd like to share with you a Greek saying (maybe also a saying in other parts of the world) that goes, for every rule there is an exception. [...] As far as I know, the same saying exist in English. It definitely exist in German. Actually, in German it is every rule has its exception including this rule. In German there is one grammar rule that does not have an exception. At least there used to be one; I am not really sure whether that rule survived the recent reform of the German grammar rules. Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Semantics of sequences in R
On 24-Feb-09 13:14:36, Berwin A Turlach wrote: G'day Dimitris, On Tue, 24 Feb 2009 11:19:15 +0100 Dimitris Rizopoulos d.rizopou...@erasmusmc.nl wrote: in my opinion the point of the whole discussion could be summarized by the question, what is a design flaw? This is totally subjective, and it happens almost everywhere in life. [...] Beautifully summarised and I completely agree. Not surprisingly, others don't. [...] To close I'd like to share with you a Greek saying (maybe also a saying in other parts of the world) that goes, for every rule there is an exception. [...] As far as I know, the same saying exist in English. It definitely exist in German. Actually, in German it is every rule has its exception including this rule. Or, as my mother used to say, Moderation in all things! To which, as I grew up, I adjoined ... including moderation. Ted. In German there is one grammar rule that does not have an exception. At least there used to be one; I am not really sure whether that rule survived the recent reform of the German grammar rules. Cheers, Berwin E-Mail: (Ted Harding) ted.hard...@manchester.ac.uk Fax-to-email: +44 (0)870 094 0861 Date: 24-Feb-09 Time: 14:44:21 -- XFMail -- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Semantics of sequences in R
WK == Wacek Kusnierczyk waclaw.marcin.kusnierc...@idi.ntnu.no on Tue, 24 Feb 2009 11:31:13 +0100 writes: WK Dimitris Rizopoulos wrote: in my opinion the point of the whole discussion could be summarized by the question, what is a design flaw? This is totally subjective, and it happens almost everywhere in life. Take human languages as an example and in particular, English. I do not know the history of the English language but I can guess at some point some people decided that the past tense for give should be gave and not gived according to the standard rule, possibly because they thought it has better acoustic. Is this a design flaw of English? Some might argue yes, maybe they would think gived does not have a that bad acoustic or they could have come up with another possibility than gave. Does this confuse new users of English? Of course it does -- I had to spent many hours learning the past tense and past particle of the irregular verbs. Should it be changed? Then almost all existing code (i.e., English texts) should be rewritten, which I think demonstrates why some people are a bit reluctant in design changes. To close I'd like to share with you a Greek saying (maybe also a saying in other parts of the world) that goes, for every rule there is an exception. The important thing, in my opinion, is that these exceptions are documented. WK all this is true; however, programming languages are not natural WK languages, there are substantial differences, and conclusions valid for WK natural languages are not necessarily valid for programming languages. You are are right, Wacek. However, Dimitris' comparison is still a valuable one, and I think I know that you don't quite agree : The S language has a long history and a relatively large user base that goes back many years (say 20). As you know, the vast majority are not professional programmers, not even semi-professional ones. Rather applied statisticians, scientists in many fields, also mathematicians, most very happy about how productively they can apply the S language by using R. The books they have written do exist however (namely mostly collections of R script files), and for almost all of them it would just lead to considerable frustration if one of the exceptions in the language was replaced by the rule in a way that makes their books contain typos. We very occasionally do this, i.e., back-incompatible improvements to R, inspite, but only rarely, when we are convinced that the costs (user frustration, need to re-write books) seem to be outweighed by the benefits. I think this is one of the big differences between (S and) R and other computer languages you've mentioned. So, indeed, Dimitris' parabola was more to the point than you may have appreciated. Hmm, but now let's return to something a bit more productive, please... Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Semantics of sequences in R
... My earlier email requires too much reading between the lines. This one puts the finger more closely on the issues: There are historical inconsistencies and there are design flaws. Naturally, there often is an overlap, but there is also a clear area of excellence. These are largely different things and they should not be so easily confused. Regards, Mark. Mark Difford wrote: Dimitris Rizopoulos wrote: in my opinion the point of the whole discussion could be summarized by the question, what is a design flaw? This is totally subjective, and it happens almost everywhere in life. This [what constitutes a design flaw, and the suggestion that all design flaws are subjective] needs to be more carefully defined, and cannot, or should not, be allowed to fly untested. People do die from time to time because of design flaws. In recent times, two well-known car companies had serious design flaws that led to several deaths. Needless to say [perhaps], design flaws in software can have serious consequences. So-called design flaws in a language are unlikely to. So there are some fundamental, and important, differences between them. Usually, respondents on this list are very careful not to confuse apples with birds, or to try to compare them. Regards, Mark. Berwin A Turlach wrote: On Tue, 24 Feb 2009 09:39:51 +0100 Wacek Kusnierczyk waclaw.marcin.kusnierc...@idi.ntnu.no wrote: Berwin A Turlach wrote: [...] why not read some fortunes? I am well aware of those fortunes and maybe you missed the one: fortune(Watson) Getting flamed for asking dumb questions on a public mailing list is all part of growing up and being a man/woman. -- Michael Watson (in a discussion on whether answers on R-help should be more polite) R-help (December 2004) I am actually wondering where the corresponding fortunes from December 2005, December 2006, December 2007 and December 2009 are since they started of be produced on an annual basis. [...] 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. ah, so what's the difference between the way i pinpoint design flaws and the way r gurus respond to people, so that i am running with a chip on my shoulder, and they are being 'negatively motivating/reinforcing' in didactic terms? [...] Your goal is, presumably, that you want to have the design flaws fixed/discussed/c. The goal of the R gurus is to avoid having to waste their time on unproductive issues because people do not read documentation/behave contrary to how they are asked to behave/c. To reach your goal, the controversial approach is counter productive. To reach their goal, the controversial approach can be quite effective. in my opinion the point of the whole discussion could be summarized by the question, what is a design flaw? This is totally subjective, and it happens almost everywhere in life. Take human languages as an example and in particular, English. I do not know the history of the English language but I can guess at some point some people decided that the past tense for give should be gave and not gived according to the standard rule, possibly because they thought it has better acoustic. Is this a design flaw of English? Some might argue yes, maybe they would think gived does not have a that bad acoustic or they could have come up with another possibility than gave. Does this confuse new users of English? Of course it does -- I had to spent many hours learning the past tense and past particle of the irregular verbs. Should it be changed? Then almost all existing code (i.e., English texts) should be rewritten, which I think demonstrates why some people are a bit reluctant in design changes. To close I'd like to share with you a Greek saying (maybe also a saying in other parts of the world) that goes, for every rule there is an exception. The important thing, in my opinion, is that these exceptions are documented. Best, Dimitris [...] 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? was this really running with a chip: Look up what running with a chip on your shoulder means and reflect on the occasions in which I suggested to you that you give the impression of doing so. On this occasion nobody said that you were running around with a chip on your shoulder. shouldn't the tests have captured it? i think you should have a check for every feature following from the docs. to which marting responded yes, we should But he also made it clear that it would be unlikely that he or any other R-core member would write those
Re: [Rd] [R] Semantics of sequences in R
Dimitris Rizopoulos wrote: in my opinion the point of the whole discussion could be summarized by the question, what is a design flaw? This is totally subjective, and it happens almost everywhere in life. This [what constitutes a design flaw, and the suggestion that all design flaws are subjective] needs to be more carefully defined, and cannot, or should not, be allowed to fly untested. People do die from time to time because of design flaws. In recent times, two well-known car companies had serious design flaws that led to several deaths. Needless to say [perhaps], design flaws in software can have serious consequences. So-called design flaws in a language are unlikely to. So there are some fundamental, and important, differences between them. Usually, respondents on this list are very careful not to confuse apples with birds, or to try to compare them. Regards, Mark. Berwin A Turlach wrote: On Tue, 24 Feb 2009 09:39:51 +0100 Wacek Kusnierczyk waclaw.marcin.kusnierc...@idi.ntnu.no wrote: Berwin A Turlach wrote: [...] why not read some fortunes? I am well aware of those fortunes and maybe you missed the one: fortune(Watson) Getting flamed for asking dumb questions on a public mailing list is all part of growing up and being a man/woman. -- Michael Watson (in a discussion on whether answers on R-help should be more polite) R-help (December 2004) I am actually wondering where the corresponding fortunes from December 2005, December 2006, December 2007 and December 2009 are since they started of be produced on an annual basis. [...] 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. ah, so what's the difference between the way i pinpoint design flaws and the way r gurus respond to people, so that i am running with a chip on my shoulder, and they are being 'negatively motivating/reinforcing' in didactic terms? [...] Your goal is, presumably, that you want to have the design flaws fixed/discussed/c. The goal of the R gurus is to avoid having to waste their time on unproductive issues because people do not read documentation/behave contrary to how they are asked to behave/c. To reach your goal, the controversial approach is counter productive. To reach their goal, the controversial approach can be quite effective. in my opinion the point of the whole discussion could be summarized by the question, what is a design flaw? This is totally subjective, and it happens almost everywhere in life. Take human languages as an example and in particular, English. I do not know the history of the English language but I can guess at some point some people decided that the past tense for give should be gave and not gived according to the standard rule, possibly because they thought it has better acoustic. Is this a design flaw of English? Some might argue yes, maybe they would think gived does not have a that bad acoustic or they could have come up with another possibility than gave. Does this confuse new users of English? Of course it does -- I had to spent many hours learning the past tense and past particle of the irregular verbs. Should it be changed? Then almost all existing code (i.e., English texts) should be rewritten, which I think demonstrates why some people are a bit reluctant in design changes. To close I'd like to share with you a Greek saying (maybe also a saying in other parts of the world) that goes, for every rule there is an exception. The important thing, in my opinion, is that these exceptions are documented. Best, Dimitris [...] 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? was this really running with a chip: Look up what running with a chip on your shoulder means and reflect on the occasions in which I suggested to you that you give the impression of doing so. On this occasion nobody said that you were running around with a chip on your shoulder. shouldn't the tests have captured it? i think you should have a check for every feature following from the docs. to which marting responded yes, we should But he also made it clear that it would be unlikely that he or any other R-core member would write those tests and that this would probably be left to you; with any contribution being welcome. Consider yourself lucky that this exchange was with Martin, other members of R core might have communicated a similar message in quite another way. That exchange is very much confirming my understanding of the culture of the R community. As I try to tell you, that is not the way it works. R comes already with extensive tests that
Re: [Rd] [R] Semantics of sequences in R
Stavros Macrakis wrote: ...sort(list(...))), I'd hope that wouldn't break existing code. [...] ...sort is a generic function, and for sort(list(...)) to work, it would have to dispatch to a function called sort.list;... such a function exists already and it is not for sorting list. Omigod. There is a function called 'sort' which doesn't sort, and which follows the S3 conventions for sorting lists, but doesn't allow lists as an argument type. That *is* a mess! Well, if it's OK for sort.list to violate S3 naming conventions (presumably because it was defined before S3 was), then I suppose it would be OK for sort to violate S3 coding conventions in return, and dispatch in a non-standard way, e.g. if (is.list(x)) sort.S3.list(...) else UseMethod(sort) Ugly, but then so is sort.list according to svn, sort.list was introduced in late 1999 by Prof Brian Ripley (revision 6598, 'add sort.list for S compatibility'). however, the fancy 'have you called sort on a list' error message was added by Prof Brian Ripley in 2006, replacing the less confusing but still odd (to a naive user) message 'x must be atomic' produced when you call sort.list on a list. btw. it's interesting that in revision 38438 (2006) Prof Brian Ripley introduced (or so does the commit message say) sorting complex numbers, and now you have things like: 1i 0i # Error in 0+0i 0+1i : invalid comparison with complex values sort(c(1i, 0i)) # 0i 1i vQ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Semantics of sequences in R
Wacek Kusnierczyk wrote: btw. it's interesting that in revision 38438 (2006) Prof Brian Ripley introduced (or so does the commit message say) sorting complex numbers, and now you have things like: 1i 0i # Error in 0+0i 0+1i : invalid comparison with complex values sort(c(1i, 0i)) # 0i 1i it's interesting also because one of the arguments for why sort does not operate on lists is that it is not clear how to compare their elements (see, e.g., [1]). so why would sort sort complex numbers, if r cannot compare them? arguing that sort cannot operate on lists because it does not know how to compare the elements is based on a misconception. algorithms for sorting are in essence ignorant of what the elements of the sequences to be sorted are; sorting works equally well with numbers, strings, functions, plants, waste, etc., provided that an appropriate comparator is specified. i think that the right design for sort and sort.list would be to have the former operate on atomic vectors (``real'' vectors, those that can be considered lists but they're not) with defaults for the respective types, and the latter operate on lists with no default for the comparator, even when all elements happen to be of the same type: sort(1:10) # fine sort(as.list(1:10)) # error: no comparator specified sort(as.list(1:10), ``) # fine vQ [1] http://tolstoy.newcastle.edu.au/R/e4/help/08/07/16231.html __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Semantics of sequences in R
Berwin A Turlach wrote: On Mon, 23 Feb 2009 08:52:05 +0100 Wacek Kusnierczyk waclaw.marcin.kusnierc...@idi.ntnu.no wrote: Berwin A Turlach wrote: G'day Stavros, snip In many cases, the orthogonal design is pretty straightforward. And in the cases where the operation is currently an error (e.g. sort(list(...))), I'd hope that wouldn't break existing code. [...] This could actually be an example that would break a lot of existing code. sort is a generic function, and for sort(list(...)) to work, it would have to dispatch to a function called sort.list; and as Patrick Burns' The R Inferno points out, such a function exists already and it is not for sorting list. and you mean that sort.list not being applicable to lists is a) good design, and b) something that by noe means should be fixed, right? I neither said nor meant this and I do not see how what I said could be interpreted in such a way. I was just commenting to Stavros that the example he picked, hoping that it would not break existing code, was actually a bad one which potentially will break a lot (?) of existing code. would it, really? if sort.list were, in addition to sorting atomic vectors (can-be-considered-lists), able to sort lists, how likely would this be to break old code? can you give one concrete example, and suggest how to estimate how much old code would involve the same issue? sort.list, to be applied to an atomic vector, must be called explicitly on the vector, because calling sort will not automatically dispatch to sort.list (right?). so allowing sort.list to sort lists does not change anything in this respect -- except for that, as i suggested, if sort.list were requiring an explicit comparator, you'd have to add one wherever sort.list is called, but to accomodate for old code sort.list could actually check whether the argument is not an atomic vector. how much old code could be relying on the fact that sort.list raises an error when given a list? i suspect it's fairly unlikely that any single piece of code does; and if so, allowing sort.list to sort lists would not change anything here either. Also, until reading Patrick Burns' The R Inferno I was not aware of sort.list. That function had not registered with me since I hardly used it. which hints that potentially will break a lot (?) of existing code is a rather unlikely event. And I also have no need of calling sort() on lists. For em a lists is a flexible enough data structure such that defining a sort() command for them makes no sense; it could only work in very specific circumstances. i don't understand the first part: flexible enough data structure such that defining a sort() command for them makes no sense makes no sense. as to it could only work in very specific circumstances -- no, it would work for any list whatsoever, provided the user has a correctly implemented comparator. for example, i'd like to sort a list of vectors by the vectors' length -- is this a very exotic idea? In fact, currently you get: R cc - list(a=runif(4), b=rnorm(6)) R sort(cc) Error in sort.list(cc) : 'x' must be atomic for 'sort.list' Have you called 'sort' on a list? one of the most funny error messages you get in r. note also that, following rolf turner's lists and vectors unproven theorem, a vector can be considered a list I do not remember the exact context of Rolf's comments, but I believe he was talking in a more general sense and not in technical terms. indeed, he was blurring the concepts instead of referring to concrete documentation with clear specified meaning of the terms he used. I find it perfectly valid, even when talking about R, to say something like vectors are stored as a list of numbers in consecutive memory locations in memory. yes; and you can always say that 'vectors can be considered electrical charges', or better, 'vectors can be considered electrical charges, in some sense'. what sense of 'list' are you using here? i'd rather use the term 'array', unless confusing the user is the real purpose. (and to be really picky, you do not store numbers.) Clearly, in a phrase like this, we are not talking about vectors and list as defined by the R Language Definition or R Internals, or what functions like is.vector(), is.list() c return for various R objects. clearly, you can say anything you like, and then add 'i was not talking about x as defined by y'. the art is to talk about x as defined by y. BTW, as I mentioned once before, you might want to consider to lose these chips on your shoulders. berwin, it's been a tradition on this list to discourage people from commenting on the design and implementation of r whenever they think it's wrong. you really should be doing the opposite. as a chinese proverb says, a gem cannot be polished without friction. friction seems to be what you fear a
Re: [Rd] [R] Semantics of sequences in R
Dear vQ, vectors (can-be-considered-lists), can you please stop repeating this nonsense? I don't think anybody ever claimed that vectors can be considered list. It's rather the other way round: lists can also be seen as vectors to R (possibly they are implemented as such, but I don't much about the internals of R). a - as.list(1:10) b - 1:10 is.vector(a) [1] TRUE is.list(a) [1] TRUE is.vector(b) [1] TRUE is.list(b) [1] FALSE Hence the confusion about mode(as.vector(a)) [1] list which prompted the original comment that you are taking so much exception to. as to it could only work in very specific circumstances -- no, it would work for any list whatsoever, provided the user has a correctly implemented comparator. for example, i'd like to sort a list of vectors by the vectors' length -- is this a very exotic idea? Honestly, I can't think of a situation where I would want to do than in R. In a Perl script, quite likely; but this is a kind of data manipulation that R wasn't really designed for IMHO. Not that I'd mind having sort() operate properly on lists; it just isn't something I miss in the language. Best, Stefan [ stefan.ev...@uos.de | http://purl.org/stefan.evert ] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Semantics of sequences in R
On Mon, 23 Feb 2009 11:31:16 +0100 Wacek Kusnierczyk waclaw.marcin.kusnierc...@idi.ntnu.no wrote: Berwin A Turlach wrote: On Mon, 23 Feb 2009 08:52:05 +0100 Wacek Kusnierczyk waclaw.marcin.kusnierc...@idi.ntnu.no wrote: [...] and you mean that sort.list not being applicable to lists is a) good design, and b) something that by noe means should be fixed, right? I neither said nor meant this and I do not see how what I said could be interpreted in such a way. I was just commenting to Stavros that the example he picked, hoping that it would not break existing code, was actually a bad one which potentially will break a lot (?) of existing code. would it, really? if sort.list were, in addition to sorting atomic vectors (can-be-considered-lists), able to sort lists, how likely would this be to break old code? Presumably not. 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. 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. AFAIK, Brian is doing something like this on his machine. I am sure that if you ask nicely he will share his scripts with you. If this sounds too time consuming, you might just want to unpack the sources and grep for sort.list on all .R files; I am sure you know how to use find and grep to do this. Also, until reading Patrick Burns' The R Inferno I was not aware of sort.list. That function had not registered with me since I hardly used it. which hints that potentially will break a lot (?) of existing code is a rather unlikely event. Only for code that I wrote; other people's need and knowledge of R may vary. And I also have no need of calling sort() on lists. For em a lists is a flexible enough data structure such that defining a sort() command for them makes no sense; it could only work in very specific circumstances. i don't understand the first part: flexible enough data structure such that defining a sort() command for them makes no sense makes no sense. lists are very flexible structure whose component must not be of equal type. So how do you want to compare components? How to you compare a vector of numbers to a vector of character strings? Or a list of lists? Or should the sorting be on the length of the components? Or their names? Or should sort(myList) sort each component of myList? But for that case we have already lapply(myList, sort). as to it could only work in very specific circumstances -- no, it would work for any list whatsoever, provided the user has a correctly implemented comparator. for example, i'd like to sort a list of vectors by the vectors' length -- is this a very exotic idea? 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? BTW, as I mentioned once before, you might want to consider to lose these chips on your shoulders. berwin, it's been a tradition on this list to discourage people from commenting on the design and implementation of r whenever they think it's wrong. I am not aware of any such tradition and I subscribed to R-help on 15 April 1998. 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). 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. Alternatively, if it turns out that something that bugs you cannot be changed without breaking too much existing code, start from scratch that with a better design. Apparently the GAP project (http://www.gap-system.org/) is doing something like this, as someone closely associated with that project once told me. While developing a version of GAP they collect information on how to improve the design, data structures c; then, at some point, they start to write the next version from scratch. 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
Re: [Rd] [R] Semantics of sequences in R
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. not that it is impossible or even difficult, i just haven't found time yet to learn how to implement internal functions in r. 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. but maybe not in r, where protection of old code seems more important than progress. AFAIK, Brian is doing something like this on his machine. I am sure that if you ask nicely he will share his scripts with you. :) If this sounds too time consuming, you might just want to unpack the sources and grep for sort.list on all .R files; I am sure you know how to use find and grep to do this. of course i've done it in the first place; there are 52 such entries in r-devel, and i can't see any where allowing sort.list to sort lists would break the code. it does not mean, of course, that it wouldn't. Also, until reading Patrick Burns' The R Inferno I was not aware of sort.list. That function had not registered with me since I hardly used it. which hints that potentially will break a lot (?) of existing code is a rather unlikely event. Only for code that I wrote; other people's need and knowledge of R may vary. hence 'hints', not 'proves'. And I also have no need of calling sort() on lists. For em a lists is a flexible enough data structure such that defining a sort() command for them makes no sense; it could only work in very specific circumstances. i don't understand the first part: flexible enough data structure such that defining a sort() command for them makes no sense makes no sense. lists are very flexible structure whose component must not be of equal type. So how do you want to compare components? How to you compare a vector of numbers to a vector of character strings? Or a list of lists? *very* easy: by applying a suitable comparator. in your specific example, the possibilities are virtually limitless. you can convert the numbers to strings, or parse the strings into numbers. you can compute the lengths of the lists, compare their elements pairwise, or whatever you wish. all this done by a comparator which is a function fullfilling just one requirement: that it returns, say, -1, 0, or 1, depending on how the two items it gets compare. (and it has to work for the type of items you happen to have in your lists -- all this *your* business, not sort's.) judging from your question, you couldn't possibly see sorting routines in other languages. Or should the sorting be on the length of the components? why not? Or their names? why not? Or should sort(myList) sort each component of myList? that's a design decision. you can always have a parameter like recursive=TRUE/FALSE, no? so you could sort or not both between and within lists. what's the problem, again? But for that case we have already lapply(myList, sort). so? as to it could only work in very specific circumstances -- no, it would work for any list whatsoever, provided the user has a correctly implemented comparator. for example, i'd like to sort a list of vectors by the vectors' length -- is this a very exotic idea? 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). BTW, as I mentioned once before, you might want to consider to lose these chips on your shoulders. berwin, it's been a tradition on this list to discourage people from commenting on the design and implementation of r whenever they think it's wrong. I am not aware of any such tradition and I subscribed to R-help on 15 April 1998. 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
Re: [Rd] [R] Semantics of sequences in R
On Mon, 23 Feb 2009 13:27:08 +0100 Wacek Kusnierczyk waclaw.marcin.kusnierc...@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,
Re: [Rd] [R] Semantics of sequences in R
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
Re: [Rd] [R] Semantics of sequences in R
On Sun, Feb 22, 2009 at 10:34 PM, Berwin A Turlach ber...@maths.uwa.edu.au wrote: G'day Stavros, Hello, Berwin, On Sun, 22 Feb 2009 16:50:13 -0500 Stavros Macrakis macra...@alum.mit.edu wrote: ...sort(list(...))), I'd hope that wouldn't break existing code. [...] ...sort is a generic function, and for sort(list(...)) to work, it would have to dispatch to a function called sort.list;... such a function exists already and it is not for sorting list. Omigod. There is a function called 'sort' which doesn't sort, and which follows the S3 conventions for sorting lists, but doesn't allow lists as an argument type. That *is* a mess! Well, if it's OK for sort.list to violate S3 naming conventions (presumably because it was defined before S3 was), then I suppose it would be OK for sort to violate S3 coding conventions in return, and dispatch in a non-standard way, e.g. if (is.list(x)) sort.S3.list(...) else UseMethod(sort) Ugly, but then so is sort.list -s __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Semantics of sequences in R
g'orning, Berwin A Turlach wrote: G'day Stavros, snip In many cases, the orthogonal design is pretty straightforward. And in the cases where the operation is currently an error (e.g. sort(list(...))), I'd hope that wouldn't break existing code. [...] This could actually be an example that would break a lot of existing code. sort is a generic function, and for sort(list(...)) to work, it would have to dispatch to a function called sort.list; and as Patrick Burns' The R Inferno points out, such a function exists already and it is not for sorting list. and you mean that sort.list not being applicable to lists is a) good design, and b) something that by noe means should be fixed, right? In fact, currently you get: R cc - list(a=runif(4), b=rnorm(6)) R sort(cc) Error in sort.list(cc) : 'x' must be atomic for 'sort.list' Have you called 'sort' on a list? one of the most funny error messages you get in r. note also that, following rolf turner's lists and vectors unproven theorem, a vector can be considered a list -- hence sort.list should raise the error on any vector input, no? Thus, to make sort(list()) work, you would have to rename the existing sort.list and then change every call to that function to the new name. I guess this might break quite a few packages on CRAN. scary! it's much preferred to confuse new users. vQ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
