Re: [Rd] [R] Semantics of sequences in R
On Mon, 23 Feb 2009 20:27:23 +0100 Wacek Kusnierczyk 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 > > > > >>> 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,
Re: [Rd] [R] are arithmetic comparison operators binary?
> "WK" == Wacek Kusnierczyk
> on Mon, 23 Feb 2009 19:29:31 +0100 writes:
WK> Martin Maechler wrote:
>>> "WK" == Wacek Kusnierczyk
>>> 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
/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. >>> 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 thi
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
> /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
On Tue, 24 Feb 2009 09:39:51 +0100
Wacek Kusnierczyk 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.
[...]
> >> 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
Re: [Rd] [R] Semantics of sequences in R
Berwin A Turlach wrote:
On Tue, 24 Feb 2009 09:39:51 +0100
Wacek Kusnierczyk 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
https://stat.ethz.ch/mailman/listinfo/
Re: [Rd] [R] Semantics of sequences in R
Berwin A Turlach wrote:
>
> 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 did miss it. i'm gladly including it in my collection of quotes
documenting your approach to your users. thanks.
>
>> 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.
>
>
nice summary. you rule, we crawl.
> 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?
>
employing the recent trick of duncan's, i'd say that i wasn't telling
anyone that they should do something. i said 'i think', which is
explaining what i think, not telling to do.
but even without the trick, even if i said 'you should' instead of 'i
think you should', if you were not oversensitive, exaggerating, and
prejudiced, you would be able to read it as a suggestion. we clearly
differ in our understanding of 'tell' -- and it's of course my fault, as
my english is certainly more unlike the official than yours.
vQ
__
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. 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):
> 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:
> 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 :
critère <- 1
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 ?
> 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 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 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) 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 > 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\R>diff -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 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
[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 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.
