RE: [Rd] Very Long Expressions

From: McGehee, Robert <Robert.McGehee_at_geodecapital.com>
Date: Tue 25 Jan 2005 - 02:02:39 EST


Thank you all for your reply. This was exactly what I was looking for. Two quick points. One, as Peter Dalgaard pointed out, wrapping the expression in a try() gives this error:

Error in eval(expr, envir, enclos) : evaluation nested too deeply:

   infinite recursion / options(expression=)?

                                         ^^^
However, from the following posts, it seems that options(expressions=) (plural) is what we're looking for instead. If so, this error message should be corrected anyway.

Secondly, the ?options help (thanks for everyone who reminded me about this), says that expressions can have values between 25...100000.

However, if the original example is set past 4995 on my computers, I receive a stack overflow.
> eval(parse(text = paste(rep(1, 4996), collapse = "+")))
Error: protect(): stack overflow

I'm pointing this out not because I will ever approach anywhere near this level of nesting, but perhaps that options(expression=5000+) might not be meaningful anyway, (unless there are processor/compilation-specific ways of getting rid of this stack overflow). If so, one might considering lowering the range of valid expressions values in the help file.

Thanks again, your replies are, as always, invaluable, Robert

-----Original Message-----
From: Peter Dalgaard [mailto:p.dalgaard@biostat.ku.dk] Sent: Monday, January 24, 2005 5:36 AM
To: McGehee, Robert
Cc: r-devel@stat.math.ethz.ch
Subject: Re: [Rd] Very Long Expressions

"McGehee, Robert" <Robert.McGehee@geodecapital.com> writes:

> Greetings,
> I'm having some difficulties with evaluating very long expressions
> (Windows/Linux 2.0.1), as seen below, and would greatly appreciate any
> help, thoughts or work arounds. Let's say that I wanted to see what I
> would get if I added 1 to itself 498 times. One way of doing this
would
> be to evaluate the expression 1+1+1+...
>
> > eval(parse(text = paste(rep(1, 498), collapse = "+")))
> [1] 498
>
> However, if we try this with 499+ items we get no answer:
> > a <- eval(parse(text = paste(rep(1, 499), collapse = "+")))
> > a
> Error: Object "a" not found
>
> And if this eval is passed to any other function, that function exits
> without error and without returning and object.
>
> So it seems that we've reached some upper limit of evaluation terms.
> While the parser is able to correctly create the long expression, eval
> does not successfully evaluate it.
 

> My problem is that since the evaluator does not return an object,
error,
> or warning, I'm not able to easily code around this problem. Also,
I've
> thought of no easy way to "count" the terms in the expression to see
> whether we've breached the upper limit or not.

It's a bug. 1.9.1 had

> eval(parse(text = paste(rep(1, 499), collapse = "+")))
Error in eval(expr, envir, enclos) : evaluation nested too deeply:

   infinite recursion / options(expression=)?

which also contains the hint about how to raise the limit.

You do see it if you do

> a <- try(eval(parse(text = paste(rep(1, 499), collapse = "+"))))
> a

[1] "evaluation nested too deeply: infinite recursion / options(expression=)?"
attr(,"class")
[1] "try-error"

but that's obviously no excuse for not printing the message. The problem appears still to be present in r-devel (the version at hand was dated Jan.12, though).

> If I were able to see if the eval would work on a particular
expression,
> one thing I had considered was to make an eval.long wrapper that peels
> terms off the right hand side of an overly-long expression until every
> sub-expression is legal.

But do you *really* want to do it this way? Why?

BTW, it's not really the length of the expression but its depth. The parse tree for 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 is really (((((((1+2)+3)+4)+5)+6)+7)+8). So you get 7 levels of parentheses. You can easily have less deeply nested parentheses: ((1+2)+(3+4))+((5+6)+(7+8))

With that sort of pattern, adding 500 terms requires a nesting no more than 9 levels deep. Persuading R to nest that way is a bit tricky though.

-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907

______________________________________________
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Received on Tue Jan 25 01:38:42 2005

This archive was generated by hypermail 2.1.8 : Fri 18 Mar 2005 - 09:02:41 EST