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[[1]], as.name("%in%"))) {
expr[[1]] <- as.name("is.element")
}
if (is.recursive(expr)) {
for(i in seq_along(expr)) {
expr[[i]] <- Recall(expr[[i]])
}
}
expr
}
E.g.,
> txt <- "function(els, negSet, posSet){
+ -els %in% negSet & # commentary
+ els %in% posSet
+ }"
> inToIsElement(parse(text=txt, keep.source=FALSE))[[1]]
function(els, negSet, posSet) {
is.element(-els, negSet) & is.element(els, posSet)
}
It assumes that you didn't make any precedence errors with %in%.
Bill Dunlap
TIBCO Software
wdunlap tibco.com
On Tue, May 6, 2014 at 1:28 PM, Hervé Pagès <hpa...@fhcrc.org> wrote:
> 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 confirm that to use your solution (i.e. replace my use of
> 'els%in%set' with 'is.element(els,set)') I need to think about
> precedence?
>
>
>> To change one to
>> the other you have to edit the parsed expression, not the text. If
>> you used is.element in the first place you would avoid precedence
>> issues.
>
>
> "If you ... in the first place". Ahhhh, but that's not what I did. So
> that doesn't help me.
>
> H.
>
>
>> (I avoid creating %xxx% functions because the precedence is
>> not often what I want.)
>> Bill Dunlap
>> TIBCO Software
>> wdunlap tibco.com
>>
>>
>> On Tue, May 6, 2014 at 1:06 PM, Hervé Pagès <hpa...@fhcrc.org> 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 <- 2:1
>>> > set <- 1:6
>>> > - els%in%set
>>> [1] FALSE FALSE
>>> > - is.element(els,set)
>>> [1] -1 -1
>>>
>>> So following your advice doesn't really help me leave my precedence
>>> problems behind.
>>>
>>>
>>> H.
>>>
>>>> Bill Dunlap
>>>> TIBCO Software
>>>> wdunlap tibco.com
>>>>
>>>>
>>>> On Tue, May 6, 2014 at 12:23 PM, Hervé Pagès <hpa...@fhcrc.org> wrote:
>>>>>
>>>>>
>>>>> 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 behind.
>>>>>> Bill Dunlap
>>>>>> TIBCO Software
>>>>>> wdunlap tibco.com
>>>>>>
>>>>>>
>>>>>> On Mon, May 5, 2014 at 10:35 PM, peter dalgaard <pda...@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 06 May 2014, at 01:05 , Hervé Pagès <hpa...@fhcrc.org> 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 here is that the %foo% operators all have the _same_
>>>>>>> precedence. In principle, they can be user-coded, and there is no way
>>>>>>> to
>>>>>>> express what precedence is desirable. It may turn out slightly weird
>>>>>>> for
>>>>>>> %in%, but think of what would happen if %*% had lower precedence than
>>>>>>> addition.
>>>>>>>
>>>>>>> --
>>>>>>> Peter Dalgaard, Professor,
>>>>>>> Center for Statistics, Copenhagen Business School
>>>>>>> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
>>>>>>> Phone: (+45)38153501
>>>>>>> Email: pd....@cbs.dk Priv: pda...@gmail.com
>>>>>>>
>>>>>>> ______________________________________________
>>>>>>> R-devel@r-project.org mailing list
>>>>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Hervé Pagès
>>>>>
>>>>> Program in Computational Biology
>>>>> Division of Public Health Sciences
>>>>> Fred Hutchinson Cancer Research Center
>>>>> 1100 Fairview Ave. N, M1-B514
>>>>> P.O. Box 19024
>>>>> Seattle, WA 98109-1024
>>>>>
>>>>> E-mail: hpa...@fhcrc.org
>>>>> Phone: (206) 667-5791
>>>>> Fax: (206) 667-1319
>>>
>>>
>>>
>>> --
>>> Hervé Pagès
>>>
>>> Program in Computational Biology
>>> Division of Public Health Sciences
>>> Fred Hutchinson Cancer Research Center
>>> 1100 Fairview Ave. N, M1-B514
>>> P.O. Box 19024
>>> Seattle, WA 98109-1024
>>>
>>> E-mail: hpa...@fhcrc.org
>>> Phone: (206) 667-5791
>>> Fax: (206) 667-1319
>
>
> --
> Hervé Pagès
>
> Program in Computational Biology
> Division of Public Health Sciences
> Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N, M1-B514
> P.O. Box 19024
> Seattle, WA 98109-1024
>
> E-mail: hpa...@fhcrc.org
> Phone: (206) 667-5791
> Fax: (206) 667-1319
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
