[Rd] Historical NA question

William Dunlap wdunlap at tibco.com
Tue May 6 22:15:09 CEST 2014


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 expression, not the text.  If
you used is.element in the first place you would avoid precedence
issues.  (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



More information about the R-devel mailing list