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 <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 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
