Building 1.125
The University of Manchester email: georgi.boshna...@manchester.ac.uk
Oxford Road
Manchester M13 9PL
UK
Date: Tue, 06 May 2014 13:57:14 -0700
From: Herv? Pag?s
To: William Dunlap
Cc: Michael Friendly , "r-devel@r-project.org"
On 05/06/2014 01:44 PM, William Dunlap wrote:
Run the following function over the output of
parse("yourSourceCode.R") to edit the parse tree:
inToIsElement <- function (expr)
{
# expr should be an expression or a call, not a function.
# The output of parse(keep.source=FALSE) or quote()
Run the following function over the output of
parse("yourSourceCode.R") to edit the parse tree:
inToIsElement <- function (expr)
{
# expr should be an expression or a call, not a function.
# The output of parse(keep.source=FALSE) or quote() is good.
if (is.call(expr) && identical(expr[
On May 6, 2014, at 1:06 PM, Hervé Pagès wrote:
> On 05/06/2014 12:36 PM, William Dunlap wrote:
>> When does els%in%set give a different result than is.element(els,set)?
>> I assumed they were copied form S+, where they are the same except
>> for argument names, but I may be wrong.
>
> > els <-
On 05/06/2014 01:15 PM, William Dunlap wrote:
In your example els%in%set gave the same result as
is.element(els,set), but because of precedence issues putting a unary
minus in front caused them to be given different inputs - one got -els
and the other got just els for the first argument.
So you
In your example els%in%set gave the same result as
is.element(els,set), but because of precedence issues putting a unary
minus in front caused them to be given different inputs - one got -els
and the other got just els for the first argument. To change one to
the other you have to edit the parsed
On 05/06/2014 12:36 PM, William Dunlap wrote:
When does els%in%set give a different result than is.element(els,set)?
I assumed they were copied form S+, where they are the same except
for argument names, but I may be wrong.
> els <- 2:1
> set <- 1:6
> - els%in%set
[1] FALSE FALSE
>
When does els%in%set give a different result than is.element(els,set)?
I assumed they were copied form S+, where they are the same except
for argument names, but I may be wrong.
Bill Dunlap
TIBCO Software
wdunlap tibco.com
On Tue, May 6, 2014 at 12:23 PM, Hervé Pagès wrote:
> On 05/06/2014 08:5
On 05/06/2014 08:54 AM, William Dunlap wrote:
You can also use is.element(els,set) instead of the equivalent
els%in%set
No they are not *equivalent*. Equivalent means you could substitute
one by the other in your code without changing its behavior.
H.
and leave your precedence problems behin
Here is source code for help(Syntax) from S+, which I think follows
closely the original S help file:
.Ix precedence
The following \f6infix\fP operators are recognized by the parser.
They are listed in decreasing precedence.
In the event of ties, evaluation is from left to right.
.sp
.in +.5i
.nf
.
On 06/05/2014 1:01 PM, peter dalgaard wrote:
On 06 May 2014, at 18:20 , Hadley Wickham wrote:
>>> BTW, that %in% has precedence over arithmetic operations is surprising,
>>> error-prone, and doesn't cover any reasonable use case (who needs to
>>> multiply the logical vector returned by %in% by
On 06 May 2014, at 18:20 , Hadley Wickham wrote:
>>> BTW, that %in% has precedence over arithmetic operations is surprising,
>>> error-prone, and doesn't cover any reasonable use case (who needs to
>>> multiply the logical vector returned by %in% by some value?) but that's
>>> another story:
>>
>> BTW, that %in% has precedence over arithmetic operations is surprising,
>> error-prone, and doesn't cover any reasonable use case (who needs to
>> multiply the logical vector returned by %in% by some value?) but that's
>> another story:
>
> The point here is that the %foo% operators all have the
You can also use is.element(els,set) instead of the equivalent
els%in%set and leave your precedence problems behind.
Bill Dunlap
TIBCO Software
wdunlap tibco.com
On Mon, May 5, 2014 at 10:35 PM, peter dalgaard wrote:
>
> On 06 May 2014, at 01:05 , Hervé Pagès wrote:
>
>>
>> BTW, that %in% has p
On 06 May 2014, at 01:05 , Hervé Pagès wrote:
>
> BTW, that %in% has precedence over arithmetic operations is surprising,
> error-prone, and doesn't cover any reasonable use case (who needs to
> multiply the logical vector returned by %in% by some value?) but that's
> another story:
The point
On 05/04/2014 06:35 PM, Michael Friendly wrote:
On 03/05/2014 12:39 PM, Hadley Wickham wrote:
Can anyone tell me what the significance of 1954 is in R's NA?
Just ask R:
> 2*(1-pnorm(1954))
[1] 0
> 2*(1-pnorm(1954)) %in% NA
[1] 0
Not sure that would make the "joke" better, but you need pa
On 03/05/2014 12:39 PM, Hadley Wickham wrote:
Can anyone tell me what the significance of 1954 is in R's NA?
Just ask R:
> 2*(1-pnorm(1954))
[1] 0
> 2*(1-pnorm(1954)) %in% NA
[1] 0
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailma
A fortune? Spencer
On 5/4/2014 6:00 AM, Hadley Wickham wrote:
Thanks Luke!
Hadley
On Sat, May 3, 2014 at 11:48 AM, wrote:
Hint: Ross will be 60 this year.
luke
On Sat, 3 May 2014, Hadley Wickham wrote:
Can anyone tell me what the significance of 1954 is in R's NA?
Thanks!
Hadley
Thanks Luke!
Hadley
On Sat, May 3, 2014 at 11:48 AM, wrote:
> Hint: Ross will be 60 this year.
>
> luke
>
>
> On Sat, 3 May 2014, Hadley Wickham wrote:
>
>> Can anyone tell me what the significance of 1954 is in R's NA?
>>
>> Thanks!
>>
>> Hadley
>>
>>
>
> --
> Luke Tierney
> Chair, Statistics a
Hint: Ross will be 60 this year.
luke
On Sat, 3 May 2014, Hadley Wickham wrote:
Can anyone tell me what the significance of 1954 is in R's NA?
Thanks!
Hadley
--
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa
Can anyone tell me what the significance of 1954 is in R's NA?
Thanks!
Hadley
--
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
21 matches
Mail list logo
