Re: Historical NA question (Herv? Pag?s)

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: Historical NA question (Herv? Pag?s)

Georgi Boshnakov
"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: [hidden email]
Oxford Road
Manchester M13 9PL
UK

________________________________________
Date: Tue, 06 May 2014 13:57:14 -0700
From: Herv? Pag?s <[hidden email]>
To: William Dunlap <[hidden email]>
Cc: Michael Friendly <[hidden email]>,       "[hidden email]"
        <[hidden email]>
Subject: Re: [Rd] Historical NA question
Message-ID: <[hidden email]>
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 06 May 2014, at 01:05 , Herv? Pag?s <[hidden email]> 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: [hidden email]  Priv: [hidden email]
>>>>>>>>
>>>>>>>> ______________________________________________
>>>>>>>> [hidden email] 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: [hidden email]
>>>>>> 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: [hidden email]
>>>> 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: [hidden email]
>> 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: [hidden email]
Phone:  (206) 667-5791
Fax:    (206) 667-1319



______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel