How can I avoid nested 'for' loops or quicken the process?
Prof Brian Ripley wrote:
On Thu, 25 Dec 2008, Oliver Bandel wrote:
....
The apply-functions do bring speed-advantages. This is not only what I read about it, I have used the apply-functions and really got results faster. The reason is simple: an apply-function does make in C, what otherwise would be done on the level of R with for-loops.
Not true of apply(): true of lapply() and hence sapply(). I'll leave you to check eapply, mapply, rapply, tapply. So the issue is what is meant by 'the apply() family of functions': people often mean *apply(), of which apply() is an unusual member, if one at all.
Conceptually, I think it belongs there. apply(M,1,max) is similar to tapply(M,row(M),max), etc. The "apply-functions" share a general split-operate-reassemble set of semantics, and apply _could_ be implemented as splitting by indices in MARGINS, followed by lapply, followed by reassembly into a matrix, as in tapply(). In reality, apply() is implemented differently, using aperm() and direct indexing. This is more efficient, but it shouldn't necessarily change the way in which we think about it. It is a bit unfortunate that the most complex mamber of the family has gotten the most basic name, though.
[Historical note: a decade ago lapply was internally a for() loop. I rewrote it in C in 2000: I also moved apply to C at the same time but it proved too little an advantage and was reverted. The speed of lapply comes mainly from reduced memory allocation: for() is also written in C.]
O__ ---- Peter Dalgaard ?ster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) FAX: (+45) 35327907