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] are arithmetic comparison operators binary?
WK == Wacek Kusnierczyk waclaw.marcin.kusnierc...@idi.ntnu.no
on Mon, 23 Feb 2009 19:29:31 +0100 writes:
WK Martin Maechler wrote:
WK == Wacek Kusnierczyk waclaw.marcin.kusnierc...@idi.ntnu.no
on Mon, 23 Feb 2009 12:06:32 +0100 writes:
Thank you, Wacek,
though .. wrong mailing list
WK apologies. i was actually asking for explanation, assuming that it
WK might be my misunderstanding, rather than reporting a bug.
( yes; but it is really a technical topic, also touching on
extending R [below], hence -- R-devel )
WK the man page for relational operators (see, e.g., ?'') says:
WK
WK Binary operators which allow the comparison of values in atomic vectors.
WK Arguments:
WK x, y: atomic vectors, symbols, calls, or other objects for which
WK methods have been written.
WK
WK it is somewhat surprizing that the following works:
WK ''(1)
WK # logical(0)
WK ''()
WK # logical(0)
WK ''(1,2,3)
WK # TRUE
a bit surprising (sic!), indeed, even for me.
Thanks for your notice and report!
WK you're welcome.
WK shouldn't the tests have captured it? i think you should have a check
WK for every feature following from the docs.
yes, we should.
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to ..
.
R is a collaborative project with many contributors.
I think we'd gladly accept well-written commented extra
R-x.y.z/tests/foo.R
files or patches to existing ./tests/*.R
particularly if the contributor shows the new tests are
systematically covering currently untested areas...
Again: this really belongs to R-devel
-- I'm CCing there {and write a quick reply on R-help about
the mailing list redirection}
WK plus those undocumented, but assumed by the developers.
;-) :-)
Indeed, we are also grateful for (concise!) patches to man/*.Rd
help files.
If you'd looked a bit in the sources, you'd seen that they
really are supposed to be binary only.
WK it wouldn't be nonsensical to let them be of arbitrary arity (in a
WK well-documented manner), though it might confuse users.
Yes (to the latter). One of the beauties of S and R is the
syntax closeness to mathematical notation.
Many of us know that Lisp has beauties that S can never have,
but that's really in different beauty-space.
A very small change in the sources does accomplish this, passes
the standard checks (and I cannot imagine reasonable code that
would have relied on the more lenient behavior), so
this will have changed in one of the next versions of R-devel.
WK thanks.
WK just a question (i haven't checked the sources, maybe i should): what
WK is it that happens when one of the operators is called with n = 0 or 1
WK argument? how does it come up with logical(0) rather than NA?
In some of the cases e.g.
''(1)
it basically does [empty] 1 and hence returns the same as
NULL 1
Regards,
Martin Maechler, ETH Zurich
__
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: 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] are arithmetic comparison operators binary?
Martin Maechler wrote: Thank you, Wacek, though .. wrong mailing list WK apologies. i was actually asking for explanation, assuming that it WK might be my misunderstanding, rather than reporting a bug. ( yes; but it is really a technical topic, also touching on extending R [below], hence -- R-devel ) point taken. I think we'd gladly accept well-written commented extra R-x.y.z/tests/foo.R files or patches to existing ./tests/*.R particularly if the contributor shows the new tests are systematically covering currently untested areas... Again: this really belongs to R-devel ok. WK plus those undocumented, but assumed by the developers. ;-) :-) Indeed, we are also grateful for (concise!) patches to man/*.Rd help files. ok. If you'd looked a bit in the sources, you'd seen that they really are supposed to be binary only. WK it wouldn't be nonsensical to let them be of arbitrary arity (in a WK well-documented manner), though it might confuse users. Yes (to the latter). One of the beauties of S and R is the syntax closeness to mathematical notation. Many of us know that Lisp has beauties that S can never have, but that's really in different beauty-space. not quite sure what you mean by 'closeness to mathematical notation' here. WK just a question (i haven't checked the sources, maybe i should): what WK is it that happens when one of the operators is called with n = 0 or 1 WK argument? how does it come up with logical(0) rather than NA? In some of the cases e.g. ''(1) it basically does [empty] 1 and hence returns the same as NULL 1 which is consistent with NULL + 1. btw: 1. you might want to keep the error message from applying and other relops to an inappropriate number of arguments in sync with the message one gets from, e.g., '+'(1,2,3). (you may want to actually update the message from '+' and relatives, as it seems that there are more operators that give an error message similar to that of ''. the attached patch fixes this; it has been compiled and successfully tested -- see below.) 2. '+'() and '+'(1,2,3) say the operator needs one or two arguments, but again, '+' is documented as a *binary* operator. i guess the intention here is to have them unary or binary, and it's the docs that should be updated. vQ The patch for src/main/arithmetic.c was prepared as follows: svn co https://svn.R-project.org/R/trunk/ cd trunk tools/rsync-recommended # modifications made to src/main/character.c svn diff do_grep.diff The patched sources were successfully compiled and tested as follows: svn revert -R . patch -p0 do_grep.diff ./configure make make check Index: src/main/arithmetic.c === --- src/main/arithmetic.c (revision 47991) +++ src/main/arithmetic.c (working copy) @@ -295,7 +295,7 @@ case 2: return R_binary(call, op, CAR(args), CADR(args)); default: - errorcall(call,_(operator needs one or two arguments)); + errorcall(call,_(%d arguments passed to '%s' which requires 1 or 2), length(args), PRIMNAME(op)); } return ans; /* never used; to keep -Wall happy */ } __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] are arithmetic comparison operators binary?
Wacek Kusnierczyk wrote: The patch for src/main/arithmetic.c was prepared as follows: svn co https://svn.R-project.org/R/trunk/ cd trunk tools/rsync-recommended # modifications made to src/main/character.c svn diff do_grep.diff The patched sources were successfully compiled and tested as follows: svn revert -R . patch -p0 do_grep.diff ./configure make make check obviously, i forgot to replace 'do_grep' with 'arithmetic'. vQ __ 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 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
[Rd] sys.source and encoding
Hello, The sys.source function does not have an encoding argument, and does not accept a connection (created by file): gt; sys.source(syssource.R) Error in parse(n = -1, file = file) : invalid multibyte character in parser at line 2 Here we could simply pass encoding or ... to parse, the next one is more confusing: gt; sys.source( file( syssource.R, encoding = windows-1252 ) ) Error in sys.source(file(syssource.R, encoding = windows-1252)) : '5' is not an existing file the syssource.R file contains this : file critère lt;- 1 /file I can try to fix this, but maybe a decision needs to be made first about how ? just add the encoding argument to sys.source, add the ... to sys.source, handle connection in sys.source ? gt; version _ platform i686-pc-linux-gnu arch i686 os linux-gnu system i686, linux-gnu status Under development (unstable) major 2 minor 9.0 year 2009 month 02 day08 svn rev47879 language R version.string R version 2.9.0 Under development (unstable) (2009-02-08 r47879) Romain -- Romain Francois Independent R Consultant +33(0) 6 28 91 30 30 http://romainfrancois.blog.free.fr [[alternative HTML version deleted]] __ 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
[Rd] [SoC09-Idea] Movement Ecology add-ons for adehabitat package
Hi all, here's a proposal for a SoC project on wildlife movement patterns analysis. A MSc student is available to anwser the call, of course. The idea has already been briefly discussed with the mantainer of the adehabitat package and the AniMov project community. Short description Develop some add-on functions to use the adehabitat package to perform basic movement ecology analysis, in particular analysis of fractal dimension D. Developed functions could possibly be included in a future release of the adehabitat package itself. Detailed description Fractal dimension analysis is an useful tool to better understand not just the 'path tortuosity', in an animal's trajectory, but also the scale level at which 'search patterns' occur, i.e. an indirect index of the scale at which habtat resources are 'perceived'. It has already been shown using simulations (Nams 2005; Oecologia 143: 179-188) that the fractal dimension D of a trajectory changes within scales, and that the fractal dimension could be a valuable tool in multiscale analysis of wildlife movement patterns. The adehabitat package, increasingly used as a free-open source alternative in radiiotracking and animal habitat selection studies, already has base functions to deal with trajectories in time and space, both as regular samples (e.g. data from GPS radio tags) and as irregular ones (as in 'classic' VHF radiotraking). The implementation of the algorithms devised by Nams could widen the range of analytical instruments that already make adehabitat an almost complete tool. Moreover, the author of the sole existing software to do fractal analysis (V. O. Nams [0]) has expressed no objection towards such a porting (as reported by Paolo Cavallini in the AniMov mailing list [1]), suggesting that a complete rewrite could be a better solution. In detail, the project objectives will be to port (or rewrite) into R the 'standard' methods offered by the FRACTAL program: - fractal dimension estimation (D) using the basic divider method - estimation of D the resampling divider method (Nams 2006: Acta Biotheoretica 54:1-11) - estimation of D using the VFractal estimator (Nams, 1996: Landscape Ecology 11:289-297). - production of other relevant movement ecology statistics useful in spetial scale perception by animals (Nams 2006: Animal Behaviour. 72: 1197-1203). - optionally, in conjunction with the random movement simulators already present in adehabitat (in particular simm.levy and simm.crw), test for deviations from a CRW model (Nams and Bourgeois 2004: Can J. Zool, 82:1738-1747) and detect if oriented movements occur (Nams 2006: Animal Behaviour. 72: 1197-1203) Required skills The candidate should be both familiar with R programming and wildlife radiotracking data analysis. A minimal familiarity with the adehabitat code could be desirable. Mentor Damiano G. Preatoni, PhD. Research Associate Unità di Analisi e Gestione delle Risorse Ambientali Dipartimento Ambiente-Salute-Sicurezza Università degli Studi dell'Insubria (see signature for details) And, finally, the programming exercise [2]: the candidate should demonstrate to be able to transform raw irregular VHF radiotracking data into an adehabitat ltraj object, which could be the base data structure to work with in the proposed package. [0] http://nsac.ca/envsci/staff/vnams/Fractal.htm [1] http://www.nabble.com/fractals-to21875728.html [2] http://xkcd.com/74/ signature.asc Description: This is a digitally signed message part. __ 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
[Rd] wishlist boxplot (PR#13553)
[CCing Martin and Brian who had both done most svn commits of boxplot.R so far] A very minor wishlist item that I should have already reported years ago: All the time when I need presentation/publication quality boxplots, I add par(lend=1) in my code in order to suppress the ugly median line that does not stop at the end of the box given the rounded line endings. Ugly example: boxplot(1:10, lwd=30) I'd like the following very minor change for boxplots: D:\Rcompile\recent\R\src\library\graphics\Rdiff -u boxplot.R boxplot-new.R --- boxplot.R 2009-02-24 18:04:47.265625000 +0100 +++ boxplot-new.R 2009-02-24 18:10:02.0 +0100 @@ -148,7 +148,7 @@ ## Median xysegments(xP(x, -wntch), stats[3L], xP(x, +wntch), stats[3L], - lty = medlty[i], lwd = medlwd[i], col = medcol[i]) + lty = medlty[i], lwd = medlwd[i], col = medcol[i], lend=1) xypoints(x, stats[3L], pch = medpch[i], cex = medcex[i], col= medcol[i], bg = medbg[i]) ## Whiskers Best wishes, Uwe Ligges __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] invalid comparison in numeric sequence (PR#13551)
Full_Name: alex Version: 2.8.1 OS: Ubuntu / MacOSX Submission from: (NULL) (162.38.183.51) 0.6==0.6 [1] TRUE seq(0,1,0.1)==0.4 [1] FALSE FALSE FALSE FALSE TRUE FALSE FALSE FALSE FALSE FALSE FALSE seq(0,1,0.1)==0.6 [1] FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE seq(0,1,0.1)==0.8 [1] FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE TRUE FALSE FALSE What is wrong with 0.6 ??? (TRUE is missing) I tried 3 differents computers (2 Ubuntu with R 2.8.1, and one Mac with R 2.8). __ 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
[Rd] Box.test reference correction (PR#13554)
Full_Name: Peter Solymos Version: 2.8.1 OS: Windows Submission from: (NULL) (129.128.141.92) The help page of the Box.test function (stats) states that the Ljung-Box test was published in: Ljung, G. M. and Box, G. E. P. (1978), On a measure of lack of fit in time series models. Biometrika 65, 553--564. The page numbers are incorrect. The correct citation should be as follows: Ljung, G. M. and Box, G. E. P. (1978), On a measure of lack of fit in time series models. Biometrika 65, 297--303. Yours, Peter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
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
