Hi Simon,
Yes, if I uses coefficients() I get the same results for lm() and lm.ridge().
So that's consistent, at least.
Interestingly, the "wrong" number I get from lm.ridge()$coef agrees with the
value from SPSS to 5dp, which is an interesting coincidence if these numbers
have no
Hi Nick,
I think that the problem here is your use of $coef to extract the coefficients
of the ridge regression. The help for lm.ridge states that coef is a "matrix of
coefficients, one row for each value of lambda. Note that these are not on the
original scale and are for use by the coef
Hi Ti-Tai,
Not much you or we can do about this. Hopefully the RMySQL Windows
binary (currently 0.10.11) will soon be fixed on CRAN.
Thanks for keeping an eye on the build results for anamiR.
Best,
H.
On 05/04/2017 08:28 AM, 王棣台 wrote:
Hi all,
It turns out that this error is related to the
Um, the link to StackOverflow does not seem to contain the same question. It
does contain a stern warning not to use the $coef component of lm.ridge...
Is it perhaps the case that x1 and x2 have already been scaled to have standard
deviation 1? In that case, x1*x2 won't be.
Also notice that
On 04/05/2017 10:28 AM, Nick Brown wrote:
Hallo,
I hope I am posting to the right place. I was advised to try this list by Ben
Bolker (https://twitter.com/bolkerb/status/859909918446497795). I also posted
this question to StackOverflow
The bioconductor dockers have been updated for the release. The release
versions now utilize R 3.4.0 and Bioc 3.5 while the devel versions now utilize
R 3.4.0 and Bioc 3.6. Older versions are available using tags. For more
information on Bioconductor dockers please see
Hi,
I am creating an R package with multiple c files within src directory. If
possible, I would like to create separate dll files for each c file. Also I
would like those dll files to have the same name as the input c files. i.e:
mod01.c -o mod01.dll
mod02.c -o mod02.dll
mod03.c -o mod03.dll
Hi all,
It turns out that this error is related to the RMySQL package(CRAN),
and only happened in windows operating system.
https://github.com/rstats-db/RMySQL/issues/190
It looks like it can be solved only if we downgraded the RMySQL version now.
Can I choose not to import the newest RMySQL
OK thanks -- this gives me a new perspective. I see this result:
> tools::nonS3methods("coda")
[1] "as.mcmc.list"
which indicates more about the mechanisms in place for this kind of situation.
So now it seems that if package 'pkg_B' simply imports and exports a function
There is no way to control this at runtime.
We will probably have to add a configure test.
Best,
Tomas
On 05/04/2017 03:23 PM, Kasper Daniel Hansen wrote:
> Thanks.
>
> I assume there is no way to control this via. environment variables or
> configure settings? Obviously that would be great
Thanks.
I assume there is no way to control this via. environment variables or
configure settings? Obviously that would be great for something like this
which affects tests and seems to be a known problem for older C standard
libraries.
Best,
Kasper
On Thu, May 4, 2017 at 9:12 AM, Tomas
As a quick fix, you can undefine HAVE_CTANH in complex.c, somewhere
after including config.h
An internal substitute, which is implemented inside complex.c, will be used.
Best
Tomas
On 05/04/2017 02:57 PM, Kasper Daniel Hansen wrote:
For a while I have been getting that the complex tests
For a while I have been getting that the complex tests fails on RHEL 6.
The specific issue has to do with tanh (see below for full output from
complex.Rout.fail).
This is both with the stock compiler (GCC 4.4.7) and a compiler supplied
through the conda project (GCC 4.8.5). The compiler supplied
On 03.05.2017 18:39, Lenth, Russell V wrote:
Package developers list:
I recently added an 'as.mcmc.list' method for objects in one of my packages.
Now, in doing an --as-cran check, I get this message:
* checking S3 generic/method consistency ... NOTE
Found the following apparent S3 methods
14 matches
Mail list logo
