R中调试的一般建议

Question

R中调试的一般建议

我在使用我编写的R函数时出错：

Warning messages:1: glm.fit: algorithm did not converge 
2: glm.fit: algorithm did not converge

我所做的：

1. 逐步完成功能
2. 添加打印以找出错误发生在哪一行，这意味着两个不应该使用的函数

   glm.fit

   ..他们是

   window()

   和

   save().

我的一般方法包括添加print和stop命令，并逐行遍历函数，直到找到异常为止。

但是，我不清楚这些技术是从代码中产生错误的。我甚至不确定代码中的哪些函数依赖于glm.fit..我该如何诊断这个问题？

Answer 1

我认为调试是一种艺术形式，所以没有明确的银弹。在任何语言中都有很好的调试策略，它们也适用于这里。读这篇好文章)。例如，第一件事是重现问题.如果你不能这样做，那么你需要获得更多的信息(例如，通过日志记录)。一旦你能复制它，你就需要减少一直到源头。与其说是“技巧”，不如说我有一个最喜欢的调试例程：当发生错误时，我通常做的第一件事是通过调用traceback()：这显示了错误发生的位置，如果您有几个嵌套函数，这一点尤其有用。接下来我会options(error=recover)这会立即切换到出现错误的浏览器模式，这样您就可以从那里浏览工作区。如果我仍然没有足够的信息，我通常使用debug()函数并逐行遍历脚本。R2.10中最好的新技巧(当处理脚本文件时)是使用findLineNum()和setBreakpoint()职能。作为最后的评论：根据错误，设置它也是非常有帮助的。try()或tryCatch()关于外部函数调用的语句(特别是在处理S4类时)。这有时会提供更多的信息，而且还能让您更好地控制在运行时如何处理错误。这些相关问题有很多建议：R语言的调试工具调试lapplication/sapplication调用在R中发生错误后获取变量的状态错误的脚本行号？

Answer 2

正如我所指出的另一个问题,&nbsp;Rprof()和summaryRprof()是很好的工具查找程序的慢部分这可能从加速或迁移到C/C+实现中获益。如果您正在进行模拟工作或其他计算机或数据密集型活动，这可能更适用。这个profr包装可以帮助可视化结果。我对调试有一点了解，所以另一个建议是另一个线程:集options(warn=2)将警告视为错误您也可以使用options在发生错误或警告时，使用您所选择的最喜欢的调试功能，将您直接放到操作的热度中。例如：集options(error=recover)跑recover()当发生错误时，正如Shane所指出的(如r调试指南..或者任何其他你认为有用的函数都可以运行。另外两种方法来自“Shane‘s”中的一种链接:将内部函数调用包装为try()若要返回更多信息，请执行以下操作。对于*应用函数，使用.inform=TRUE(来自plyr包)作为Apply命令的选项@JoShuaUlrich还指出运用经典的条件能力的巧妙方法browser()命令打开/关闭调试：放入您可能要调试的函数中。browser(expr=isTRUE(getOption("myDebug")))并将全局选项设置为options(myDebug=TRUE)您甚至可以包装浏览器调用：myBrowse <- browser(expr=isTRUE(getOption("myDebug")))然后打电话给myBrowse()因为它使用了全局。还有R2.10中的新功能：findLineNum()获取源文件名和行号，并返回函数和环境。当你source()一个.R文件，它在#n行返回一个错误，但是您需要知道#n行中的函数是什么。setBreakpoint()获取源文件名和行号，并在其中设置断点。这个码器包，特别是其checkUsage函数在快速获取编译器通常会报告的语法和样式错误(未使用的局部变量、未定义的全局函数和变量、部分参数匹配等)方面尤其有帮助。setBreakpoint()是一个更方便用户的前端trace()..有关如何工作的内部结构的详细信息，可在最近R杂志的文章.如果您正在尝试调试其他人的包，一旦您找到了问题，您可以重写它们的函数带着fixInNamespace和assignInNamespace，但不要在生产代码中使用此方法。所有这些都不应排除尝试过的真实。标准R调试工具，其中一些在上面，另一些则不在上面。特别是，验尸调试工具当您有一堆您不希望重新运行的耗费时间的代码时，非常方便。最后，对于似乎不会抛出错误消息的棘手问题，可以使用options(error=dump.frames)如本问题所详述：没有引发错误的错误