From wdunlap at tibco.com  Tue May  6 17:54:17 2014
From: wdunlap at tibco.com (William Dunlap)
Date: Tue, 6 May 2014 08:54:17 -0700
Subject: [Rd] Historical NA question
In-Reply-To: <4BBA43DC-39CB-4CCC-9172-E2318459FD77@gmail.com>
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>
Message-ID: <CAF8bMcbt5j70eLj_ijMTvX5wFmXW_ZCrMTYzZO6MovASADnhuA@mail.gmail.com>

You can also use is.element(els,set) instead of the equivalent
els%in%set 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



[Rd] Historical NA question
William Dunlap