search for: jbrzusto

...The source of this code mentions a bug in the original code that effects both methods 'median' and 'centroid'. This program has a fix for this bug, but I can find no similar fix in the code of R's hclust. You can find the program with the fix at: http://www2.biology.ualberta.ca/jbrzusto/ftp/trees/source.zip The relevant file is: qclust.c The bug is mentioned at line 670 of that code. The fix for the bug starts at line 908. Unfortunatly, I do not know Fortran programming, so I can not offer a tested solution for hclust. I hope I have located the problem accurately enough for other...

Full_Name: John Brzustowski Version: R-devel-trunk, R-2.4.0 OS: linux, gcc 4.0.3 Submission from: (NULL) (206.248.157.184) This isn't a bug, but an easily-remedied performance issue. SYMPTOM > for (i in 1000 * (1:20)) { y <- paste(rep("asdf", times=i), collapse=" ") t <- system.time(strsplit(y, " ", fixed=TRUE)) cat(sprintf("i=%5d

Full_Name: John Brzustowski Version: R-devel-trunk OS: linux (problem under Windows too) Submission from: (NULL) (74.101.124.238) (This bug was discovered by Phil Taylor, Acadia University.) I'm not sure from reading the documentation whether strptime(x, "%j") is meant to be supported, but if so, there is a bug which prevents it from working on the first day of months after

R-ecologists: Anyone wanting to create a Krebs package for R can do so using the C-source code avalaible at: ftp://gause.biology.ualberta.ca/pub/jbrzusto/krebs/source.zip Barry J. Cooke Current mailing address: Ph.D. Candidate 3971 NW 23 Circle Environmental Biology and Ecology Gainesville, Florida, USA Department of Biological Sciences 32605 University of Alberta Edmonton, AB, T6G 2E9 h...

Full_Name: John Brzustowski Version: R-devel-trunk, R-2.4.0 OS: linux Submission from: (NULL) (206.248.132.197) DESCRIPTION seek() on files larger than 2 gigabytes fails for large values of "where" on i386 linux 2.6.13 (and presumably other 32-bit unix-like platforms). e.g.: > f<-file("3gigabytefile.dat", "rb") > seek(f, 3e9, "start",

Hi, In trying to build R 1.9.0, I ran into a problem building the x11() device support under XFree86 4.4.0: make[4]: Entering directory `/home/john/build/R-1.9.0/src/modules/X11' gcc -I. -I../../../src/include -I../../../src/include -I/usr/X11R6/include -I/usr/local/include -DHAVE_CONFIG_H -fPIC -g -O2 -c dataentry.c -o dataentry.lo In file included from dataentry.c:31:

Full_Name: John Brzustowski Version: R-devel trunk and R-2.4.0 OS: linux Submission from: (NULL) (76.10.152.79) Here are two minor potential issues in pointer protection stack (PPS) code which could arise in debugging R with valgrind. Only the second could possibly cause a problem in normal use of R, and only under laughably implausible circumstances. (1) valgrind is given a wrong address when

Full_Name: John Brzustowski Version: 2.8.1 OS: linux Submission from: (NULL) (67.71.250.146) When entering a debug()'ed function, the call printout is not limited by options()$deparse.max.lines as it is when one uses browser() or trace(). Should it be? If so, here's a patch: diff -cr R-2.8.1/src/library/base/man/options.Rd R-2.8.1-patched/src/library/base/man/options.Rd ***

Hello, If repeated calls are made to save() using the same pre-opened gzfile connection to a file, and then the connection is closed, the objects saved by the second and subsequent calls are not correctly restored by repeated calls to load() with a new gzfile connection to the same file. What follows are a session exposing the bugs, analysis (see ANALYSIS), patches (see PATCHES), and a session