[Rd] initFields() method no longer coerces arguments in R-devel
Dear all, I've just had a package update bounced from CRAN because of a recent change in R-devel which seems to affect the behaviour of the initFields() reference class method. (The change must be very recent because I tested the package on a week-old build of R-devel.) It seems that the method no longer coerces its arguments to the expected type of each field. For a simple example: Foo - setRefClass(Foo, fields=list(number=integer), methods=list(initialize=function (number = NULL) initFields(number=number))) Foo$new() Error in function (value) : invalid replacement for field ‘number’, should be from class “integer” or a subclass (was class “NULL”) (This used to work, with number being set to integer(0)). In fact it is now extremely strict, not even allowing a double literal which is equal to an integer: Foo$new(number=1) Error in function (value) : invalid replacement for field ‘number’, should be from class “integer” or a subclass (was class “numeric”) I don't see anything about this in the NEWS, so I was wondering if I could get clarification on whether this is now the intended behaviour, before I further modify the package. I must say that this will be a bit of a pain to correct... All the best, Jon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] RPMs needed to compile R using the tar.gz file
First off, this was an R-devel question (or maybe an r-sig-fedora
one).
It is not at all easy to give a complete answer: the list is very long
and changes rapidly as Fedora updates. If you can use yum to install
a minimal list and let it get the dependencies the list would be
manageable. And the simplest way to get a minimal list would be to
look in the spec file for the Fedora SRPM.
But here's a start, from yum -v install R
pkgconfig
gcc-gfortran
gcc-c++ (optional for R)
libX11-devel
libXt-devel
libXmu-devel
pango-devel
tcl-devel
tk-devel
readline-devel
libpng-devel
libjpeg-turbo-devel
libtiff-devel
libicu-devel
(Fedora uses lots of things like pcre, bzip2 which have copies
in R.)
A lot of that is actually documented in the R-admin manual.
On Fri, 5 Aug 2011, Patrick Connolly wrote:
I don't wish to install R by rpm. I need to know what Fedora rpms I
need to install to give me the capability to install R using the
tar.gz source file as I've done for years.
On previous occasions when I've installed Fedora, I've used the DVD
which has thousands of RPMs. Lately I've installed Fedora 15 from the
Live CD which has a lot fewer and so a lot of necessary stuff is not
installed yet.
I've done the same not long ago with Kubuntu which required me to
install about 20 debs before I could compile R. If I had access to
that installation, I could probably work out what the corresponding
rpms are. But I figured some clever person will have a list of the
necessary rpms somewhere already. Or even a smarter search string
than I can think of would be appreciated.
There's a lot of information about installing R from an rpm but that's
not what I wish to do.
TIA
--
~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.
___Patrick Connolly
{~._.~} Great minds discuss ideas
_( Y )_ Average minds discuss events
(:_~*~_:) Small minds discuss people
(_)-(_) . Eleanor Roosevelt
~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.
__
r-h...@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
--
Brian D. Ripley, rip...@stats.ox.ac.uk
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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] RPMs needed to compile R using the tar.gz file
On Fri, 2011-08-05 at 12:13 +0100, Prof Brian Ripley wrote: And the simplest way to get a minimal list would be to look in the spec file for the Fedora SRPM. See: http://pkgs.fedoraproject.org/gitweb/?p=R.git;a=blob_plain;f=R.spec;hb=HEAD Pierre __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] slightly speeding up readChar()
On 5 Aug 2011, at 1:20AM, Dirk Eddelbuettel wrote: When you know the (fixed) structure of the data, the CRAN package mmap can be a huge winner. Thanks! I didn't know that. Is there a package that provides methods for mmap, like sum(x) or maybe even y=x+z where x, and z are mmaps? I assume that once you mmap to a huge file, you do operations on it by working on chunks at a time... are there packages for that, or do I have to write my own code? Thanks! Michael __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] initFields() method no longer coerces arguments in R-devel
It's worth actually reading the list you post to ... http://r.789695.n4.nabble.com/Reference-classes-assignments-to-fields-td3708168.html On Aug 5, 2011, at 6:41 AM, Jon Clayden wrote: Dear all, I've just had a package update bounced from CRAN because of a recent change in R-devel which seems to affect the behaviour of the initFields() reference class method. (The change must be very recent because I tested the package on a week-old build of R-devel.) It seems that the method no longer coerces its arguments to the expected type of each field. For a simple example: Foo - setRefClass(Foo, fields=list(number=integer), methods=list(initialize=function (number = NULL) initFields(number=number))) Foo$new() Error in function (value) : invalid replacement for field ‘number’, should be from class “integer” or a subclass (was class “NULL”) (This used to work, with number being set to integer(0)). In fact it is now extremely strict, not even allowing a double literal which is equal to an integer: Foo$new(number=1) Error in function (value) : invalid replacement for field ‘number’, should be from class “integer” or a subclass (was class “numeric”) I don't see anything about this in the NEWS, so I was wondering if I could get clarification on whether this is now the intended behaviour, before I further modify the package. I must say that this will be a bit of a pain to correct... All the best, Jon __ 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
Re: [Rd] slightly speeding up readChar()
Michael, The mmap package currently provides an Ops method for comparisons, which returns something like which(i==) does in R - since a vector of logicals the same size would be likely too big to handle in many cases. At some point I'll implement mmap to mmap operations, though for vectorized ops that result in non-logical output (i.e. numeric), I haven't yet decided on how that should be implemented. Something like a results buffer on disk/memory has been my thinking, but anyone with additional (better!) suggestions please feel free to send me ideas off list. I'll look to add some basic summary statistics as well. Note that you need to have a binary representation on disk (via fwrite in C, or writeBin or as.mmap in R) for this to work. But the package currently supports something like 16 data types, including bit logicals, fixed width character strings (\0 delim vectors), floats (4 byte), and 64 bit ints. The vignette covers a lot of the details. Additionally if you have struct-style data (think row-oriented, with varying types), you can use the struct() feature. This maps to an R list, but allows for very fast access if you are pulling complete rows. example(mmap) example(types) example(struct) The R-forge version has more than the CRAN version at this moment, but I'll be pushing a new one to CRAN soon. Jeff On Fri, Aug 5, 2011 at 8:22 AM, Michael Lachmann lachm...@eva.mpg.dewrote: On 5 Aug 2011, at 1:20AM, Dirk Eddelbuettel wrote: When you know the (fixed) structure of the data, the CRAN package mmap can be a huge winner. Thanks! I didn't know that. Is there a package that provides methods for mmap, like sum(x) or maybe even y=x+z where x, and z are mmaps? I assume that once you mmap to a huge file, you do operations on it by working on chunks at a time... are there packages for that, or do I have to write my own code? Thanks! Michael __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com www.esotericR.com [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] initFields() method no longer coerces arguments in R-devel
There is also an item in the NEWS file: Field assignments in reference classes are now consistent with slots in S4 classes: the assigned value must come from the declared class (if any) for the field or from a subclass. On 8/5/11 7:24 AM, Simon Urbanek wrote: It's worth actually reading the list you post to ... http://r.789695.n4.nabble.com/Reference-classes-assignments-to-fields-td3708168.html On Aug 5, 2011, at 6:41 AM, Jon Clayden wrote: Dear all, I've just had a package update bounced from CRAN because of a recent change in R-devel which seems to affect the behaviour of the initFields() reference class method. (The change must be very recent because I tested the package on a week-old build of R-devel.) It seems that the method no longer coerces its arguments to the expected type of each field. For a simple example: Foo- setRefClass(Foo, fields=list(number=integer), methods=list(initialize=function (number = NULL) initFields(number=number))) Foo$new() Error in function (value) : invalid replacement for field ‘number’, should be from class “integer” or a subclass (was class “NULL”) (This used to work, with number being set to integer(0)). In fact it is now extremely strict, not even allowing a double literal which is equal to an integer: Foo$new(number=1) Error in function (value) : invalid replacement for field ‘number’, should be from class “integer” or a subclass (was class “numeric”) I don't see anything about this in the NEWS, so I was wondering if I could get clarification on whether this is now the intended behaviour, before I further modify the package. I must say that this will be a bit of a pain to correct... All the best, Jon __ 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Tesla GPUs
On Jul 19, 2011, at 12:56 PM, Simon Urbanek wrote: On Jul 19, 2011, at 2:26 AM, Prof Brian Ripley wrote: On Mon, 18 Jul 2011, Alireza Mahani wrote: Simon, Thank you for elaborating on the limitations of R in handling float types. I think I'm pretty much there with you. As for the insufficiency of single-precision math (and hence limitations of GPU), my personal take so far has been that double-precision becomes crucial when some sort of error accumulation occurs. For example, in differential equations where boundary values are integrated to arrive at interior values, etc. On the other hand, in my personal line of work (Hierarchical Bayesian models for quantitative marketing), we have so much inherent uncertainty and noise at so many levels in the problem (and no significant error accumulation sources) that single vs double precision issue is often inconsequential for us. So I think it really depends on the field as well as the nature of the problem. The main reason to use only double precision in R was that on modern CPUs double precision calculations are as fast as single-precision ones, and with 64-bit CPUs they are a single access. So the extra precision comes more-or-less for free. You also under-estimate the extent to which stability of commonly used algorithms relies on double precision. (There are stable single-precision versions, but they are no longer commonly used. And as Simon said, in some cases stability is ensured by using extra precision where available.) I disagree slightly with Simon on GPUs: I am told by local experts that the double-precision on the latest GPUs (those from the last year or so) is perfectly usable. See the performance claims on http://en.wikipedia.org/wiki/Nvidia_Tesla of about 50% of the SP performance in DP. That would be good news. Unfortunately those seem to be still targeted at a specialized market and are not really graphics cards in traditional sense. Although this is sort of required for the purpose it removes the benefit of ubiquity. So, yes, I agree with you that it may be an interesting way forward, but I fear it's too much of a niche to be widely supported. I may want to ask our GPU specialists here to see if they have any around so I could re-visit our OpenCL R benchmarks. Last time we abandoned our OpenCL R plans exactly due to the lack of speed in double precision. A quick update - it turns out we have a few Tesla/Fermi machines here, so I ran some very quick benchmarks on them. The test case was the same as for the original OpenCL comparisons posted here a while ago when Apple introduced it: dnorm on long vectors: 64M, single: -- GPU -- total: 4894.1 ms, compute: 234.5 ms, compile: 4565.7 ms, real: 328.3 ms -- CPU -- total: 2290.8 ms 64M, double: -- GPU -- total: 5448.4 ms, compute: 634.1 ms, compile: 4636.4 ms, real: 812.0 ms -- CPU -- total: 2415.8 ms 128M, single: -- GPU -- total: 5843.7 ms, compute: 469.2 ms, compile: 5040.5 ms, real: 803.1 ms -- CPU -- total: 4568.9 ms 128M, double: -- GPU -- total: 6042.8 ms, compute: 1093.9 ms, compile: 4583.3 ms, real: 1459.5 ms -- CPU -- total: 4946.8 ms The CPU times are based on a dual Xeon X5690 machine (12 cores @ 3.47GHz) using OpenMP, but are very approximate, because there were two other jobs running on machine -- still, it should be a good ballpark figure. The GPU times are run on Tesla S2050 using OpenCL, addressed as one device so presumably comparable to the performance of one Tesla M2050. The figures to compare are GPU.real (which is computation + host memory I/O) and CPU.total, because we can assume that we can compile the kernel in advance, but you can't save on the memory transfer (unless you find a good way to chain calls which is not realistic in R). So the good news is that the new GPUs fulfill their promise : double precision is only twice as slow as single precision. Also they scale approximately linearly - see the real time of 64M double is almost the same as 128M single. They also outperform the CPUs as well, although not by an order of magnitude. The double precision support is very good news, and even though we are still using GPUs in a suboptimal manner, they are faster than the CPUs. The only practical drawback is that using OpenCL requires serious work, it's not as easy as slapping omp pragmas on existing code. Also the HPC Teslas are quite expensive so I don't expect to see them in desktops anytime soon. However, for people that are thinking about big computation, it may be an interesting way to go. Given that it's not mainstream I don't expect core R to have OCL support just yet, but it may be worth keeping in mind for the future as we are designing the parallelization framework in R. Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] initFields() method no longer coerces arguments in R-devel
OK, apologies - on both fronts I obviously searched on the wrong terms. Sorry to waste your time. Jon On 5 August 2011 18:22, John Chambers j...@r-project.org wrote: There is also an item in the NEWS file: Field assignments in reference classes are now consistent with slots in S4 classes: the assigned value must come from the declared class (if any) for the field or from a subclass. On 8/5/11 7:24 AM, Simon Urbanek wrote: It's worth actually reading the list you post to ... http://r.789695.n4.nabble.com/Reference-classes-assignments-to-fields-td3708168.html On Aug 5, 2011, at 6:41 AM, Jon Clayden wrote: Dear all, I've just had a package update bounced from CRAN because of a recent change in R-devel which seems to affect the behaviour of the initFields() reference class method. (The change must be very recent because I tested the package on a week-old build of R-devel.) It seems that the method no longer coerces its arguments to the expected type of each field. For a simple example: Foo- setRefClass(Foo, fields=list(number=integer), methods=list(initialize=function (number = NULL) initFields(number=number))) Foo$new() Error in function (value) : invalid replacement for field ‘number’, should be from class “integer” or a subclass (was class “NULL”) (This used to work, with number being set to integer(0)). In fact it is now extremely strict, not even allowing a double literal which is equal to an integer: Foo$new(number=1) Error in function (value) : invalid replacement for field ‘number’, should be from class “integer” or a subclass (was class “numeric”) I don't see anything about this in the NEWS, so I was wondering if I could get clarification on whether this is now the intended behaviour, before I further modify the package. I must say that this will be a bit of a pain to correct... All the best, Jon __ 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 __ 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
[Rd] Usage of options() for user defined options
Hi I want to use options() to store session wide options - is that a reasonable approach, or should options() be reserved for core options? Thanks Rainer -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax (F): +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
