[Rd] weighted.residuals for glm objects (PR#7961)
Full_Name: Henric Nilsson
Version: 2.2.0 (2005-06-20 r34776)
OS: Windows 2000
Submission from: (NULL) (213.115.23.26)
The help page for `weighted.residuals' states that the function can be used with
both `lm' and `glm' objects. However, it's unclear what's meant by the following
passage
"Weighted residuals are the usual residuals Ri, multiplied by wi^0.5, where wi
are the weights as specified in lm's call."
when it comes to a GLM. What's "...usual residuals..." in this context?
After reading the code it's clear that the function multiplies the deviance
residuals by wi^0.5, but this doesn't seem sensible for a GLM. Consider e.g.
> set.seed(1)
> x <- runif(10)
> y <- x + rnorm(10)
> w <- 0:9
> weighted.residuals(lm(y ~ x, weights = w))
2 3 4 5 6 7 8
0.3845201 1.0361636 1.2689516 -0.9817686 3.7205310 1.3823979 -1.5458433
9 10
-6.2029822 2.6149474
> weighted.residuals(glm(y ~ x, weights = w))
2 3 4 5 6 7
0.3845201 1.4653567 2.1978886 -1.9635372 8.3193602 3.3861695
8 9 10
-4.0899170 -17.5446831 7.8448423
I suggest that the code for `weighted.residuals' is changed to
weighted.residuals <- function (obj, drop0 = TRUE)
{
w <- weights(obj)
r <- residuals(obj, type = "deviance")
if (is.null(w))
r
else if (drop0)
r[w != 0]
else r
}
which seems to do the "right thing" for both `lm' and `glm' objects.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Spelling of "parameter" in summary.nls(..., correlation = TRUE) (PR#8759)
Full_Name: Henric Nilsson Version: 2.3.0 alpha (2006-04-08 r37675) OS: Windows XP SP2 Submission from: (NULL) (212.209.13.15) The text preceeding the correlation matrix in summary.nls(..., correlation = TRUE) has a spelling error: parameter is spelled paraneter. > DNase1 <- subset(DNase, Run == 1) > fm1DNase1 <- nls(density ~ SSlogis(log(conc), Asym, xmid, scal), DNase1) > summary(fm1DNase1, cor = TRUE) Formula: density ~ SSlogis(log(conc), Asym, xmid, scal) Parameters: Estimate Std. Error t value Pr(>|t|) Asym 2.345180.07815 30.01 2.17e-13 *** xmid 1.483090.08135 18.23 1.22e-10 *** scal 1.041460.03227 32.27 8.51e-14 *** --- Signif. codes: 0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1 Residual standard error: 0.01919 on 13 degrees of freedom Correlation of Paraneter Estimates: Asym xmid xmid 0.99 scal 0.90 0.91 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Allowed quasibinomial links (PR#8851)
Full_Name: Henric Nilsson
Version: 2.3.0 Patched (2006-05-09 r38014)
OS: Windows 2000 SP4
Submission from: (NULL) (83.253.9.137)
When supplying an unavailable link to `quasibinomial', the error message looks
strange. E.g.
> quasibinomial("x")
Error in quasibinomial("x") : 'x' link not available for quasibinomial family,
available links are "logit", ", ""probit" and "cloglog"
Clearly, something's missing. A quick peek in the code reveals that `log' is
allowed, but is missing from the above list.
Furthermore, shouldn't `quasibinomial' also allow the `cauchit' link?
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Is there a version of RMySQL for Windows?
Den 2006-11-27 14:33, Roger D. Peng skrev:
> There are some pre-built binaries here:
>
> http://stat.bell-labs.com/RS-DBI/download/index.html
And an even newer one, for the current version of R, is here:
http://bus.cba.utulsa.edu/byersj/Research.asp
HTH,
Henric
>
> -roger
>
> Michal Okoniewski wrote:
>> I was trying to email directly the developer, David A. James, but all
>> the emails bounce...
>> Does anyone know if RMySQL may be re-compiled under Windows
>> and what are the limitations?
>>
>> Cheers,
>> Michal
>>
>>
>>
>>
>> This email is confidential and intended solely for the use o...{{dropped}}
>>
>> __
>> 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] R CMD check does not recognize S4 functions inside other functions?
On 2009-08-28 09:58, Martin Maechler wrote:
"GH" == Giles Hooker
on Thu, 27 Aug 2009 21:12:48 -0400 writes:
GH> I am developing a new R package and am now checking it for submission to
GH> CRAN.
GH> The some functions in the package make use of the sparse matrix routines
GH> in the package 'Matrix'.
GH> When these are loaded in R, they create no problems.
GH> However, when running R CMD check, I run into the following error in
GH> executing the examples in a .rd file:
>> DD = Matrix(diag(1,200),sparse=TRUE)
>> tDD = t(DD)
{{well, the transpose of a diagonal matrix, really ??}}
Just a remark: For larger values of n=200,
it would be more efficient (and elegant) to directly use
DD <- Diagonal(200)
See ?Diagonal, and e.g.,
> Diagonal(4)
4 x 4 diagonal matrix of class "ddiMatrix"
[,1] [,2] [,3] [,4]
[1,]1...
[2,].1..
[3,]..1.
[4,]...1
> .symDiagonal(4)
4 x 4 sparse Matrix of class "dsCMatrix"
[1,] 1 . . .
[2,] . 1 . .
[3,] . . 1 .
[4,] . . . 1
>>
>> fres = FitMatchOpt(coefs=coefs,which=2,pars=pars,proc)
GH> Error in t.default(DD) : argument is not a matrix
GH> Calls: FitMatchOpt -> t -> t.default
GH> Execution halted
GH> The first two lines of the function FitMatchOpt are
GH> DD = Matrix(diag(1,200),sparse=TRUE)
GH> tDD = t(DD)
GH> These were fine when given in the examples section of the .rd file
GH> directly. However, when defined within a function in the package, the
GH> lines cause an error.
How does your package "get Matrix"?
I'm sure there's some problem in requiring Matrix, in either
your DESCRIPTION or your NAMESPACE (or a .First.library or ...)
Your DESCRIPTION should have
Depends: , Matrix
Imports: , Matrix
Can you please clarify the simultaneous use of `Depends:' and `Imports'.
The Writing R Extensions manual explicitly says that:
"Packages declared in the 'Depends' field should not also be in the
'Imports' field."
Thanks,
Henric
and your NAMESPACE
either
importFrom("Matrix", .)# the things you need
or (if you use many things from the Matrix package, and/or
in some way just *extend* it ...)
import("Matrix")
Does that help?
Best regards,
Martin Maechler
GH> Sparse matrices improve the computational efficiency of the routines I
GH> am developing and I would like to use them. But I'm not sure how I can
GH> get around this error.
GH> Many thanks,
GH> Giles Hooker
GH> __
GH> R-devel@r-project.org mailing list
GH> 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] IDE for R C++ package writing ?
Den Fr, 2007-02-23, 11:49 skrev mel: > Dear all, > > I have to develop a (hopefully) small package for R in C++. > I didn't code in C++ for some years, and i'm now searching > for an adequate IDE for this task. > > Some of my criterions : not proprietary, not too heavy, > open to linux, not java gasworks, still maintained, etc > > After looking on several places > http://en.wikipedia.org/wiki/List_of_C%2B%2B_compilers_and_integrated_development_environments > http://www.freeprogrammingresources.com/cppide.html > + R docs > I was thinking on code::blocks, and emacs (and perhaps vim) > > Emacs seems used by some R developers as an R editor. > So i did think on emacs because it could perhaps be interesting > to have the same editor for R code and C++ code. > > However, when looking at the last emacs windows version, > it seems to date from january 2004 ... (dead end ?) > ftp://ftp.gnu.org/pub/gnu/emacs/windows/ Not a dead end: Emacs development has continued and version 22 is due RSN. For Windows users, I'd recommend EmacsW32 and binaries of the patched Emacs available from http://ourcomments.org/Emacs/EmacsW32.html. The binaries are current (22.0.93.1 last time I checked) and the provided EmacsW32 extension offers quite a few goodies. HTH, Henric > > I will be grateful for all advices on this tool topic. > Better choosing emacs ? or code::blocks ? > or another idea ? > Does somebody have an idea about the most used IDEs for > R C++ package writing ? > > Thanks > Vincent > > __ > 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] Unhidden predict methods
Hi,
I've noted that not all `predict' methods are hidden in the namespace:
> methods("predict")
[1] predict.ar*predict.Arima*
[3] predict.arima0*predict.glm
[5] predict.HoltWinters* predict.lm
[7] predict.loess* predict.mlm
[9] predict.nls* predict.poly
[11] predict.ppr* predict.prcomp*
[13] predict.princomp* predict.smooth.spline*
[15] predict.smooth.spline.fit* predict.StructTS*
Non-visible functions are asterisked
I'm sure there's a good reason for this, but I haven't been able to
figure it out. Please enlighten me.
Thanks!
Henric
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Unhidden predict methods
Den 2007-03-16 13:25, Prof Brian Ripley skrev:
> The reason some are not hidden is historical: they were called
> explicitly by (contributed) package code at the time namespaces were
> introduced.
Ah, I see.
In that case I'll just hide away as much as possible in the new package
I'm working on.
> It would be a good idea to revisit some of those decisions, but it is
> not a very appealing way to spend one's time.
Agreed.
Thanks again!
Henric
>
> On Fri, 16 Mar 2007, Henric Nilsson (Public) wrote:
>
>> Hi,
>>
>> I've noted that not all `predict' methods are hidden in the namespace:
>>
>> > methods("predict")
>> [1] predict.ar*predict.Arima*
>> [3] predict.arima0*predict.glm
>> [5] predict.HoltWinters* predict.lm
>> [7] predict.loess* predict.mlm
>> [9] predict.nls* predict.poly
>> [11] predict.ppr* predict.prcomp*
>> [13] predict.princomp* predict.smooth.spline*
>> [15] predict.smooth.spline.fit* predict.StructTS*
>>
>>Non-visible functions are asterisked
>>
>> I'm sure there's a good reason for this, but I haven't been able to
>> figure it out. Please enlighten me.
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R-2.6.0 for Windows, semi-transparent colours and layout()
Hi, The added support for semi-transparent colours in `windows' under R-2.6.0 for Windows is much appreciated. However, I've discovered that issuing a `layout' (or `par' with arguments `mfcol'/`mfrow') call and then trying to plot several figures with semi-transparent colour on the same page results in only the first one being fully drawn. E.g. > x <- rnorm(1) > y <- rnorm(1) > > layout(matrix(1:2, ncol = 2)) > plot(y ~ x, pch = 16, col = rgb(1, 0, 0, 0.15)) > plot(y ~ x, pch = 16, col = rgb(1, 0, 0, 0.15)) results in the second one having only the axes and box, but no data points. This is under > sessionInfo() R version 2.6.0 alpha (2007-09-14 r42843) i386-pc-mingw32 locale: LC_COLLATE=Swedish_Sweden.1252;LC_CTYPE=Swedish_Sweden.1252;LC_MONETARY=Swedish_Sweden.1252;LC_NUMERIC=C;LC_TIME=Swedish_Sweden.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base Henric __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-2.6.0 for Windows, semi-transparent colours and layout()
Prof Ripley, Quoting Prof Brian Ripley <[EMAIL PROTECTED]>: > On Sat, 15 Sep 2007, Henric Nilsson (Public) wrote: > >> Hi, >> >> The added support for semi-transparent colours in `windows' under >> R-2.6.0 for Windows is much appreciated. >> >> However, I've discovered that issuing a `layout' (or `par' with >> arguments `mfcol'/`mfrow') call and then trying to plot several figures >> with semi-transparent colour on the same page results in only the first >> one being fully drawn. E.g. > > That's not the whole story, as my test examples using multiple subplots > did work. > > The problem I found is that clipping rectangles were being used in some > places where I cannot find documentation that they should be. > So explicitly setting the clipping rectangle before each alpha-blending > call seems to fix the problematic examples, including yours. Many thanks for looking into and fixing this -- I really appreciate it! Henric >> >>> x <- rnorm(1) >>> y <- rnorm(1) >>> >>> layout(matrix(1:2, ncol = 2)) >>> plot(y ~ x, pch = 16, col = rgb(1, 0, 0, 0.15)) >>> plot(y ~ x, pch = 16, col = rgb(1, 0, 0, 0.15)) >> >> results in the second one having only the axes and box, but no data >> points. This is under >> >>> sessionInfo() >> R version 2.6.0 alpha (2007-09-14 r42843) >> i386-pc-mingw32 >> >> locale: >> LC_COLLATE=Swedish_Sweden.1252;LC_CTYPE=Swedish_Sweden.1252;LC_MONETARY=Swedish_Sweden.1252;LC_NUMERIC=C;LC_TIME=Swedish_Sweden.1252 >> >> attached base packages: >> [1] stats graphics grDevices utils datasets methods base >> >> >> Henric >> >> __ >> R-devel@r-project.org 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@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] typo in cov()? var() fails on NA in R 2.7.2 but not R 2.6.1
Andrew Piskorski wrote:
I recently started using R 2.7.2, and noticed a surprising change in
the behavior of var() on NA data:
R 2.6.1 (Patched), 2007-11-26, svn.rev 43541, x86_64-unknown-linux-gnu:
> stdev(rep(NA,3), na.rm=F)
[1] NA
> stdev(rep(NA,3), na.rm=T)
[1] NA
> var(rep(NA,3), na.rm=T, use="complete.obs")
[1] NA
R 2.7.2 (Patched), 2008-09-02, svn.rev 46491, x86_64-unknown-linux-gnu:
> stdev(rep(NA,3), na.rm=F)
[1] NA
> stdev(rep(NA,3), na.rm=T)
Error in var(x, na.rm = na.rm) : no complete element pairs
Enter a frame number, or 0 to exit
1: stdev(rep(NA, 3), na.rm = T)
2: var(x, na.rm = na.rm)
Selection: 0
> var(rep(NA,3), na.rm=T, use="complete.obs")
Error in var(rep(NA, 3), na.rm = T, use = "complete.obs") :
no complete element pairs
Is this change intentional? Also, what is causing it? Looking, I see
no changes in var() at all, so the new behavior must be due to a
change in what this call does:
.Internal(cov(x, y, na.method, FALSE))
The R 2.7.2 cov() also has this weird line:
else if (na.method != 3L) {
Note the "L" in the "3L". A typo? The older 2.6.1 cov() just has "3"
on that line, no "L".
Not a typo! See R-2.5.0's NEWS:
NEW FEATURES
o Introduced the suffix L for integer literals to create
integer rather than numeric values, e.g. 100L, 0x10L, 1e2L.
So,
> class(3)
[1] "numeric"
> class(3L)
[1] "integer"
HTH,
Henric
Interactively redefining cov() to remove the "L" makes no difference in my
var() calls, but that could b
The original source file seems to be:
src/library/stats/R/cor.R
svn annotate says that 3L line was last changed nearly a year ago, way
back in rev 43302:
r43302 | ripley | 2007-10-29 14:50:18 -0400 (Mon, 29 Oct 2007) | 2 lines
make cor/cov a little less inconsistent
The strange 3L line occurs twice in that file, in both cor() and cov():
$ grep -n 3L cor.R
36:else if (na.method != 3L) {
118:else if (na.method != 3L) {
That line might not be the cause of my "no complete element pairs"
problem (I'm not at all sure), but it does look suspicious.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
