"Equivalence" certainly does not mean that literally replacing some
text will not change the result.
>From "R language definition", p. 11:
> Except for the syntax, there is no difference between applying an operator
and calling a
function. In fact, x + y can equivalently be written ?+?(x, y). Notice that
since ?+? is a nonstandard
function name, it needs to be quoted.
A doubt that anybody would interpret the above as implying that the following
expressions should be equivalent:> 2 * 2 + 2
> 2 * "+"(2,2)
I believe that S's %xxx% notation predates Mathematica's generic infix,
~XXX~, notation, which also has high priority, independent of the meaning of the
symbol XXX.
--
Dr Georgi Boshnakov tel: (+44) (0)161 306 3684
School of Mathematics fax: (+44) (0)161 306 3669
Alan Turing Building 1.125
The University of Manchester email: Georgi.Boshnakov at manchester.ac.uk
Oxford Road
Manchester M13 9PL
UK
________________________________________
Date: Tue, 06 May 2014 13:57:14 -0700
From: Herv? Pag?s <hpages at fhcrc.org>
To: William Dunlap <wdunlap at tibco.com>
Cc: Michael Friendly <friendly at yorku.ca>, "r-devel at
r-project.org"
<r-devel at r-project.org>
Subject: Re: [Rd] Historical NA question
Message-ID: <53694CAA.3080808 at fhcrc.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
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() 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%.
Thanks Bill. I appreciate that you are really trying to help me with my
"precedence problem". Maybe I should clarify that I can live with it
though. Anyway, it's always good to know how to make substitutions in
the parse tree.
Cheers,
H.
>
> 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
--
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
