Re: [Rd] [R] R with MKL
On Tue, 2009-03-17 at 12:12 +0900, Ei-ji Nakama wrote:
> Hi
>
> > I have seen a lot of problems from people trying to compile R with
> > MKL. So I am writing my experience in case it helps and to ask one
> > question. I installed R-2.8.1.patched in Ubuntu 9.04 (gcc 4.3.3) using
> > MKL 10.1.1.019.
>
> Do you use gcc and gfortran?
>
> > I configured correctly (following MKL userguide) with :
> >
> > sudo ./configure --with-blas="-I/opt/intel/mkl/10.1.1.019/include
> > -L/opt/intel/mkl/10.1.1.019/lib/em64t -lmkl_intel_lp64
> > -lmkl_intel_thread -lmkl_core -liomp5 -lpthread"
> > --with-lapack="-I/opt/intel/mkl/10.1.1.019/include
> > -L/opt/intel/mkl/10.1.1.019/lib/em64t -lmkl_intel_lp64
> > -lmkl_intel_thread -lmkl_core -liomp5 -lpthread"
>
> cited reference https://svn.r-project.org/R/trunk/doc/manual/R-admin.texi
> | You are strongly encouraged to read the MKL User's Guide
> |
> | @example
> | MKL=" -...@{mkl_lib_path@} \
> | -Wl,--start-group \
> | $...@{mkl_lib_path@}/libmkl_gf_lp64.a\
> | $...@{mkl_lib_path@}/libmkl_gnu_thread.a \
> | $...@{mkl_lib_path@}/libmkl_core.a \
> | -Wl,--end-group \
> | -liomp5 -lpthread"
> | @end example
>
> However, It is a little different.( -lgomp and configure line)
>
> MKL=" -...@{mkl_lib_path@} \
> -Wl,--start-group \
> $...@{mkl_lib_path@}/libmkl_gf_lp64.a\
> $...@{mkl_lib_path@}/libmkl_gnu_thread.a \
> $...@{mkl_lib_path@}/libmkl_core.a \
> -Wl,--end-group \
> -lgomp -lpthread"
> ./configure --with-blas="$MKL" --with-lapack="$MKL"
Yes I see. If you are statically linking to MKL, you want to link to the
GNU OMP runtime for portability. Sorry about that.
> > But in order to compile had to edit src/modules/lapack/vecLibg95c.c
> > and comment out the include. Weird, since I am not building for Mac.
>
> Please note the thing that ABI of fortran is different with Intel compiler
> and GNU compiler.
> difficult to detect the mistake.
---
This message and its attachments are strictly confidenti...{{dropped:8}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Match .3 in a sequence
Petr Savicky wrote: > On Mon, Mar 16, 2009 at 07:39:23PM -0400, Stavros Macrakis wrote: > ... > >> Let's look at the extraordinarily poor behavior I was mentioning. Consider: >> >> nums <- (.3 + 2e-16 * c(-2,-1,1,2)); nums >> [1] 0.3 0.3 0.3 0.3 >> >> Though they all print as .3 with the default precision (which is >> normal and expected), they are all different from .3: >> >> nums - .3 => -3.885781e-16 -2.220446e-16 2.220446e-16 3.885781e-16 >> >> When we convert nums to a factor, we get: >> >> fact <- as.factor(nums); fact >> [1] 0.300 0.3 0.3 0.300 >> Levels: 0.300 0.3 0.3 0.300 >> >> Not clear what the difference between 0.300 and 0.3 is >> supposed to be, nor why some 0.300 are < .3 and others are >> > ... > > When creating a factor from numeric vector, the list of levels and the > assignment of original elements to the levels is done using > double precision. Since the four elements in the vector are distinct, > we get four distinct levels. After this is done, the levels attribute is > formed using as.character(). This can map different numbers to the same > string, so in the example above, this leads to a factor, which contains > repeated levels. > > This part of the problem may be avoided using > > fact <- as.factor(as.character(nums)); fact > [1] 0.300 0.3 0.3 0.300 > Levels: 0.3 0.300 > > The reason for having 0.300 and 0.3 is that as.character() > works the same as printing with digits=15. The R printing mechanism > works in two steps. In the first step it tries to determine the shortest > format needed to achieve the required relative precision of the output. > This step uses an algorithm, which need not provide an accurate result. > The next step is that the number is printed using C function sprintf > with the chosen format. This step is accurate, so we cannot get wrong > digits. We only can get wrong number of digits. > > In order to avoid using 15 digits in as.character(), we can use > round(,digits), > with digits argument appropriate for the current situation. > > > fact <- as.factor(round(nums,digits=1)); fact > [1] 0.3 0.3 0.3 0.3 > Levels: 0.3 > > with the examples above, it looks like a design flaw that factor levels and their *labels* are messed up into one clump. if, in the above, levels were the numbers, and their labels were produced with as.character, as you show, but kept separately (or generated on the fly, when displaying the factor), the problem would have been solved. you would then have something like: nums <- (.3 + 2e-16 * c(-2,-1,1,2)); nums # [1] 0.3 0.3 0.3 0.3 sum(nums[rep(1:4, each=4)] == nums[rep(1:4, 4)]) # 4 fact <- as.factor(nums); fact # [1] 0.300 0.3 0.3 0.300 # Levels: 0.300 0.3 0.3 0.300 sum(fact[rep(1:4, each=4)] == fact[rep(1:4, 4)]) # 4 (currently, it's 8) there's one more curiosity about factors, in particular, ordered factors: ord <- as.ordered(nums); ord # [1] 0.300 0.3 0.3 0.300 # Levels: 0.300 < 0.3 < 0.3 < 0.300 ord[1] < ord[4] # TRUE ord[1] == ord[4] # TRUE vQ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Match .3 in a sequence
On Tue, Mar 17, 2009 at 10:15:39AM +0100, Wacek Kusnierczyk wrote: ... > there's one more curiosity about factors, in particular, ordered factors: > > ord <- as.ordered(nums); ord > # [1] 0.300 0.3 0.3 > 0.300 > # Levels: 0.300 < 0.3 < 0.3 < 0.300 > > ord[1] < ord[4] > # TRUE > ord[1] == ord[4] > # TRUE ... The following workaround should help in most cases. nums <- (.3 + 2e-16 * c(-2,-1,1,2)) nums # [1] 0.3 0.3 0.3 0.3 nums <- signif(nums, digits=15) as.ordered(nums) # Levels: 0.3 as.factor(nums) # Levels: 0.3 Petr. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] link in base help file fails.
On 16/03/2009 11:44 PM, Keith Satterley wrote: I run R on MS Windows. In R2.9.0dev, I type ?base to get "R help for package base" to open. I then select ".First" from the list of contents, getting a page headed: "Initialization at Start of an R Session". About half way down there is a sentence: Thanks for the report. I can reproduce this problem with CHM help, but not HTML help. I'll investigate, but it might be a limitation of the format. (It's not new in R2.9.0, it is present in 2.8.1 as well.) Duncan Murdoch The command-line flag --vanilla implies --no-site-file, --no-init-file, --no-restore and --no-environ. Under Windows, it also implies --no-Rconsole, which prevents loading the ‘Rconsole’ file. The last occurrence of the word Rconsole is in blue text and underlined, a link. On clicking on this link, I get a page headed "This program cannot display the webpage" with advice on "Most likely causes:" and "What you can try". Other links work satisfactorily on that page. My internet connection is working. I presume there is a problem with this Rconsole link. > sessionInfo() R version 2.9.0 Under development (unstable) (2009-03-13 r48127) i386-pc-mingw32 locale: LC_COLLATE=English_Australia.1252;LC_CTYPE=English_Australia.1252;LC_MONETARY=English_Australia.1252;LC_NUMERIC=C;LC_TIME=English_Australia.1252 attached base packages: [1] stats graphics grDevices datasets utils methods base > cheers, Keith Keith Satterley Bioinformatics Division The Walter and Eliza Hall Institute of Medical Research Parkville, Melbourne, Victoria, Australia __ 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] exporting s3 and s4 methods
If a package defined an S3 generic and an S4 generic for the same function (so
as to add methods for S4 classes to the existing code), how do I set up the
namespace to have them exported?
With
import(stats)
exportMethods(bigglm)
importClassesFrom(DBI)
useDynLib(biglm)
export(biglm)
export(bigglm)
in NAMESPACE, the S3 generic is not exported.
methods("bigglm")
[1] bigglm.RODBC* bigglm.data.frame* bigglm.function*
Non-visible functions are asterisked
Warning messages:
1: In findGeneric(generic.function, parent.frame()) :
'bigglm' is a formal generic function; S3 methods will not likely be found
2: In methods("bigglm") : function 'bigglm' appears not to be generic
[This is R 2.7.2, admittedly a little ancient]
-thomas
Thomas Lumley Assoc. Professor, Biostatistics
tlum...@u.washington.eduUniversity of Washington, Seattle
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Match .3 in a sequence
Wacek Kusnierczyk wrote: > > > there's one more curiosity about factors, in particular, ordered factors: > > ord <- as.ordered(nums); ord > # [1] 0.300 0.3 0.3 > 0.300 > # Levels: 0.300 < 0.3 < 0.3 < 0.300 > > ord[1] < ord[4] > # TRUE > ord[1] == ord[4] > # TRUE > as a corollary, the warning printed when comparing elements of a factor is misleading: f = factor(1:2) f[1] < f[2] # [1] NA # Warning message: # In Ops.factor(f[1], f[2]) : < not meaningful for factors g = as.ordered(f) is.factor(g) # TRUE g[1] < g[2] # TRUE < *is* meaningful for factors, though not for unordered ones. the warning is generated in Ops.factor, src/library/base/all.R:7162, and with my limited knowledge of the r internals i can't judge how easy it is to fix the problem. vQ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] link in base help file fails.
On 16/03/2009 11:44 PM, Keith Satterley wrote: I run R on MS Windows. In R2.9.0dev, I type ?base to get "R help for package base" to open. I then select ".First" from the list of contents, getting a page headed: "Initialization at Start of an R Session". About half way down there is a sentence: The command-line flag --vanilla implies --no-site-file, --no-init-file, --no-restore and --no-environ. Under Windows, it also implies --no-Rconsole, which prevents loading the ‘Rconsole’ file. The last occurrence of the word Rconsole is in blue text and underlined, a link. On clicking on this link, I get a page headed "This program cannot display the webpage" with advice on "Most likely causes:" and "What you can try". Other links work satisfactorily on that page. My internet connection is working. I presume there is a problem with this Rconsole link. After a little looking, this turns out to be a limitation of the CHM help file production. With other formats that support links you don't need to specify which package a link goes to, but with CHM help, you do. Since Rconsole is documented in the utils package, this link from base failed in that format. I've fixed other external links to that particular topic, but I imagine there are lots of other cross-package links that will still fail in CHM files. Since we will likely replace the file conversion system soon, and since CHM files are no longer supported by Microsoft, I am not planning to try to fix the old conversion code. If the fix was easy, it would have been in place from the beginning. But if someone else wants to put together a patch (to share/perl/R/Rdconv.pm), I'll test it. So for now I'd recommend using HTML help rather than CHM help. Duncan Murdoch > sessionInfo() R version 2.9.0 Under development (unstable) (2009-03-13 r48127) i386-pc-mingw32 locale: LC_COLLATE=English_Australia.1252;LC_CTYPE=English_Australia.1252;LC_MONETARY=English_Australia.1252;LC_NUMERIC=C;LC_TIME=English_Australia.1252 attached base packages: [1] stats graphics grDevices datasets utils methods base > cheers, Keith Keith Satterley Bioinformatics Division The Walter and Eliza Hall Institute of Medical Research Parkville, Melbourne, Victoria, Australia __ 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] R freeze when loading dll with dyn.load
Good morning,
I am investigating dll import in R under Windows XP. Using examples I found on
the internet, I started with a very simple dll, e.g. including only the basic
function:
void
{
*x2 = x*x;
}sqr(doublex, double*x2)
I compiled it as a dll with Eclipse and Cygwin's gcc. It works when I call it
with another simple .exe C program, compile with Eclipse and gcc as well. I can
do what I want with x2 after I have called the function.
However, R freezes when I try to load it with the following command:
dyn.load('c:/.../sqr/Release/sqr.dll')
I know the path I provide is correct, it's the same without the .dll extension
and providing an invalid path makes the function returning an error message
(LoadLibrary failure...) but not freeze. Has anyone an idea of what is
happening?
Thanks for your help,
Best regards,
Didier.
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R freeze when loading dll with dyn.load
On Mar 17, 2009, at 8:24 , Morel Didier wrote:
Good morning,
I am investigating dll import in R under Windows XP. Using examples
I found on the internet, I started with a very simple dll, e.g.
including only the basic function:
void
{
*x2 = x*x;
}sqr(doublex, double*x2)
This is not a valid C code. What you may have possibly meant is
void sqr(double *x, double *x2) {
*x2 = *x * *x;
}
> dyn.load("tt.dll")
> .C("sqr",4,0)
[[1]]
[1] 4
[[2]]
[1] 16
Cheers,
S
I compiled it as a dll with Eclipse and Cygwin's gcc.
You should be using MinGW - I don't think anything else is directly
supported (see R Windows FAQ).
Cheers,
S
It works when I call it with another simple .exe C program, compile
with Eclipse and gcc as well. I can do what I want with x2 after I
have called the function.
However, R freezes when I try to load it with the following command:
dyn.load('c:/.../sqr/Release/sqr.dll')
I know the path I provide is correct, it's the same without the .dll
extension and providing an invalid path makes the function returning
an error message (LoadLibrary failure...) but not freeze. Has anyone
an idea of what is happening?
Thanks for your help,
Best regards,
Didier.
[[alternative HTML version deleted]]
__
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] Match .3 in a sequence
Petr, Thank you for the detailed diagnosis of the bizarre behavior I reported, which seems to indicate several distinct problems in the underlying code: 1) Factor allows repeated levels, e.g. factor(c(1),c(1,1,1)), with no warning or error. 2) Even from distinct inputs, factor of a numeric vector may generate repeated levels, because it only uses 15 digits. 3) The algorithm to determine the shortest format is inconsistent with the algorithm to actually print, giving pathological cases like 0.3 vs. 0.300. About: > In order to avoid using 15 digits in as.character(), we can use > round(,digits), > with digits argument appropriate for the current situation. > > > fact <- as.factor(round(nums,digits=1)); fact > [1] 0.3 0.3 0.3 0.3 > Levels: 0.3 The original problem was testing whether a floating-point number was a member of a vector. rounding and then converting to a factor seem like a very poor way of doing that, even if the above problems were resolved. Comparing with a tolerance seems much more robust, clean, and efficient. -s __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R does not compile any more on FreeBSD 8.0-CURRENT
On a recent FreeBSD 8.0-CURRENT (i386) building R (any version) breaks with the following messages: -- [...snip...] gcc -std=gnu99 -I. -I../../src/include -I../../src/include -I/usr/local/include -DHAVE_CONFIG_H -g -O2 -c wilcox.c -o wilcox.o gcc -std=gnu99 -I. -I../../src/include -I../../src/include -I/usr/local/include -DHAVE_CONFIG_H -g -O2 -c signrank.c -o signrank.o rm -rf libnmath.a ar cr libnmath.a mlutils.o d1mach.o i1mach.o fmax2.o fmin2.o fprec.o fround.o ftrunc.o sign.o fsign.o imax2.o imin2.o chebyshev.o log1p.o expm1.o lgammacor.o gammalims.o stirlerr.o bd0.o gamma.o lgamma.o gamma_cody.o beta.o lbeta.o polygamma.o bessel_i.o bessel_j.o bessel_k.o bessel_y.o choose.o snorm.o sexp.o dgamma.o pgamma.o qgamma.o rgamma.o dbeta.o pbeta.o qbeta.o rbeta.o dunif.o punif.o qunif.o runif.o dnorm.o pnorm.o qnorm.o rnorm.o dlnorm.o plnorm.o qlnorm.o rlnorm.o df.o pf.o qf.o rf.o dnf.o dt.o pt.o qt.o rt.o dnt.o dchisq.o pchisq.o qchisq.o rchisq.o rnchisq.o dbinom.o pbinom.o qbinom.o rbinom.o rmultinom.o dcauchy.o pcauchy.o qcauchy.o rcauchy.o dexp.o pexp.o qexp.o rexp.o dgeom.o pgeom.o qgeom.o rgeom.o dhyper.o phyper.o qhyper.o rhyper.o dnbinom.o pnbinom.o qnbinom.o rnbinom.o dpois.o ppois.o qpois.o rpois.o dweibull.o pweibull.o qweibull.o rweibull.o dlogis.o plogis.o qlogis.o rlogis.o dnchisq.o pnchisq.o qnchisq.o dnbeta.o pnbeta.o qnbeta.o pnf.o pnt.o qnf.o qnt.o ptukey.o qtukey.o toms708.o wilcox.o signrank.o ranlib libnmath.a config.status: creating src/unix/Makefile make: /usr/local/R-devel/srcunix: No such file or directory *** Error code 2 Stop in /usr/local/R-devel/src/unix. *** Error code 1 Stop in /usr/local/R-devel/src. *** Error code 1 Stop in /usr/local/R-devel. -- The path /usr/local/R-devel/srcunix does not exist but .../src/unix/ does. As a workaround I am able to do cd src/unix make cd ../.. make A second break with the same error does occur at /usr/local/R-devel/srcmain. Again this workaround works cd src/main make cd ../.. make Now the compilation finished without another break. What could be the reason for this 'path break'? So long it seems that this error on FreeBSD 8.0-CURRENT only appears with R and no other third party software. Potentially this is an error within latest FreeBSD code (?) and I have to ask on the FreeBSD mailing list. But before I wanted to ask on r-de...@. Perhaps someone here has an idea? Any hints are very welcome. Thanks in advance, Rainer Hurling __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Match .3 in a sequence
On Tue, Mar 17, 2009 at 10:04:39AM -0400, Stavros Macrakis wrote: ... > 1) Factor allows repeated levels, e.g. factor(c(1),c(1,1,1)), with no > warning or error. Yes, this is a confusing behavior, since repeated levels are never meaningful. > 2) Even from distinct inputs, factor of a numeric vector may generate > repeated levels, because it only uses 15 digits. I think, 15 digits is a reasonable choice. Mapping double precision numbers and character strings with a given decimal precision is never bijective. With 15 digits, we can achive that every character value has unique double precision representation, but not vice versa. With 17 digits, we have a unique character string for each double precision number, but not vice versa. What is better? Specification of as.character says() that the numbers are represented with 15 significant digits. So, I think, if as.factor() applies signif(,digits=15) to a numeric vector before determining the levels using sort(unique.default(x), this could help to eliminate most of the problems without being in conflict with the existing specification. > 3) The algorithm to determine the shortest format is inconsistent with > the algorithm to actually print, giving pathological cases like 0.3 > vs. 0.300. I do not exactly understand what you mean by inconsistent. If you do nums <- (.3 + 2e-16 * c(-2,-1,1,2)) options(digits=15) for (x in nums) print(x) # [1] 0.300 # [1] 0.3 # [1] 0.3 # [1] 0.300 as.character(nums) # [1] "0.300" "0.3" "0.3" # [4] "0.300" then print and as.character are consistent. Printing the whole vector behaves differently, since it uses the same format for all numbers. > The original problem was testing whether a floating-point number was a > member of a vector. rounding and then converting to a factor seem > like a very poor way of doing that, even if the above problems were > resolved. Comparing with a tolerance seems much more robust, clean, > and efficient. Definitely, using comparison tolerance is a meaningful approach. Its disadvantage is that the relation abs(x - y) <= eps is not transitive. So, it may also produce confusing results in some situations. I think that one has to choose the right solution depending on the application. Petr. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Match .3 in a sequence
Is this a reasonably fast way to do an approximate match of a vector x to values in a list? match.approx <- function(x,list,tol=.0001) sapply(apply(abs(outer(list,x,"-"))wrote: > Well, first of all, seq(from=.2,to=.3) gives c(0.2), so I assume you > really mean something like seq(from=.2,to=.3,by=.1), which gives > c(0.2, 0.3). > > %in% tests for exact equality, which is almost never a good idea with > floating-point numbers. > > You need to define what exactly you mean by "in" for floating-point > numbers. What sort of tolerance are you willing to allow? > > Some possibilities would be for example: > > approxin <- function(x,list,tol) any(abs(list-x) tolerance > > rapproxin <- function(x,list,tol) (x==0 && 0 %in% list) || > any(abs((list-x)/x)<=tol,na.rm=TRUE) > # relative tolerance; only exact 0 will match 0 > > Hope this helps, > > -s > > On Mon, Mar 16, 2009 at 9:36 AM, Daniel Murphy > wrote: > > Hello:I am trying to match the value 0.3 in the sequence seq(.2,.3). I > get > >> 0.3 %in% seq(from=.2,to=.3) > > [1] FALSE > > Yet > >> 0.3 %in% c(.2,.3) > > [1] TRUE > > For arbitrary sequences, this "invisible .3" has been problematic. What > is > > the best way to work around this? > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] exporting s3 and s4 methods
You shouldn't have to export the S3 function: in the normal practice,
setGeneric("biglm") or just a setMethod("biglm", ) will cause the S3
function (like any existing function) to become the default method for
the S4 generic. There is only one object called "biglm".
It's important though to use the default, one argument, call to
setGeneric(). Otherwise the two functions are not consistent and can't
exist in the same namespace. Also, the situation is different if the S3
function is in another package, as discussed in a previous thread here
recently.
The warning messages below, if they are still current, are misleading,
and usually outright wrong. The code should look at the default method
for the S4 generic.
John
PS: if this is the biglm() in the biglm package, the current CRAN
version is not a generic of any flavor. Presumably this is a new
version? Just curious, this has no effect on the above comments.
Thomas Lumley wrote:
If a package defined an S3 generic and an S4 generic for the same
function (so as to add methods for S4 classes to the existing code),
how do I set up the namespace to have them exported?
With import(stats)
exportMethods(bigglm)
importClassesFrom(DBI)
useDynLib(biglm)
export(biglm)
export(bigglm)
in NAMESPACE, the S3 generic is not exported.
methods("bigglm")
[1] bigglm.RODBC* bigglm.data.frame* bigglm.function*
Non-visible functions are asterisked
Warning messages:
1: In findGeneric(generic.function, parent.frame()) :
'bigglm' is a formal generic function; S3 methods will not likely be
found
2: In methods("bigglm") : function 'bigglm' appears not to be generic
[This is R 2.7.2, admittedly a little ancient]
-thomas
Thomas LumleyAssoc. Professor, Biostatistics
tlum...@u.washington.eduUniversity of Washington, Seattle
__
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] lsfit w/ rank-deficient x
Actually, the correct permutation is given by the inverse of qr$pivot: foo$coefficients[foo$qr$pivot] <- foo$coefficients Here foo is an object returned by lsfit, see below. -Original Message- From: Vadim Ogranovich Sent: Friday, March 13, 2009 5:25 PM To: 'r-devel@r-project.org' Subject: lsfit w/ rank-deficient x Dear R-devel, It seems that lsfit incorrectly reports coefficients when the input matrix 'x' is rank-deficient, see the example below: ## here values of 'b' and 'c' are incorrectly swapped > x <- cbind(a=rnorm(100), b=0, c=rnorm(100)); y <- rnorm(100); lsfit(x, y)$coef Intercept a b c -0.0227787 0.1042860 -0.1729261 0.000 Warning message: In lsfit(x, y) : 'X' matrix was collinear ## correct values > lsfit(x[,-2], y)$coef Intercept a c -0.0227787 0.1042860 -0.1729261 I looked inside the lsfit code and it appears that even though rank-deficiency is detected there is no attempt to patch the coefficients. Why is that? Taking clues from the code it appears that the following trick might do the work: > foo <- lsfit(x, y) Warning message: In lsfit(x, y) : 'X' matrix was collinear > structure(foo$coefficients[foo$qr$pivot], names=names(foo$coefficients)) Intercept a b c 0.14857345 -0.07473099 0. 0.12835155 Is this reliable or there are cases when it may fail? Thanks, Vadim P.S. > version _ platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status major 2 minor 7.1 year 2008 month 06 day23 svn rev45970 language R version.string R version 2.7.1 (2008-06-23) > Note: This email is for the confidential use of the named addressee(s) only and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you are hereby notified that any review, dissemination or copying of this email is strictly prohibited, and to please notify the sender immediately and destroy this email and any attachments. Email transmission cannot be guaranteed to be secure or error-free. Jump Trading, therefore, does not make any guarantees as to the completeness or accuracy of this email or any attachments. This email is for informational purposes only and does not constitute a recommendation, offer, request or solicitation of any kind to buy, sell, subscribe, redeem or perform any type of transaction of a financial product. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] exporting s3 and s4 methods
On Tue, 17 Mar 2009, John Chambers wrote:
It's important though to use the default, one argument, call to setGeneric().
Otherwise the two functions are not consistent and can't exist in the same
namespace.
Thanks. Does this include restricting which arguments are used for dispatch? I
have
setGeneric("bigglm", signature=c("formula","data"))
to dispatch just on the first two arguments.
I will try to run everything on my desktop back in Seattle to see if there are
still problems under r-devel -- my laptop is staying with its current version
of R until my book goes to the publisher.
PS: if this is the biglm() in the biglm package, the current CRAN version is
not a generic of any flavor. Presumably this is a new version?
You're missing a 'g'. It's bigglm(), which is S3-generic already. The current
version uses S3 inheritance on SQLiteConnection (which works, but doesn't
extend to other DBIConnection objects, as you pointed out previously).
-thomas
Thomas Lumley Assoc. Professor, Biostatistics
tlum...@u.washington.eduUniversity of Washington, Seattle
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Putting demo shell scripts, text files, and RScript files with a package?
I've written a package to assist with using R in Hadoop Streaming. The main point of the package is to help make command-line runnable RScript files. I'd like to provide a demo RScript file, a demo data file (e.g. a plaintext file, not something already processed by R) , as well as demo bash shell scripts that demonstrate how to run the job from the command line and in a Hadoop cluster. My best idea so far for distributing these files is to package the contents of these files as a list of strings in a data file in the data directory, and include a function in the package, say generateDemoFolder(targetDir), that writes the files to a user- specified directory, ready for use from the command line. Any suggestions? Thanks, David __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Match .3 in a sequence
On 3/17/2009 11:26 AM, Daniel Murphy wrote: Is this a reasonably fast way to do an approximate match of a vector x to values in a list? match.approx <- function(x,list,tol=.0001) sapply(apply(abs(outer(list,x,"-")) If you are willing to assume that the list values are all multiples of 2*tol, then it's easy: just divide both x and list by 2*tol, round to nearest integer, and use the regular match function. If not, it becomes harder; I'd probably use a solution like yours. Duncan Murdoch Thanks. -Dan On Mon, Mar 16, 2009 at 8:24 AM, Stavros Macrakis wrote: Well, first of all, seq(from=.2,to=.3) gives c(0.2), so I assume you really mean something like seq(from=.2,to=.3,by=.1), which gives c(0.2, 0.3). %in% tests for exact equality, which is almost never a good idea with floating-point numbers. You need to define what exactly you mean by "in" for floating-point numbers. What sort of tolerance are you willing to allow? Some possibilities would be for example: approxin <- function(x,list,tol) any(abs(list-x) wrote: > Hello:I am trying to match the value 0.3 in the sequence seq(.2,.3). I get >> 0.3 %in% seq(from=.2,to=.3) > [1] FALSE > Yet >> 0.3 %in% c(.2,.3) > [1] TRUE > For arbitrary sequences, this "invisible .3" has been problematic. What is > the best way to work around this? [[alternative HTML version deleted]] __ 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] Embedding R Engine in Cocoa
Hello Everyone, I'm attempting to use the R-Engine from the Mac R.app GUI project to embed R in an Objective-C application I'm writing. However, after a few days of trying, dependencies to the GUI keep tying me down. I don't need anything fancy, I'm just feeding in vectors and running regressions on them, but even that seems to escape me. I've seen on the outdated R/Cocoa page that there's a standalone engine * somewhere.* But I don't know if that's outdated information too. So, is there a simple project or tutorial out there that will allow me to interact with R programmatically? Thanks, David Zwerdling [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] question on "row.names" attribute of dataframe when called from a compiled package
Why does the following show a class attribute of "character" when
using the interpreter:
x <- data.frame(hat=1:10)
class(rownames(x)) ## returns [1] "character"
but when called from c/cpp, the rownames attribute has no class
attribute, and is in fact a vector of INTSXP?
> .Call("print_class_of_rownames", x, package = "test")
length(x): 10
TYPEOF(x): 13
R_ClassSymbol is null.
NULL
>
is this the intended behaviour?
-Whit
here is my test code:
SEXP print_class_of_rownames(SEXP dataframe_sexp) {
SEXP x = getAttrib(dataframe_sexp,install("row.names"));
cout << "length(x): " << length(x) << endl;
cout << "TYPEOF(x): " << TYPEOF(x) << endl;
if(getAttrib(x, R_ClassSymbol)==R_NilValue) {
cout << "R_ClassSymbol is null." << endl;
} else {
cout << "R_ClassSymbol is a good value." << endl;
}
return R_NilValue;
}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] question on "row.names" attribute of dataframe when called from a compiled package
On Mar 17, 2009, at 16:45 , Whit Armstrong wrote:
Why does the following show a class attribute of "character" when
using the interpreter:
x <- data.frame(hat=1:10)
class(rownames(x)) ## returns [1] "character"
but when called from c/cpp, the rownames attribute has no class
attribute
Note the difference between class("foo") and attr("foo", "class") -
some classes are implicit.
, and is in fact a vector of INTSXP?
Because the internal representation of automatic row names is c(NA, -
dim(d)[1]) where d is the data frame. This is not exposed at the R
level, though, since it's an implementation optimization.
.Call("print_class_of_rownames", x, package = "test")
length(x): 10
TYPEOF(x): 13
R_ClassSymbol is null.
NULL
is this the intended behaviour?
Yes - it saves a lot of space when using large datasets with automatic
names.
Cheers,
Simon
-Whit
here is my test code:
SEXP print_class_of_rownames(SEXP dataframe_sexp) {
SEXP x = getAttrib(dataframe_sexp,install("row.names"));
cout << "length(x): " << length(x) << endl;
cout << "TYPEOF(x): " << TYPEOF(x) << endl;
if(getAttrib(x, R_ClassSymbol)==R_NilValue) {
cout << "R_ClassSymbol is null." << endl;
} else {
cout << "R_ClassSymbol is a good value." << endl;
}
return R_NilValue;
}
__
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] Embedding R Engine in Cocoa
On Mar 17, 2009, at 15:51 , David Zwerdling wrote: Hello Everyone, I'm attempting to use the R-Engine from the Mac R.app GUI project to embed R in an Objective-C application I'm writing. However, after a few days of trying, dependencies to the GUI keep tying me down. I don't need anything fancy, I'm just feeding in vectors and running regressions on them, but even that seems to escape me. I've seen on the outdated R/Cocoa page that there's a standalone engine * somewhere.* But I don't know if that's outdated information too. There is a stand-alone version, indeed, at https://svn.r-project.org/R-packages/branches/stand-alone-REngine It needed a few small adjustments to match current R version, but it should be ok now. Don't forget to use R CMD when running your program, though, so the demo in the above should work with make R CMD ./test The default setup is now OS X but there are instructions in the Makefile on how to use it on other unices and I have tested it successfully with Linux and libFoundation. Cheers, Simon So, is there a simple project or tutorial out there that will allow me to interact with R programmatically? Thanks, David Zwerdling [[alternative HTML version deleted]] __ 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] exporting s3 and s4 methods
Thomas Lumley wrote:
On Tue, 17 Mar 2009, John Chambers wrote:
It's important though to use the default, one argument, call to
setGeneric(). Otherwise the two functions are not consistent and
can't exist in the same namespace.
Thanks. Does this include restricting which arguments are used for
dispatch? I have
setGeneric("bigglm", signature=c("formula","data"))
to dispatch just on the first two arguments.
That seems not to disturb anything. (It's really only the arguments
affecting the default that would break things directly. The other
non-defaults are a problem if multiple packages turn the same S3
function into a generic in inconsistent ways. But here you own both the
S3 and S4 versions.)
(R2.8.1)> foo <- function(x,y,z)UseMethod("foo")
(R2.8.1)> setGeneric("foo", signature = c("x", "y"))
[1] "foo"
(R2.8.1)> getMethod(foo) # the default
Method Definition (Class “derivedDefaultMethod”):
function (x, y, z)
UseMethod("foo")
Signatures:
target
defined
(R2.8.1)> f...@signature
[1] "x" "y"
__
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
