Some related suggestions: 1. instead of dataFrame[condition, ], use
>>>>>>>>>>> subset() <<<<<<<<<<< which has an inbuilt test for !is.na(condition). This function is not documented in the Introduction or cross-referenced by ?"[", so should be posted to this list at least once a week until everybody knows about it. (Sorry Martin M. that I still have not done what I promised re documentation. The ink has faded so much on the sticky reminder that I can't read it any more.) 2. consider using an editor with definable keyboard macros. There's nothing quicker, or easier to debug, than plain old, bottom level !is.na, but you can get there by typing F1 if you set it up that way. 3. I have a very old brown-covered book describing macros in the S language (version 1? I don't have it to hand to check). When and why did they disappear? (Hoping John Chambers is reading this.) > -----Original Message----- > From: Thomas Lumley [mailto:[EMAIL PROTECTED] > Sent: 20 October 2003 23:03 > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: [R] "aliases" for R constructs? > > > Security Warning: > If you are not sure an attachment is safe to open please contact > Andy on x234. There are 0 attachments with this message. > ________________________________________________________________ > > On Mon, 20 Oct 2003 [EMAIL PROTECTED] wrote: > > > Hi Folks, > > > > My recent response to Laura Quinn's query about matrix subsetting > > reminded of a question. > > > > I wrote: > > > > iDir <- ((Winds[,20]<45)|(Winds[,20]>315))&(!is.na(Winds[,20])) > > > > Now, I find "!is.na" a bit awkward to type, so I might prefer to > > type it as "nis.na". > > > > While it is possible to define > > > > nis.na <- function(x){ !is.na(x) } > > > > this involves a slight bloat of overhead in execution since > achieving > > !is.na involves an extra layer of function call. So is it possible > > to define an "alias" so that > > > > nis.na(x) > > > > is _exactly_ equivalent to > > > > !is.na(x) > > > > No, R doesn't have macros. As R is interpreted, a macro wouldn't > necessarily save you any execution time -- Lisp macros, IIRC, are only > expanded at compile-time. > > You can get most of the programming advantages of macros with > substitute > and eval, but this is presumably slower rather than faster. > > > -thomas > > ______________________________________________ > [EMAIL PROTECTED] mailing list > https://www.stat.math.ethz.ch/mailman/listinfo/r-help > Simon Fear Senior Statistician Syne qua non Ltd Tel: +44 (0) 1379 644449 Fax: +44 (0) 1379 644445 email: [EMAIL PROTECTED] web: http://www.synequanon.com Number of attachments included with this message: 0 This message (and any associated files) is confidential and\...{{dropped}} ______________________________________________ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-help
