R help - Nov 2008 - question about the "Y of R" article in the latest R news

I found the article the "Y of R" in the latest R news to be very
interesting. It is certainly challenging me to learn more about how R works
"under the hood" as the author states. What is less clear to me is
whether
this approach is primarily for teaching purposes or has a real world
application. What is meant by "fragility of reliance on the function
name defined as a global variable" as a downside to the classical recursive
formulation of function "s"? How can that impact the average R
programmer?

Beyond that, empiricist that I am, I decided to put the examples to the
test. My source code and output is below, but the bottom line consists of 2
observations:

   - The Y function approach using csum is consistently slower on my machine
   that the s function approach
   - The Y function using csum gives recursive error with high input values
   just like the s function does
   - The Y function in fact reaches the limit of recursion BEFORE the s
   function does

Given that it is slower, is more cumbersome to write, and has a lower
nesting limit than the classical approach, I wonder about its utility for
the average programmer (or somewhat below average programmer like me).

Okay, here's my code, output, and sessionInfo()

s <- function(n) {
  if (n == 1) return(1)
  return(s(n-1)+n)
}


Y <- function(f) {
  g <- function(h) function(x) f(h(h))(x)
  g(g)
}

csum <- function(f) function(n) {
  if (n < 2) return(1);
  return(n+f(n-1))
}

recurs.time <- matrix(0, ncol = 3, nrow = 100)
Y.time <- matrix(0, ncol = 3, nrow = 100)

for (i in 1:100) recurs.time[i,] <- unclass(system.time(a <- s(996)))[1:3]
ave.recurs.time <- colSums(recurs.time)
ave.recurs.time

for (i in 1:100) Y.time[i,] <- unclass(system.time(b <- Y
(csum)(996)))[1:3]
ave.Y.time <- colSums(Y.time)
ave.Y.time

u <- s(1000)
u

v <- Y (csum)(1000)
v

sessionInfo()
> s <- function(n) {
+   if (n == 1) return(1)
+   return(s(n-1)+n)
+ }
>
>
> Y <- function(f) {
+   g <- function(h) function(x) f(h(h))(x)
+   g(g)
+ }
>
> csum <- function(f) function(n) {
+   if (n < 2) return(1);
+   return(n+f(n-1))
+ }
>
> recurs.time <- matrix(0, ncol = 3, nrow = 100)
> Y.time <- matrix(0, ncol = 3, nrow = 100)
>
> for (i in 1:100) recurs.time[i,] <- unclass(system.time(a <-
s(996)))[1:3]
> ave.recurs.time <- colSums(recurs.time)
> ave.recurs.time
[1] 0.356 0.004 0.355
>
> for (i in 1:100) Y.time[i,] <- unclass(system.time(b <- Y
(csum)(996)))[1:3]
> ave.Y.time <- colSums(Y.time)
> ave.Y.time
[1] 0.652 0.000 0.640
>
> u <- s(1000)
> u
[1] 500500
> v <- Y (csum)(1000)
Error: evaluation nested too deeply: infinite recursion /
options(expressions=)?
Error during wrapup: evaluation nested too deeply: infinite recursion /
options(expressions=)?
> v
Error: object "v" not found
No suitable frames for recover()
------------------------------------------------------------
Mark W. Kimpel MD  ** Neuroinformatics ** Dept. of Psychiatry
Indiana University School of Medicine

15032 Hunter Court, Westfield, IN  46074

(317) 490-5129 Work, & Mobile & VoiceMail
(317) 399-1219  Home
Skype:  mkimpel

"The real problem is not whether machines think but whether men do."
-- B.
F. Skinner
******************************************************************

	[[alternative HTML version deleted]]

On Sat, Nov 8, 2008 at 5:09 PM, Mark Kimpel <mwkimpel at gmail.com>
wrote:
> I found the article the "Y of R" in the latest R news to be very
> interesting. It is certainly challenging me to learn more about how R works
> "under the hood" as the author states. What is less clear to me
is whether
> this approach is primarily for teaching purposes or has a real world
> application. What is meant by "fragility of reliance on the function
> name defined as a global variable" as a downside to the classical
recursive
> formulation of function "s"? How can that impact the average R
programmer?
The entire sentence is:
"We can avoid the fragility of reliance on the function
name defined as a global variable, by invoking
the function through Recall instead of using selfreference."
so he is referring to the fact that if one self-references the function by name
then renaming the function causes it to no longer work.  That is there
is fragile dependence on the function name.  He points out that the R
function, Recall, can be used to avoid that.

On Sat, 8 Nov 2008, Mark Kimpel wrote:
> I found the article the "Y of R" in the latest R news to be very
> interesting. It is certainly challenging me to learn more about how R works
> "under the hood" as the author states. What is less clear to me
is whether
> this approach is primarily for teaching purposes or has a real world
> application. What is meant by "fragility of reliance on the function
> name defined as a global variable" as a downside to the classical
recursive
> formulation of function "s"? How can that impact the average R
programmer?
>
> Beyond that, empiricist that I am, I decided to put the examples to the
> test. My source code and output is below, but the bottom line consists of 2
> observations:
>
>    - The Y function approach using csum is consistently slower on my
machine
>    that the s function approach
>    - The Y function using csum gives recursive error with high input values
>    just like the s function does
>    - The Y function in fact reaches the limit of recursion BEFORE the s
>    function does
>
> Given that it is slower, is more cumbersome to write, and has a lower
> nesting limit than the classical approach, I wonder about its utility for
> the average programmer (or somewhat below average programmer like me).
>
Thanks for your comments and to Gabor for some clarification.  Your
empirical study adds to our knowledge of the situation.  I considered
the implementation of Y in R to be of conceptual interest only, and I
probably should have said that.  Even the conceptual considerations
may admit of improvement, as there are use-mention distinctions that are
murky in various points in the text.  But I will not be able to revisit
this, apart from dealing with major misconceptions if such exist, in the
foreseable future.