疑问：数值列变量num为何使用eval(parse模式？旧版R是否有用？

代码合理性判断 #

如果num是整数或双精度类型的数值列，这段代码纯粹是冗余写法，完全没必要：

• 把数值转成字符、再解析成表达式最后求值，得到的结果和直接写num_val <- num完全一致。
• 这种写法既拖慢运行效率，还平白引入了eval(parse(...))的潜在风险——虽然这里num是数值型，风险几乎为零，但写法本身不符合R的规范。

旧版R中的可能场景 #

在早期R版本（比如2.x系列）里，针对数值型的num，这种模式也没有正经的实用场景。只有在一些极端特殊的非典型情况（和你说的「num来自数值列」不匹配）下，才可能被用到：

• 比如有人把表达式转成ASCII码存成数值，再用这种方式还原成表达式，但这种需求极其小众，几乎碰不到。
• 还有可能是旧脚本里的错误补救：本来num应该是字符型的数值表达式（比如"3*5"），结果被误转成了数值，开发者就用这种写法试图「修正」，但这属于错误的处理方式，不是合理场景。

总结下来，就你描述的场景而言，这段代码既不合理，在旧版R里也没有对应的实用价值，属于冗余或错误的写法。

内容的提问来源于stack exchange，提问作者Natrave Drova