Re: [Rd] str() with attr(*, "names") is extremely slow for long vectors
> "HenrikB" == Henrik Bengtsson (max 7Mb) <[EMAIL PROTECTED]> > on Fri, 5 May 2006 11:58:19 -0700 writes: HenrikB> Hi, HenrikB> I noticed some time ago that, for instance, named vectors HenrikB> that are really makes str() really slow when displaying the HenrikB> names attribute. HenrikB> I don't know exactly when this started, but it wasn't the HenrikB> case say 1-2 years ago. Example (on a WinXP 1.8GHz): It got slower with R 2.3.0. Comparing str() for a big exprSet object from the "Biobase" package I got the following numbers (system.time(str(anaexp)) on WinXP 1.8 GHz): R 2.2.0 1. 14.64 0.13 14.90NANA 2. 4.33 0.09 4.43NANA 3. 4.20 0.15 4.38NANA R 2.3.0 1. 65.36 0.18 66.12NANA 2. 51.75 0.21 52.55NANA 3. 51.79 0.17 52.45NANA One can notice a considerable speed-up in the 2nd & 3rd call to str() in R 2.2.0, which is much less pronounced in R 2.3.0. Hth Gerhard DI Gerhard Thallinger E-mail: [EMAIL PROTECTED] Institute for Genomics and Bioinformatics Web: http://genome.tugraz.at Graz University of Technology Tel:+43 316 873 5343 Petersgasse 14/VFax:+43 316 873 5340 8010 Graz, Austria Map: http://genome.tugraz.at/Loc.html __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S4 initialize methods, unexpected recursive callNextMethod
The bug should now be fixed. The actual change is very small, but it
enforces a semantic definition that may be relevant, so we should
discuss it.
The question is: what method does callNextMethod() refer to? The
definition now enforced is: the "next method" is the method found for
the defining signature (the signature in the call to setMethod()) if
that method itself was absent. See the Details section of the
documentation for callNextMethod in the latest development version.
In previous versions, it was possible to use callNextMethod() to get at
different inherited methods, depending on the instance, that is on the
class of the particular object(s) in the call, while going through the
_same_ method containing the callNextMethod().
I think the current semantics is cleaner and more appropriate to a
functional style of programming. It is also needed if the dispatch of
the next method were to be "compiled in" to the method in a future
version (which should, in fact, be easy to do).
But watch for uses of callNextMethod() that now behave differently.
Seth Falcon wrote:
>Hi,
>
>Given a simple three class hierarchy: A <-- B <-- C
>
>I want to define an initialize method for each class such that when I
>call new("C", x=5), the initialize methods for A and B are used to
>incrementally build the object.
>
>When I do what seems obvious to me using callNextMethod, I get an
>infinite recursion. An example follows...
>
>setClass("A", representation(a="numeric"))
>setClass("B", representation(b="numeric"), contains="A")
>setClass("C", representation(c="numeric"), contains="B")
>
>setMethod("initialize", signature(.Object="A"),
> function(.Object, x) {
> cat("in A\n")
> [EMAIL PROTECTED] <- x
> .Object
> })
>
>setMethod("initialize", signature(.Object="B"),
> function(.Object, x) {
> cat("in B\n")
> .Object <- callNextMethod(.Object=.Object, x=x)
> [EMAIL PROTECTED] <- [EMAIL PROTECTED] + 1
> .Object
> })
>
>setMethod("initialize", signature(.Object="C"),
> function(.Object, x) {
> cat("in C\n")
> .Object <- callNextMethod(.Object=.Object, x=x)
> [EMAIL PROTECTED] <- [EMAIL PROTECTED] + [EMAIL PROTECTED] + 1
> .Object
> })
>
>
>## Works as I am expecting for B
>
>
>>myB <- new("B", 4)
>>
>>
>in B
>in A
>
>## When you create a C, the B method gets called but the appropriate
>## next method info seems lost and we end up back in C's method ?!
>
>
>>myC <- new("C", 5)
>>
>>
>in C
>in B
>in C
>in B
>in C
> C-c C-c
>
>Should this work? Is there a better way to organize the initializers
>for a simple hierarchy (perhaps assume that args to the initializers
>are not the same for A, B, and C).
>
>Thanks,
>
>+ seth
>
>__
>R-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] str() with attr(*, "names") is extremely slow for long vectors
> "Gerhard" == Gerhard Thallinger <[EMAIL PROTECTED]> > on Sat, 13 May 2006 12:54:10 +0200 writes: > "HenrikB" == Henrik Bengtsson (max 7Mb) <[EMAIL PROTECTED]> > on Fri, 5 May 2006 11:58:19 -0700 writes: But have you looked at R 2.3.0-patched at all? I did acknowledge that str() had become unacceptably slow, and had implemented a simple patch almost "immediately". Martin HenrikB> Hi, I noticed some time ago that, for instance, HenrikB> named vectors that are really makes str() really HenrikB> slow when displaying the names attribute. HenrikB> I don't know exactly when this started, but it HenrikB> wasn't the case say 1-2 years ago. Example (on a HenrikB> WinXP 1.8GHz): Gerhard> It got slower with R 2.3.0. Comparing str() for a Gerhard> big exprSet object from the "Biobase" package I got Gerhard> the following numbers (system.time(str(anaexp)) on Gerhard> WinXP 1.8 GHz): Gerhard> R 2.2.0 Gerhard> 1. 14.64 0.13 14.90 NA NA 2. 4.33 0.09 4.43 NA Gerhard> NA 3. 4.20 0.15 4.38 NA NA Gerhard> R 2.3.0 Gerhard> 1. 65.36 0.18 66.12 NA NA 2. 51.75 0.21 52.55 Gerhard> NA NA 3. 51.79 0.17 52.45 NA NA Gerhard> One can notice a considerable speed-up in the 2nd & Gerhard> 3rd call to str() in R 2.2.0, which is much less Gerhard> pronounced in R 2.3.0. Gerhard> Hth Gerhard> Gerhard Gerhard> Gerhard> DI Gerhard Thallinger E-mail: Gerhard> [EMAIL PROTECTED] Institute for Genomics Gerhard> and Bioinformatics Web: http://genome.tugraz.at Gerhard> Graz University of Technology Tel: +43 316 873 5343 Gerhard> Petersgasse 14/V Fax: +43 316 873 5340 8010 Graz, Gerhard> Austria Map: http://genome.tugraz.at/Loc.html __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] windows( ... ,rescale="fixed") bug (PR#8857)
Full_Name: Gerhard Thallinger Version: 2.3.0; 2.2.0 OS: Windows XP Submission from: (NULL) (212.183.54.87) Invoking windows() with the parameter rescale="fixed" followed by plot.new() or any other plot command causes very often the following error: windows(width=7, height=7, rescale="fixed");plot.new() Error in plot.new() : outer margins too large (fig.region too small) The values in the width and height parameters seem not to have an influence. Investigating the problem more deeply shows that certain values in the device structure are set to 0 or have some invalid value (bty, cex, ljoin, ... ) after the call to windows() when plot.new() fails. This indicates that the device structure is either not initialized properly or gets clobbered somehow. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] windows( ... ,rescale="fixed") bug (PR#8857)
On 5/13/2006 12:54 PM, [EMAIL PROTECTED] wrote: > Full_Name: Gerhard Thallinger > Version: 2.3.0; 2.2.0 > OS: Windows XP > Submission from: (NULL) (212.183.54.87) > > > Invoking windows() with the parameter rescale="fixed" followed by plot.new() > or any other plot command causes very often the following error: > > windows(width=7, height=7, rescale="fixed");plot.new() > Error in plot.new() : outer margins too large (fig.region too small) > > The values in the width and height parameters seem not to have an influence. > Investigating the problem more deeply shows that certain values > in the device structure are set to 0 or have some invalid value > (bty, cex, ljoin, ... ) after the call to windows() when plot.new() fails. > > This indicates that the device structure is either not initialized properly > or gets clobbered somehow. > I can confirm the bug in R-devel. A workaround is to open the window without specifying "fixed", then in the menu, select fixed. That suggests to me something wasn't being initialized. I'll take a look... Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] windows( ... ,rescale="fixed") bug (PR#8857)
On 5/13/2006 1:51 PM, Duncan Murdoch wrote: > On 5/13/2006 12:54 PM, [EMAIL PROTECTED] wrote: >> Full_Name: Gerhard Thallinger >> Version: 2.3.0; 2.2.0 >> OS: Windows XP >> Submission from: (NULL) (212.183.54.87) >> >> >> Invoking windows() with the parameter rescale="fixed" followed by plot.new() >> or any other plot command causes very often the following error: >> >> windows(width=7, height=7, rescale="fixed");plot.new() >> Error in plot.new() : outer margins too large (fig.region too small) >> >> The values in the width and height parameters seem not to have an influence. >> Investigating the problem more deeply shows that certain values >> in the device structure are set to 0 or have some invalid value >> (bty, cex, ljoin, ... ) after the call to windows() when plot.new() fails. >> >> This indicates that the device structure is either not initialized properly >> or gets clobbered somehow. >> > > I can confirm the bug in R-devel. A workaround is to open the window > without specifying "fixed", then in the menu, select fixed. That > suggests to me something wasn't being initialized. I'll take a look... I've taken a look, and tracked it down this far: While setting up, the graphics device installs a callback called HelpExpose that's called when drawing the window. For some reason I haven't figured out, rescale="fixed" causes this to be called before the window is ready, and junk in the structure leads to the error. I won't be able to do any more on this for a couple of days. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] windows( ... ,rescale="fixed") bug (PR#8857)
On 5/13/2006 1:51 PM, Duncan Murdoch wrote: > On 5/13/2006 12:54 PM, [EMAIL PROTECTED] wrote: >> Full_Name: Gerhard Thallinger >> Version: 2.3.0; 2.2.0 >> OS: Windows XP >> Submission from: (NULL) (212.183.54.87) >> >> >> Invoking windows() with the parameter rescale="fixed" followed by plot.new() >> or any other plot command causes very often the following error: >> >> windows(width=7, height=7, rescale="fixed");plot.new() >> Error in plot.new() : outer margins too large (fig.region too small) >> >> The values in the width and height parameters seem not to have an influence. >> Investigating the problem more deeply shows that certain values >> in the device structure are set to 0 or have some invalid value >> (bty, cex, ljoin, ... ) after the call to windows() when plot.new() fails. >> >> This indicates that the device structure is either not initialized properly >> or gets clobbered somehow. >> > > I can confirm the bug in R-devel. A workaround is to open the window > without specifying "fixed", then in the menu, select fixed. That > suggests to me something wasn't being initialized. I'll take a look... I've taken a look, and tracked it down this far: While setting up, the graphics device installs a callback called HelpExpose that's called when drawing the window. For some reason I haven't figured out, rescale="fixed" causes this to be called before the window is ready, and junk in the structure leads to the error. I won't be able to do any more on this for a couple of days. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Mere chat on vectorisation matters
Hi to all. Not so long ago, I wrote: >Allow me to chat a tiny bit on two vectorisation-related matters, in >the context of R. I'm curious about if the following ideas have ever >been considered, and rejected already. [... then, a few words about >Duff's device, and operation chaining ...] As this letter did not generate any reply, I presumed the ideas have not be rejected, on the premise that if they have been, someone would have been kind enough to tell me :-). So, today, I went forward and added Duff's device within arithmetic.c. There might have been operational or experimental error, of course, as I'm far from mastering R installation matters. But if there were no such error, I'm now reporting, for the record, that Duff's device does _not_ yield an interesting speedup. -- François Pinard http://pinard.progiciels-bpi.ca __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Error Compiling RMySQL in Fedora Core 5 86x64
in download and automatic install the RMySQL, R show the error (look
under session attach. MySQL is install and operational.
Juan Santiago Ramseyer.
> install.packages('RMySQL')
--- Please select a CRAN mirror for use in this session ---
Loading Tcl/Tk interface ... done
tentando a URL
'http://cran.br.r-project.org/src/contrib/RMySQL_0.5-7.tar.gz'
Content type 'application/x-tar' length 142507 bytes
URL aberta
==
downloaded 139Kb
* Installing *source* package 'RMySQL' ...
creating cache ./config.cache
checking how to run the C preprocessor... cc -E
checking for compress in -lz... yes
checking for getopt_long in -lc... yes
checking for mysql_init in -lmysqlclient... no
checking for mysql.h... no
checking for mysql_init in -lmysqlclient... no
checking for mysql_init in -lmysqlclient... no
checking for mysql_init in -lmysqlclient... no
checking for mysql_init in -lmysqlclient... no
checking for mysql_init in -lmysqlclient... no
checking for /usr/local/include/mysql/mysql.h... no
checking for /usr/include/mysql/mysql.h... yes
Configuration error:
could not find the MySQL installation include and/or library
directories. Manually specify the location of the MySQL
libraries and the header files and re-run R CMD INSTALL.
INSTRUCTIONS:
1. Define and export the 2 shell variables PKG_CPPFLAGS and
PKG_LIBS to include the directory for header files (*.h)
and libraries, for example (using Bourne shell syntax):
export PKG_CPPFLAGS="-I"
export PKG_LIBS="-L -lmysqlclient"
Re-run the R INSTALL command:
R CMD INSTALL RMySQL_.tar.gz
2. Alternatively, you may pass the configure arguments
--with-mysql-dir= (distribution directory)
or
--with-mysql-inc= (where MySQL header files reside)
--with-mysql-lib= (where MySQL libraries reside)
in the call to R INSTALL --configure-args='...'
R CMD INSTALL --configure-args='--with-mysql-dir=DIR'
RMySQL_.tar.gz
ERROR: configuration failed for package 'RMySQL'
** Removing '/usr/lib64/R/library/RMySQL'
The downloaded packages are in
/tmp/RtmpLXIne5/downloaded_packages
Warning message:
installation of package 'RMySQL' had non-zero exit status in:
install.packages("RMySQL")
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] reusing routines
Hi Terry.
If I am inferring correctly from your description, in S-Plus
your C code for the microarray automatically finds the cholesky2 routine
in the survival package without any need to tell it to do so.
While it may be convenient, this is not very desirable at all.
Rather, you should have to tell the microarray C code about
cholesky2 when compiling and linking that code.
You didn't mention which operating system you and your colleague
are each using. But perhaps the local argument of dyn.load()
may work for you; use
dyn.load(system.file("libs",
paste("survival", .Platform$dynlib.ext, sep =""),
package = "survival"),
local = FALSE)
Then dyn.load() the other dynamically loadable library which uses
cholesky2.
In the next few months, we'll be able to link native code from one
package into another and this is a much more sensible approach than
using the global symbol table and risking conflicts and ambiguities.
D.
Terry Therneau wrote:
>I've created some Splus code for a microarray problem that
> - needed to be in C, to take advantage of some sparse matrix
> properties
> - uses a cholesky decompostion as part of the computation
>
> For the cholesky, I used the cholesky2 routine, which is a part of the
> survival library. It does just what I want and I'm familiar with it (after
> all, I wrote it).
>
> In Splus, this all works fine. A colleague working on the same problem
> prefers R; things don't work there. The dyn.load command complains that
> the routine is not found, even when the survival library is already loaded.
>
> I looked at the manual page for dyn.load, but don't see anything. What
> are we missing?
>
> Please reply via email, as I don't read this list. (But I likely will start
> to later this summer, when I port the newest mixed-effects Cox model code
> over from S).
>
> Terry Therneau
> Mayo Clinic
> [EMAIL PROTECTED]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
