Re: [Rd] MacOS X: update.packages(type=mac.binary) fails (PR#7834)
Dear Mr Moderator, please let me through. I want to reply to my own thread. I once subscribed to this list, but then my subscription was not accepted. Now to the business: The final failure came from missing .install.macbinary() function. I grepped R-patched sourcesand the only instance of .install.macbinary() was the call to the function in R- patched/src/library/utils/R/packages2.R (stupid automatic linefeed in mail composer: just parse it). There was no definition of the function, so I don't know from where should that function be loaded. I looked at the R-patched/src/library/utils/R/aqua/GUI.R today (it was the only file in that directory), and it had a function install.binaries() (but no .install.macbinary()). So it might be that .install.macbinary() function was supposed to call this function, and there is a naming conflict. My intention was to look at editing this piece today so that I would change the call of .install.macbinary() into call of install.binaries, but the sanguine(*) R in MacOS X refuses to start in GUI mode today with uninformative error message (The application R has unexpectedly quit.). So it seems not be the only problem in the MacOS X build of R at CRAN. Starting from bash prompt in Terminal.app fails as well with error .onLoad failed in 'loadNamespace' for 'tcltk'. After starting X, R starts even from Terminal.app, but still fails when clicking the icon. Anyway, I hope this helps. (*) you may replace this with a synonymous Saxon adjective (English word, Germanic/Norse origin). On Tue, 2005-05-03 at 16:14 +0100, Prof Brian Ripley wrote: Binary installs are AFAIK only supported in the GUI, where the default is as documented. So .install.macbinary() is not loaded except in the GUI. The reason is that those binaries are tied to that particular build of R, and will not work with a general build on MacOS X. I would expect this to work from the command-line in the GUI console, and had believed it had been tested there. On Tue, 3 May 2005 [EMAIL PROTECTED] wrote: Full_Name: Jari Oksanen Version: R 2.1.0 OS: MacOS 10.3.9 Submission from: (NULL) (130.231.102.145) For various reasons (which need not be expanded here) I have tried to update my long neglected R in MacOS X using handy command line tool update.packages() using readily available binaries of contributed packages at CRAN. However, this fails with message saying that packages _*_tar.gz is not found at the server (HTTP error 404). Obviously, the package name is expanded wrongly as the binary packages for MacOS X have type *.tgz. However, this seems not be the problem, but there are two other problems: 1. update.packages does not transfer the value of 'type' to the next function install.packages, but install.packages uses the value of getOption(pkgType) which seems to be source in CRAN binary of MacOS X (contrary to documentation at ?options). 2. If this is corrected, or first set options(pkgType=mac.binary), the update fails for missing function .install.macbinary(). The first problem is easy to correct: --- update.packages.R 2005-05-03 17:13:36.0 +0300 +++ jarioksa.update.packages.R 2005-05-03 17:13:58.0 +0300 @@ -59,5 +59,5 @@ install.packages(update[, Package], instlib, contriburl = contriburl, method = method, available = available, destdir = destdir, -installWithVers = installWithVers, type) +installWithVers = installWithVers, type = type) } } For the second, problem, I don't know what to do. grepping R-patched_2005-05-03.tar.gz source found only one instance of .install.macbinary(): the failed call in R-patched/src/library/utils/R/packages2.R. I couldn't find the definition of the function. Do I really have to use GUI? Uh. cheers, jari oksanen __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Jari Oksanen -- Dept Biology, Univ Oulu, 90014 Oulu, Finland Ph. +358 8 5531526, cell +358 40 5136529, fax +358 8 5531061 email [EMAIL PROTECTED], homepage http://cc.oulu.fi/~jarioksa/ __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] MacOS X: update.packages(type=mac.binary) fails (PR#7836)
Message 2 of today: it works now. After re-installing R.app from the same R-2.1.0.dmg file, and fixInNamespace'ing(*) install.packages(), I managed to update 23 outdated packages from CRAN binaries for MacOS X. What I did was to: 1. change call to .install.macbinaries() into call to install.binaries() in install.packages(). install.binaries() is a function defined utils/R/aqua/GUI.R. 2. I also had to remove argument 'dependencies' since that is not defined in install.binaries() of utils/aqua. It seems that install.binaries of utils/aqua is mentioned in several places in R sources, but .install.macbinary() appears only in one place, so changing install.packages() is less hassle than changing utils/R/aqua/GUI.R and all other places (although this looks more natural). This still requires a fix in passing type in update.packages() that B. Ripley already did for R 2.1.1, or setting options(pkgType=mac.binary). cheers, jari oksanen (*) Object-oriented programming is an exceptionally bad idea which could only have originated in California. E. Dijkstra On Tue, 2005-05-03 at 16:14 +0100, Prof Brian Ripley wrote: Binary installs are AFAIK only supported in the GUI, where the default is as documented. So .install.macbinary() is not loaded except in the GUI. The reason is that those binaries are tied to that particular build of R, and will not work with a general build on MacOS X. I would expect this to work from the command-line in the GUI console, and had believed it had been tested there. On Tue, 3 May 2005 [EMAIL PROTECTED] wrote: Full_Name: Jari Oksanen Version: R 2.1.0 OS: MacOS 10.3.9 Submission from: (NULL) (130.231.102.145) For various reasons (which need not be expanded here) I have tried to update my long neglected R in MacOS X using handy command line tool update.packages() using readily available binaries of contributed packages at CRAN. However, this fails with message saying that packages _*_tar.gz is not found at the server (HTTP error 404). Obviously, the package name is expanded wrongly as the binary packages for MacOS X have type *.tgz. However, this seems not be the problem, but there are two other problems: 1. update.packages does not transfer the value of 'type' to the next function install.packages, but install.packages uses the value of getOption(pkgType) which seems to be source in CRAN binary of MacOS X (contrary to documentation at ?options). 2. If this is corrected, or first set options(pkgType=mac.binary), the update fails for missing function .install.macbinary(). The first problem is easy to correct: --- update.packages.R 2005-05-03 17:13:36.0 +0300 +++ jarioksa.update.packages.R 2005-05-03 17:13:58.0 +0300 @@ -59,5 +59,5 @@ install.packages(update[, Package], instlib, contriburl = contriburl, method = method, available = available, destdir = destdir, -installWithVers = installWithVers, type) +installWithVers = installWithVers, type = type) } } For the second, problem, I don't know what to do. grepping R-patched_2005-05-03.tar.gz source found only one instance of .install.macbinary(): the failed call in R-patched/src/library/utils/R/packages2.R. I couldn't find the definition of the function. Do I really have to use GUI? Uh. cheers, jari oksanen __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] MacOS X: update.packages(type=mac.binary) fails (PR#7836)
On Wed, 4 May 2005 [EMAIL PROTECTED] wrote: Message 2 of today: it works now. After re-installing R.app from the same R-2.1.0.dmg file, and fixInNamespace'ing(*) install.packages(), I managed to update 23 outdated packages from CRAN binaries for MacOS X. What I did was to: 1. change call to .install.macbinaries() into call to install.binaries() in install.packages(). install.binaries() is a function defined utils/R/aqua/GUI.R. 2. I also had to remove argument 'dependencies' since that is not defined in install.binaries() of utils/aqua. The point is that the omitted .install.macbinaries() does support dependencies and has several other improvements over install.binaries(). It seems that install.binaries of utils/aqua is mentioned in several places in R sources, but .install.macbinary() appears only in one place, so changing install.packages() is less hassle than changing utils/R/aqua/GUI.R and all other places (although this looks more natural). This still requires a fix in passing type in update.packages() that B. Ripley already did for R 2.1.1, or setting options(pkgType=mac.binary). This should not be required. What does .Platform say? cheers, jari oksanen (*) Object-oriented programming is an exceptionally bad idea which could only have originated in California. E. Dijkstra On Tue, 2005-05-03 at 16:14 +0100, Prof Brian Ripley wrote: Binary installs are AFAIK only supported in the GUI, where the default is as documented. So .install.macbinary() is not loaded except in the GUI. The reason is that those binaries are tied to that particular build of R, and will not work with a general build on MacOS X. I would expect this to work from the command-line in the GUI console, and had believed it had been tested there. On Tue, 3 May 2005 [EMAIL PROTECTED] wrote: Full_Name: Jari Oksanen Version: R 2.1.0 OS: MacOS 10.3.9 Submission from: (NULL) (130.231.102.145) For various reasons (which need not be expanded here) I have tried to update my long neglected R in MacOS X using handy command line tool update.packages() using readily available binaries of contributed packages at CRAN. However, this fails with message saying that packages _*_tar.gz is not found at the server (HTTP error 404). Obviously, the package name is expanded wrongly as the binary packages for MacOS X have type *.tgz. However, this seems not be the problem, but there are two other problems: 1. update.packages does not transfer the value of 'type' to the next function install.packages, but install.packages uses the value of getOption(pkgType) which seems to be source in CRAN binary of MacOS X (contrary to documentation at ?options). 2. If this is corrected, or first set options(pkgType=mac.binary), the update fails for missing function .install.macbinary(). The first problem is easy to correct: --- update.packages.R 2005-05-03 17:13:36.0 +0300 +++ jarioksa.update.packages.R 2005-05-03 17:13:58.0 +0300 @@ -59,5 +59,5 @@ install.packages(update[, Package], instlib, contriburl = contriburl, method = method, available = available, destdir = destdir, -installWithVers = installWithVers, type) +installWithVers = installWithVers, type = type) } } For the second, problem, I don't know what to do. grepping R-patched_2005-05-03.tar.gz source found only one instance of .install.macbinary(): the failed call in R-patched/src/library/utils/R/packages2.R. I couldn't find the definition of the function. Do I really have to use GUI? Uh. cheers, jari oksanen __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R2HTML bug? shell bug? (PR#7832)
[EMAIL PROTECTED] wrote: Full_Name: Juan José Goyeneche Version: 2.0.1 OS: debian Submission from: (NULL) (164.73.246.102) When I call the R2HTML library I get (most of the time) the following message. library(R2HTML) sh: line 1: -oq: command not found In any case, the R2HTML functions seem to be working fine after that. Should I ignore the sh message? Thanks in advance Juan José Q: What has a question releated to a contributed packages in common with the R bug tracking system? A: NOTHING! This is a point for the package maintainer, not for any R mailing list, and in particular not for the bug tracking system. Please read the FAQs, they are telling you what a bug is and how to report bugs! Please try on a recent version of R (yours is not even the latest official relase), and with a recent version of R2HTML - you have not told us which version you are using. Uwe Ligges __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Cost of method dispatching: was: when can we expect Prof Tierney's compiled R?
Vadim Ogranovich wrote: -Original Message- From: Prof Brian Ripley [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 27, 2005 1:13 AM To: Vadim Ogranovich Cc: Luke Tierney; r-devel@stat.math.ethz.ch Subject: Re: [Rd] RE: [R] when can we expect Prof Tierney's compiled R? On Tue, 26 Apr 2005, Vadim Ogranovich wrote: ... The arithmetic shows that x[i]- is still the bottleneck. I suspect that this is due to a very involved dispatching/search for the appropriate function on the C level. There might be significant gain if loops somehow cached the result of the initial dispatching. This is what you probably referred to as additional improvements in the engine itself. I'd be surprised if dispatching were the issue: have you (C-level) profiled to find out? Please do so: these statements do tend to get perpetuated as fact. For the record, I didn't profile the dispatching, so it is only my guess and is not verified by C-level profiling. The guess is based on reading the code and on the following timing on R level: n = 1e6; iA = seq(2,n); x = double(n); f1 - function(x, iA) for (i in iA) x[i] = c(1.0) f2 - function(x, iA) for (i in iA) x = c(1.0) last.gc.time = gc.time(TRUE) system.time(f1(x, iA), gcFirst=TRUE) [1] 3.50 0.01 3.52 0.00 0.00 print(gc.time() - last.gc.time); last.gc.time = gc.time() [1] 1.25 0.82 1.24 0.00 0.00 system.time(f2(x, iA), gcFirst=TRUE) [1] 0.76 0.00 0.77 0.00 0.00 print(gc.time() - last.gc.time); last.gc.time = gc.time() [1] 0.25 0.18 0.23 0.00 0.00 f1 and f2 are identical except that the first assigns to an element in the vector (and thus goes through the method dispatching). Originally I had thought that the number of allocations in f1 and in f2 must be the same, the c(1.0) call. But gc.time() shows that the number of allocations in f1 is indeed, as Prof. Ripley suggests, bigger than in f2. It is not clear to me where these extra allocations come from and whether they are necessary. All x[i] = c(1.0) needs to do is to create a new vector c(1.0), which is a step common between f1 and f2, and then copy from the vector into x[i]. However even after discounting for gc.time the assignment to x[i] seems to be heavy. You cannot cache the result, as [- can change the class of x, as could other operations done by the rhs (e.g. if it were x[i] - g(x, i) the function g could change its argument). Yes, however R may try to use the last method found and only when that fails go for the full dispatch. This should give a lot of gain in a typical case when the vars. types do not change. There are probably efficiency improvements available, but they need to be done very carefully. For example, the default method of [- could be called in one step, and as a side effect create a more specific method. So for the second call we should call the more specific one, but the default call will still be valid in the sense that the arguments match the signature (S4) or the class matches the name (S3), but not in the sense that it is the method that should be called. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] MacOS X: update.packages(type=mac.binary) fails (PR#7836)
On Wed, 2005-05-04 at 09:01 +0100, Prof Brian Ripley wrote: This still requires a fix in passing type in update.packages() that B. Ripley already did for R 2.1.1, or setting options(pkgType=mac.binary). This should not be required. What does .Platform say? I don't know: R fails to start again in my Mac (The application R has unexpectedly quit.) Re-installation and removing all .RData and .Rhistory do not help this time either (that was the time between receiving this message and answering now). However, it was the R-2.1.0.dmg I got from CRAN, I started it in Mac way (clicking the icon), it was the Mac graphical window. Further, I had checked ?options which said that default package type in this case should be mac.binary. Still it wasn't, but it was source. I didn't check the .Platform that time, only pkgType. It seems that I'll quit using R in MacOS X for a while, since she quits me in the startup anyway (fortunately I have Linux as my main environment). cheers, jari oksanen -- Jari Oksanen -- Dept Biology, Univ Oulu, 90014 Oulu, Finland Ph. +358 8 5531526, cell +358 40 5136529, fax +358 8 5531061 email [EMAIL PROTECTED], homepage http://cc.oulu.fi/~jarioksa/ __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] MacOS X: update.packages(type=mac.binary) fails (PR#7836)
On Wed, 2005-05-04 at 09:01 +0100, Prof Brian Ripley wrote: This should not be required. What does .Platform say? I couldn't let it be: str(.Platform) List of 6 $ OS.type : chr unix $ file.sep : chr / $ dynlib.ext: chr .so $ GUI : chr AQUA $ endian: chr big $ pkgType : chr source R.version.string [1] R version 2.1.0, 2005-04-18 (After removing R.app and R.framework, re-installing from R-2.1.0.dmg, logging out and in -- the last step helped.) As this is CRAN Mac OS X build this seems to be in conflict with documentation of 'options' pkgType. PS. download.packages(AMORE, type=source, destdir=/tmp) works in MacOS X (or this one I have here) with any 'type'. cheers, jari oksanen -- Jari Oksanen -- Dept Biology, Univ Oulu, 90014 Oulu, Finland Ph. +358 8 5531526, cell +358 40 5136529, fax +358 8 5531061 email [EMAIL PROTECTED], homepage http://cc.oulu.fi/~jarioksa/ __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] MacOS X: update.packages(type=mac.binary) fails (PR#7836)
On Wed, 4 May 2005, Jari Oksanen wrote: On Wed, 2005-05-04 at 09:01 +0100, Prof Brian Ripley wrote: This should not be required. What does .Platform say? I couldn't let it be: str(.Platform) List of 6 $ OS.type : chr unix $ file.sep : chr / $ dynlib.ext: chr .so $ GUI : chr AQUA $ endian: chr big $ pkgType : chr source Thanks, that is the bit which is incorrect. I now see the problem and have fixed it. R.version.string [1] R version 2.1.0, 2005-04-18 (After removing R.app and R.framework, re-installing from R-2.1.0.dmg, logging out and in -- the last step helped.) As this is CRAN Mac OS X build this seems to be in conflict with documentation of 'options' pkgType. PS. download.packages(AMORE, type=source, destdir=/tmp) works in MacOS X (or this one I have here) with any 'type'. Good! cheers, jari oksanen -- Jari Oksanen -- Dept Biology, Univ Oulu, 90014 Oulu, Finland Ph. +358 8 5531526, cell +358 40 5136529, fax +358 8 5531061 email [EMAIL PROTECTED], homepage http://cc.oulu.fi/~jarioksa/ -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Workspace [Was: MacOS X: update.packages(type=mac.binary)]
On May 4, 2005, at 2:30 AM, [EMAIL PROTECTED] wrote: but the sanguine(*) R in MacOS X refuses to start in GUI mode today with uninformative error message (The application R has unexpectedly quit.). It's an OS X message, nothing R.app can do about it. See the Console for details - those would be more useful (I would expect a Linux person to look there first and ignore the message ;)). So it seems not be the only problem in the MacOS X build of R at CRAN. It's likely a problem with your setup, see below. Starting from bash prompt in Terminal.app fails as well with error .onLoad failed in 'loadNamespace' for 'tcltk'. Delete your workspace (rm -f ~/.RData) - that should fix it - as the message tells you there is a problem while the workspace is restored. Cheers, Simon BTW: Using R-SIG-Mac instead of R-devel for the update.package could be more helpful as this is Mac-only issue. __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] make hanging during compile of r-patched/R-devel on Fedora Core 3
Hi, On a new Dell laptop, with a fresh FC3 installation (with latest updates applied) I am experiencing make hanging consistently after/during building grDevices. This happens when using the configure flag --with-lapack (I have the LAPACK rpm distributed with FC3 installed). The last two lines of output are: make[5]: Leaving directory `/home/gavin/R/devel/build/src/library/grDevices/src' make[4]: Leaving directory `/home/gavin/R/devel/build/src/library/grDevices/src' hang here There are no errors or warnings printed to the console. The same thing happens with r-patched. Both source trees were checked out using subversion. If I remove the configure flag for lapack, r-patches and r devel both build fine. I'm not sure where to look for error messages or to diagnose the problem. Has anyone experienced a similar problem? Where should I look for any errors/logs? Any other suggestions? All the best, Gavin -- %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~% Gavin Simpson [T] +44 (0)20 7679 5522 ENSIS Research Fellow [F] +44 (0)20 7679 7565 ENSIS Ltd. ECRC [E] gavin.simpsonATNOSPAMucl.ac.uk UCL Department of Geography [W] http://www.ucl.ac.uk/~ucfagls/cv/ 26 Bedford Way[W] http://www.ucl.ac.uk/~ucfagls/ London. WC1H 0AP. %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~% __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Problem with pbirthday (PR#7837)
Full_Name: Andy Lynch Version: 1.9.1 OS: Windows Submission from: (NULL) (131.111.86.211) As I understand it, pbirthday(n,c,k) gives the approximate probability that we see a class with k coicident people in it when n people are sorted into c classes. so the command pbirthday(4,classes=3,coincident=4) should give the approximate probability that when four people fall into three classes, all four end up in the same class. A probability that is clearly lower than the presently returned value of 1. It seems to me that the line in the function if (n classes) return(1) is only relevant to the default case of coincident = 2. (Naturally, if there are more people than classes, then at least one class must contain 2 people). __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Cost of method dispatching: was: when can we expect Prof Tierney's compiled R?
On Wed, 4 May 2005, Duncan Murdoch wrote:
Vadim Ogranovich wrote:
-Original Message-
From: Prof Brian Ripley [mailto:[EMAIL PROTECTED] Sent: Wednesday,
April 27, 2005 1:13 AM
To: Vadim Ogranovich
Cc: Luke Tierney; r-devel@stat.math.ethz.ch
Subject: Re: [Rd] RE: [R] when can we expect Prof Tierney's compiled R?
On Tue, 26 Apr 2005, Vadim Ogranovich wrote:
...
The arithmetic shows that x[i]- is still the bottleneck. I suspect that
this is due to a very involved dispatching/search for the appropriate
function on the C level. There might be
significant gain
if loops somehow cached the result of the initial
dispatching. This is
what you probably referred to as additional improvements in
the engine itself.
I'd be surprised if dispatching were the issue: have you (C-level)
profiled to find out? Please do so: these statements do tend to get
perpetuated as fact.
For the record, I didn't profile the dispatching, so it is only my guess
and is not verified by C-level profiling.
The guess is based on reading the code and on the following timing on R
level:
n = 1e6; iA = seq(2,n); x = double(n);
f1 - function(x, iA) for (i in iA) x[i] = c(1.0)
f2 - function(x, iA) for (i in iA) x = c(1.0)
last.gc.time = gc.time(TRUE)
system.time(f1(x, iA), gcFirst=TRUE)
[1] 3.50 0.01 3.52 0.00 0.00
print(gc.time() - last.gc.time); last.gc.time = gc.time()
[1] 1.25 0.82 1.24 0.00 0.00
system.time(f2(x, iA), gcFirst=TRUE)
[1] 0.76 0.00 0.77 0.00 0.00
print(gc.time() - last.gc.time); last.gc.time = gc.time()
[1] 0.25 0.18 0.23 0.00 0.00
f1 and f2 are identical except that the first assigns to an element in
the vector (and thus goes through the method dispatching).
Originally I had thought that the number of allocations in f1 and in f2
must be the same, the c(1.0) call. But gc.time() shows that the number
of allocations in f1 is indeed, as Prof. Ripley suggests, bigger than in
f2. It is not clear to me where these extra allocations come from and
whether they are necessary. All x[i] = c(1.0) needs to do is to create a
new vector c(1.0), which is a step common between f1 and f2, and then
copy from the vector into x[i].
However even after discounting for gc.time the assignment to x[i] seems
to be heavy.
You cannot cache the result, as [- can change the class of x, as could
other operations done by the rhs (e.g. if it were x[i] - g(x, i) the
function g could change its argument).
Yes, however R may try to use the last method found and only when that
fails go for the full dispatch. This should give a lot of gain in a
typical case when the vars. types do not change.
There are probably efficiency improvements available, but they need to be
done very carefully. For example, the default method of [- could be called
in one step, and as a side effect create a more specific method. So for the
second call we should call the more specific one, but the default call will
still be valid in the sense that the arguments match the signature (S4) or
the class matches the name (S3), but not in the sense that it is the method
that should be called.
Duncan Murdoch
Let's slow down here. In
function(x, iA) for (i in iA) x[i] = c(1.0)
there are three functions in the body, [-, [, and c. All are
.Primitives with internal C implementations for which methods can be
written. These implementations all look roughly like this:
if (method is available)
call the method
else { C default code }
The test of whether methods are available first looks at a bit. If
that bit is not set there are guaranteed not to be any methods. Only
if that bit is set does any further search for methods happen. In
this example, and in most uses of these functions, that bit is not
set, so dispatch involves testing one bit. This most important case
has already been optimized. Further optimizing cases where methods
migth be available might be worth doing and will happen over time as
we learn what is necessary and feasible and where bottlenecks are.
But this sort of thing has to be done with care. Here, however, this
just is not an issue.
The default code for [- might well merit another look--I suspect it
has not been as heavily optiized as the default code for [. How much
difference this will make to realistic code and whether the cost of
implementation/maintenance is worth while is not clear.
On additional allocations: that is the function call mechanism of the
interpreter. This could be done differently, but given the semantics
of argument matching and ... arguments there is a limit on what an
interpreter can realistically do. Again, whether the cost of making
changes to the function call mechanism in terms of both implementation
cost and maintenance cost is justified is not clear. Some of us are
likely to look at the function call overhead sometime this summer; I
would't want to bet on the outcome though.
luke
--
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of
Re: [Rd] Problem with pbirthday (PR#7837)
On Wed, 4 May 2005 [EMAIL PROTECTED] wrote: It seems to me that the line in the function if (n classes) return(1) is only relevant to the default case of coincident = 2. (Naturally, if there are more people than classes, then at least one class must contain 2 people). Yep, looks like a bug to me. Thanks. I do note that the approximation used in pbirthday is not very good for small n, so fixing this bug still doesn't give the right answer for your example. For small n the best solution is simulation or direct calculation. The point of the pbirthday approximation is that the untrained intuition guesses the probability to be about n(1/classes)^(coincident-1) and the approximation is usually quite good when this is much smaller than the true probability. -thomas __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Re: [R] Unbundling gregmisc (was: loading gap package)
On Wed, 4 May 2005, Duncan Murdoch wrote: Warnes, Gregory R wrote: Let me redirect the topic a bit. I've been considering unbundling gregmisc. So let's move to R-devel. The pro would be that people would find the component packages (i.e. gdata) more easily. The con is that the packages have a number of interdependencies, so you pretty much will need to get most of them anyway. As the latest gregmisc bundle contains a gregmisc package that is just a stub that depends on and loads the individual packages, there would still be a gregmisc object. Comments? Currently R can follow dependencies when you install a package from CRAN (and this is the default in Windows, not sure about other platforms), so I'd say this would be a good thing to do. I don't know your revision history on the components, but I'd guess some change more often than others, so there'll be no need to update all of them every time one of them changes. It has been possible on Unix and Windows for a while, but it seems is not yet implemented on MacOS X (although I submitted the code needed). However, it is only the default on the Windows GUI and not for any command-line version of install.packages(). People have from time to time suggested changing the default, but the dependency tree can get rather large and some people do have slow and expensive connections. I think a bundle is still a better idea. Apart from on MacOS X we need some education about how to use the power of *.packages (and we need to get the MacOS versions in place). For example, bundle components show up with the dialog-based installation lists. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] make hanging during compile of r-patched/R-devel on Fedora Core 3
On Wed, 2005-05-04 at 13:56 +0100, Gavin Simpson wrote: Hi, On a new Dell laptop, with a fresh FC3 installation (with latest updates applied) I am experiencing make hanging consistently after/during building grDevices. This happens when using the configure flag --with-lapack (I have the LAPACK rpm distributed with FC3 installed). The last two lines of output are: make[5]: Leaving directory `/home/gavin/R/devel/build/src/library/grDevices/src' make[4]: Leaving directory `/home/gavin/R/devel/build/src/library/grDevices/src' hang here There are no errors or warnings printed to the console. The same thing happens with r-patched. Both source trees were checked out using subversion. If I remove the configure flag for lapack, r-patches and r devel both build fine. I'm not sure where to look for error messages or to diagnose the problem. Has anyone experienced a similar problem? Where should I look for any errors/logs? Any other suggestions? Gavin, FWIW, I can duplicate this behavior on my Dell 5150 w/ FC3 using the r- patched tarball from 2005-05-03. I thought that perhaps this might be related to the use of the nVidia proprietary driver, but temporarily going back to the 'nv' driver did not resolve the problem. Thus, I am unable to provide more information as to the etiology of the problem other than to point to some of the references in the r-admin manual starting on page 19 regarding linear algebra. Perhaps there is a problem with the FC3 LAPACK. Best regards, Marc Schwartz __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Re: [R-SIG-Mac] Workspace [Was: MacOS X: update.packages(type=mac.binary)]
Hi Jari, In addition to Simon's suggestion below, recently someone fixed this by ensuring R.app has write permission to its working directory. Rob On May 4, 2005, at 5:23 AM, Simon Urbanek wrote: Starting from bash prompt in Terminal.app fails as well with error .onLoad failed in 'loadNamespace' for 'tcltk'. Delete your workspace (rm -f ~/.RData) - that should fix it - as the message tells you there is a problem while the workspace is restored. Cheers, Simon __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] make hanging during compile of r-patched/R-devel on Fedora Core 3
Marc Schwartz wrote: On Wed, 2005-05-04 at 13:56 +0100, Gavin Simpson wrote: Hi, On a new Dell laptop, with a fresh FC3 installation (with latest updates applied) I am experiencing make hanging consistently after/during building grDevices. This happens when using the configure flag --with-lapack (I have the LAPACK rpm distributed with FC3 installed). The last two lines of output are: make[5]: Leaving directory `/home/gavin/R/devel/build/src/library/grDevices/src' make[4]: Leaving directory `/home/gavin/R/devel/build/src/library/grDevices/src' hang here There are no errors or warnings printed to the console. The same thing happens with r-patched. Both source trees were checked out using subversion. If I remove the configure flag for lapack, r-patches and r devel both build fine. I'm not sure where to look for error messages or to diagnose the problem. Has anyone experienced a similar problem? Where should I look for any errors/logs? Any other suggestions? Gavin, FWIW, I can duplicate this behavior on my Dell 5150 w/ FC3 using the r- patched tarball from 2005-05-03. I thought that perhaps this might be related to the use of the nVidia proprietary driver, but temporarily going back to the 'nv' driver did not resolve the problem. Thus, I am unable to provide more information as to the etiology of the problem other than to point to some of the references in the r-admin manual starting on page 19 regarding linear algebra. Perhaps there is a problem with the FC3 LAPACK. Best regards, Marc Schwartz Cheers for this Mark, I had a quick google search for this problem and found a discussion in the redhat mailing list archives that discusses the issue and points to the following bug: https://bugzilla.redhat.com/beta/show_bug.cgi?id=138447 Which describes the behaviour I am experiencing. Basically, the LAPACK in FC3 is broken because it was compiled with gcc-3.4 and that introduced errors when -O2 optimisations were used to compile the rpm. That bug was recently reopened so there may be the possibility of the FC3 rpm being updated (the underlying problem has been fixed by compiling with lower optimisation). I'll read more of the r-admin, and see about finding an alternative. Also, note that lapack has been moved to Fedora Extras from FC4 so that's one more thing to remember to add after upgrading! All the best, Gav -- %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~% Gavin Simpson [T] +44 (0)20 7679 5522 ENSIS Research Fellow [F] +44 (0)20 7679 7565 ENSIS Ltd. ECRC [E] gavin.simpsonATNOSPAMucl.ac.uk UCL Department of Geography [W] http://www.ucl.ac.uk/~ucfagls/cv/ 26 Bedford Way[W] http://www.ucl.ac.uk/~ucfagls/ London. WC1H 0AP. %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~% __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] make hanging during compile of r-patched/R-devel on Fedora Core 3
On Wed, 4 May 2005, Marc Schwartz wrote:
On Wed, 2005-05-04 at 13:56 +0100, Gavin Simpson wrote:
Hi,
On a new Dell laptop, with a fresh FC3 installation (with latest updates
applied) I am experiencing make hanging consistently after/during
building grDevices. This happens when using the configure flag
--with-lapack (I have the LAPACK rpm distributed with FC3 installed).
The last two lines of output are:
make[5]: Leaving directory
`/home/gavin/R/devel/build/src/library/grDevices/src'
make[4]: Leaving directory
`/home/gavin/R/devel/build/src/library/grDevices/src'
hang here
There are no errors or warnings printed to the console.
The same thing happens with r-patched. Both source trees were checked
out using subversion.
If I remove the configure flag for lapack, r-patches and r devel both
build fine. I'm not sure where to look for error messages or to diagnose
the problem. Has anyone experienced a similar problem? Where should I
look for any errors/logs? Any other suggestions?
Gavin,
FWIW, I can duplicate this behavior on my Dell 5150 w/ FC3 using the r-
patched tarball from 2005-05-03.
I thought that perhaps this might be related to the use of the nVidia
proprietary driver, but temporarily going back to the 'nv' driver did
not resolve the problem.
Thus, I am unable to provide more information as to the etiology of the
problem other than to point to some of the references in the r-admin
manual starting on page 19 regarding linear algebra.
Perhaps there is a problem with the FC3 LAPACK.
In any case, we do not recommend an external LAPACK unless it is
essential. There are far too many buggy ones about, and there is no
performance gain in using someone else's compile of a nearly identical
code base. Is
Provision is made for using an external LAPACK library, principally to
cope with BLAS libraries which contain a copy of LAPACK (such as
@code{libsunperf} on Solaris and @code{vecLib} on Mac OS X).
However, the likely performance gains are thought to be small (and may
be negative), and the default is not to search for a suitable LAPACK
library.
If you do use @option{--with-lapack}, be aware of potential problems
with bugs in the LAPACK 3.0 sources (or in the posted corrections to
those sources).
not enough warning?
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] make hanging during compile of r-patched/R-devel on Fedora Core 3
On Wed, 2005-05-04 at 16:58 +0100, Gavin Simpson wrote: snip Cheers for this Mark, I had a quick google search for this problem and found a discussion in the redhat mailing list archives that discusses the issue and points to the following bug: https://bugzilla.redhat.com/beta/show_bug.cgi?id=138447 Which describes the behaviour I am experiencing. Basically, the LAPACK in FC3 is broken because it was compiled with gcc-3.4 and that introduced errors when -O2 optimisations were used to compile the rpm. That bug was recently reopened so there may be the possibility of the FC3 rpm being updated (the underlying problem has been fixed by compiling with lower optimisation). I'll read more of the r-admin, and see about finding an alternative. Also, note that lapack has been moved to Fedora Extras from FC4 so that's one more thing to remember to add after upgrading! All the best, Gav Thanks for the update Gavin. For FC4, there are a lot of things that are either going to be new in or are moving to Extras (including R BTW). Much controversy over some of the decisions made there, but that's another topic for another thread in a different galaxy, far, far away... ;-) Best regards, Marc __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Re: [R] Unbundling gregmisc (was: loading gap package)
BDR == Prof Brian Ripley [EMAIL PROTECTED] on Wed, 4 May 2005 16:29:33 +0100 (BST) writes: ... BDR .. we need some education about how to use the BDR power of *.packages (and we need to get the MacOS BDR versions in place). and maybe we should even consider adding regression tests for the *.packages() functions so chances increase they will work on all platforms Martin __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] make hanging during compile of r-patched/R-devel on Fedora Core 3
Gavin Simpson [EMAIL PROTECTED] writes: Basically, the LAPACK in FC3 is broken because it was compiled with gcc-3.4 and that introduced errors when -O2 optimisations were used to compile the rpm. That bug was recently reopened so there may be the possibility of the FC3 rpm being updated (the underlying problem has been fixed by compiling with lower optimisation). There's a pending update on lapack/blas now, which may or may not fix the issue (no announcement in the archives). Any clue whether there is any benefit in using the FC3 versions over the versions that ships with R? -- O__ Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] make hanging during compile of r-patched/R-devel on Fedora Core 3
On Wed, 2005-05-04 at 21:15 +0200, Peter Dalgaard wrote: Gavin Simpson [EMAIL PROTECTED] writes: Basically, the LAPACK in FC3 is broken because it was compiled with gcc-3.4 and that introduced errors when -O2 optimisations were used to compile the rpm. That bug was recently reopened so there may be the possibility of the FC3 rpm being updated (the underlying problem has been fixed by compiling with lower optimisation). There's a pending update on lapack/blas now, which may or may not fix the issue (no announcement in the archives). Any clue whether there is any benefit in using the FC3 versions over the versions that ships with R? Peter, I cannot offer an authoritative response here and perhaps Gavin has other information. Recognizing the absence of evidence is not evidence of absence, I have not seen anything (benchmarks, etc.) to suggest that there is an advantage. Regards, Marc __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] DLL modules with other dependent libraries
Hi all, In R for Windows, is there a preferred way to handle R extensions that provide native code that depend upon one or more third party DLLs? If I put those DLLs in the library/MODULE/libs it doesn't find them. In other words, my MODULE.dll has other DLLs it uses, but they aren't standard and it would be unlikely to find them in the system path. Thanks for any suggestions! __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Varying as.Date performance
R-devel, The performance of as.Date differs by a large degree between one of my machines with glibc 2.3.2: system.time(x - as.Date(rep(01-01-2005, 10), format = %m-%d-%Y)) [1] 1.17 0.00 1.18 0.00 0.00 and a comparable machine with glibc 2.3.3: system.time(x - as.Date(rep(01-01-2005, 10), format = %m-%d-%Y)) [1] 31.20 46.89 81.01 0.00 0.00 both with the same R version: R.version _ platform i686-pc-linux-gnu arch i686 os linux-gnu system i686, linux-gnu status major2 minor1.0 year 2005 month04 day 18 language R I'm focusing on differences in glibc versions because of as.Date's use of strptime. Does it seem likely that the cause of this discrepancy is in fact glibc? If so, can anyone tell me how to make the performance of the second machine more like the first? I have verified that using the chron package, which I don't believe uses strptime, for the above character conversion performs equally well on both machines. Thanks in advance, Jeff __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Varying as.Date performance
On 5/5/05, Gabor Grothendieck [EMAIL PROTECTED] wrote:
On 5/4/05, Jeff Enos [EMAIL PROTECTED] wrote:
R-devel,
The performance of as.Date differs by a large degree between one of my
machines with glibc 2.3.2:
system.time(x - as.Date(rep(01-01-2005, 10), format = %m-%d-%Y))
[1] 1.17 0.00 1.18 0.00 0.00
and a comparable machine with glibc 2.3.3:
system.time(x - as.Date(rep(01-01-2005, 10), format = %m-%d-%Y))
[1] 31.20 46.89 81.01 0.00 0.00
both with the same R version:
R.version
_
platform i686-pc-linux-gnu
arch i686
os linux-gnu
system i686, linux-gnu
status
major2
minor1.0
year 2005
month04
day 18
language R
I'm focusing on differences in glibc versions because of as.Date's use
of strptime.
Does it seem likely that the cause of this discrepancy is in fact
glibc? If so, can anyone tell me how to make the performance of the
second machine more like the first?
I have verified that using the chron package, which I don't believe
uses strptime, for the above character conversion performs equally
well on both machines.
I think its likely the character processing that is the bottleneck. You
can speed that part up by extracting the substrings directly:
system.time({
+ dd - rep(01-01-2005, 1)
+ year - as.numeric(substr(dd, 7, 10))
+ mon - as.numeric(substr(dd, 1, 2))
+ day - as.numeric(substr(dd, 4, 5))
+ x - as.Date(ISOdate(year, mon, day))
+ }, gc = TRUE)
[1] 0.42 0.00 0.51 NA NA
system.time(x - as.Date(rep(01-01-2005, 10), format = %m-%d-%Y),
gc=TRUE)
[1] 1.08 0.00 1.22 NA NA
Sorry but I got the number of zeros in the reps wrong. Its actually slower.
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] make hanging during compile of r-patched/R-devel on Fedora Core 3
On Wed, 4 May 2005, Peter Dalgaard wrote: Gavin Simpson [EMAIL PROTECTED] writes: Basically, the LAPACK in FC3 is broken because it was compiled with gcc-3.4 and that introduced errors when -O2 optimisations were used to compile the rpm. That bug was recently reopened so there may be the possibility of the FC3 rpm being updated (the underlying problem has been fixed by compiling with lower optimisation). There's a pending update on lapack/blas now, which may or may not fix the issue (no announcement in the archives). Any clue whether there is any benefit in using the FC3 versions over the versions that ships with R? Yes: at least for earlier versions, none. (See the comments in the R-admin manual I quoted yesterday which no one else seems to have read.) -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] DLL modules with other dependent libraries
On Wed, 4 May 2005, Marcus G. Daniels wrote: In R for Windows, is there a preferred way to handle R extensions that provide native code that depend upon one or more third party DLLs? If I put those DLLs in the library/MODULE/libs it doesn't find them. In other words, my MODULE.dll has other DLLs it uses, but they aren't standard and it would be unlikely to find them in the system path. Thanks for any suggestions! Set the path for the loading of the DLL. One example is tcltk in the R sources, and it is done for several of the binary packages I distribute. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
