From wdunlap at tibco.com  Tue May  6 22:44:56 2014
From: wdunlap at tibco.com (William Dunlap)
Date: Tue, 6 May 2014 13:44:56 -0700
Subject: [Rd] Historical NA question
In-Reply-To: <5369460B.8000607@fhcrc.org>
References: <CABdHhvFt2n6=ORLBSTYxkA_G+t_d_H=0B1+vhhM_ZFL_Z-RT3g@mail.gmail.com>
	<5366EAC6.9030109@yorku.ca> <53681944.9020606@fhcrc.org>
	<4BBA43DC-39CB-4CCC-9172-E2318459FD77@gmail.com>
	<CAF8bMcbt5j70eLj_ijMTvX5wFmXW_ZCrMTYzZO6MovASADnhuA@mail.gmail.com>
	<53693699.9080502@fhcrc.org>
	<CAF8bMcaWp9Wa91uPncwR7EF+UdSkRVUNa1DnppkGPVwo-iV25Q@mail.gmail.com>
	<536940D3.7060008@fhcrc.org>
	<CAF8bMcYFP-hPPLG-z26+_=1K5T0EzE0-4_aCbq7jhpHLc7bqCw@mail.gmail.com>
	<5369460B.8000607@fhcrc.org>
Message-ID: <CAF8bMcb=3jrccyPjr34oFcwE7hpOt_CG=q4sW870DRbtaTX2Mw@mail.gmail.com>

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 <hpages at 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 <hpages at 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 <hpages at 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 <pdalgd at gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 06 May 2014, at 01:05 , Herv? Pag?s <hpages at 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.mes at cbs.dk  Priv: PDalgd at gmail.com
>>>>>>>
>>>>>>> ______________________________________________
>>>>>>> R-devel at 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: hpages at 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: hpages at 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: hpages at fhcrc.org
> Phone:  (206) 667-5791
> Fax:    (206) 667-1319



[Rd] Historical NA question
William Dunlap