I came across the following code and wondering if there is a reason for this given that the num variable comes from a numeric column (integer or double).

num_val <- eval(parse(text = num %>% as.character()))

Could it be a pattern that is (was) useful for something in older versions of R?

CodePudding user response：

No, that hasn't really changed for a very long time.

• It allows strings like "1 1" to be evaluated and stored as the result (i.e. 2).
• If num was already numeric, it would have the effect of rounding it to the value that as.character() would calculate. Typically that value is not affected by the options("digits") setting and is usually much more precise, but it's not quite the same precision as used internally.
• If num held an integer, that would convert it to a double.
• If num held a vector of values, that would evaluate all of them, then only keep the last one.

I'd have to see the context, but I can't think of any useful reason to use code like that if num was known to be numeric. Only the first reason (allowing users to enter expressions instead of numbers) would make sense.

CodePudding user response：

A very good general piece of advice is to never use the eval(parse( combination in your own code. From the fortunes package:

> library(fortunes)
> fortune(106)

If the answer is parse() you should usually rethink the question.
   -- Thomas Lumley
      R-help (February 2005)

There is almost always a better alternative in R, the above code looks like a more complicated, hard to understand version of:

num_val <- as.numeric(as.character(num))

if the values in num are numbers, or a factor with numeric labels then this works (there is a slightly more efficient version in the FAQ). The eval-parse method would work if num contained something like "c(1,4,6)" or "1:10", but in those cases it would probably be better to figure out where num is coming from that it would contain something like the above and figure out a better workflow.

Using eval and parse can be dangerous (if num contains some attack code, then this could cause major problems) and very hard to debug (google for "debug action at a distance").

That said, there is code out there where the programmers used parse and eval as a quick and dirty (but not best) way to do something, then that code was copied and modified and people took the quick and dirty approach to somehow be a reasonable approach, so things like this are out there. But you best approach (for good code and learning to be a better R programmer) is to find better options and never use eval(parse(.

My own contribution to fortunes on this topic:

> fortune(181)

Personally I have never regretted trying not to underestimate my own future
stupidity.
   -- Greg Snow (explaining why eval(parse(...)) is often suboptimal, answering a
      question triggered by the infamous fortune(106))
      R-help (January 2007)