search for: ubbw

Hi All, I've gotten a number of reports from users about gplots::heatmap.2 generating 'node stack overflow' errors. As it turns out, these errors originate in stats:::plotNode, and are triggered when it is passed a dendrogram that is too deeply nested. While increasing the stack size (which is a compile-time option for byte coded functions) can allow a particular instance to

I've noticed that the arguments and result list of prcomp in the mva package (with 61.1) are not quite the same as in the Blue Book and in Splus. Is this intentional or can I change it? If I change it who should I send the code to? Paul Gilbert -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read

L.S. I noticed weird tools::texi2dvi behaviour on R-alpha when specifying an absolute path to the .tex file. The same phenomenon also appears to occur on R-2.12.2, so maybe the issue is independent of R. I hope I did not overlook any important information. Best, Tobias > require(tools) Loading required package: tools > getwd() [1] "/home/tobias" >

There is a contradiction between what the help page says and what constrOptim actually does with the constraints. The issue is what happens on the boundary. The help page says The feasible region is defined by ?ui %*% theta - ci >= 0?, but the R code for constrOptim reads if (any(ui %*% theta - ci <= 0)) stop("initial value not feasible") The following example

I find it a bit peculiar that a package skeleton created with a utils function package.skeleton() fails subsequent R CMD check. I do understand that the function is intended to produce only a skeleton that should be edited by the package author. I think that it would be justified to say that the skeleton *should* fail the test. However, I have two arguments against intentional failure: * When you