Epiverse-TRACE developer space - Lesser-known reasons to prefer apply() over for loops

[giscus[bot]]

Epiverse-TRACE developer space - Lesser-known reasons to prefer apply() over for loops

A place for Epiverse-TRACE developers to share their reflections, learnings, and showcase their work.

https://epiverse-trace.github.io/posts/for-vs-apply/

[cellocgw]

The index variable doesn't "Leak" anywhere. It is defined inside its own environment, so any for-loop inside a closure will not affect any variable in the .globalenv. but in any case, only a fool fails to set all named loop indices to names never used anywhere else.

[rfhb]

where apply functions can’t: when the next step depends on the previous one. This concept is known as recursion.

Isn't rapply for this purpose? See https://stat.ethz.ch/R-manual/R-devel/library/base/html/rapply.html

[Bisaloo]

The name can lead you to believe so, but no. "Recursive" in rapply() means it can go down in nested lists and apply the function FUN on internal elements.

The help page jumps straight to more complex examples but here is a simpler one:

x <- list(a = 3, b = list(c = 2))

# We can see that a and c are not at the same level of nestedness
str(x)
#> List of 2
#>  $ a: num 3
#>  $ b:List of 1
#>   ..$ c: num 2

# Yet `rapply()` manages to apply `sqrt()` on both `a` and `c`
rapply(x, sqrt)
#>        a      b.c 
#> 1.732051 1.414214

^{Created on 2023-11-06 with reprex v2.0.2}

In this example, you can see that there not interdependence between the different elements. We're really in the case of iterating a function on a complex list.

Outside of the apply() family, there are indeed functions to work with recursion though: Reduce() / purrr::reduce(). You can read more about this in the dedicated section in the "Advanced R" book by Hadley Wickham, or this blog post by Maëlle Salmon.

Thanks a lot for pointing out something that should have been clarified in the original post! 🙏