[Rd] initialize expression in 'quasi' (PR#8486)
This is a multi-part message in MIME format.
--_=_NextPart_001_01C61962.212F35AB
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
This is not so much a bug as an infelicity in the code that can easily
be fixed.
The initialize expression in the quasi family function is, (uniformly
for all links and all variance functions):
initialize <- expression({
n <- rep.int(1, nobs)
mustart <- y + 0.1 * (y =3D=3D 0)
})
This is inappropriate (and often fails) for variance function
"mu(1-mu)". Here is a short demo to show it:
#
set.seed(666)
dat <- data.frame(x =3D rep((-10):10, each =3D 5), w =3D rep(1:5, 21))
dat <- transform(dat, y =3D rbinom(x, size =3D w, prob =3D pcauchy(1 + =
2*x)))
modFit <- glm(y/w ~ x, quasi(link =3D cauchit, variance =3D "mu(1-mu)"),
dat, weights =3D w, trace =3D T)
Deviance =3D 309.2785 Iterations - 1=20
Deviance =3D 3257.501 Iterations - 2=20
Deviance =3D 1043.455 Iterations - 3=20
..
Deviance =3D 1733.824 Iterations - 24=20
Deviance =3D 1665.487 Iterations - 25=20
Warning message:
algorithm did not converge in: glm.fit(x =3D X, ...
#
A comprehensive fix would involve tying the initialize expression to
both the link and the variance function, but that would involve changing
make.link(), which is probably not a good idea for other reasons (though
ultimately that might be the way to go). There are at least three
possible work-arounds:
1) use quasibinomial for this kind of model (but that's not possible
here and an unnecessary complication if you are transferring S-PLUS
code, which is how I found the problem) but quasibinomial could be
extended to take this link as well, of course.
2) warn people in the help information that with quasi() they should
always give the algorithm a bit more help and supply an appropriate
mustart. This works fine (even if the coefficient estimates are a bit
ropey!):
#
modFit <- glm(y/w ~ x, quasi(link =3D cauchit, variance =3D "mu(1-mu)"),
dat, weights =3D w, trace =3D T, mustart =3D pmax(0.001, pmin(0.999, =
y/w)))
Deviance =3D 218.9552 Iterations - 1=20
Deviance =3D 123.2773 Iterations - 2=20
Deviance =3D 86.13804 Iterations - 3=20
Deviance =3D 74.23746 Iterations - 4=20
Deviance =3D 72.03787 Iterations - 5=20
Deviance =3D 71.89566 Iterations - 6=20
Deviance =3D 71.89395 Iterations - 7=20
Deviance =3D 71.89395 Iterations - 8=20
Deviance =3D 71.89395 Iterations - 9=20
>=20
#
3) change quasi() slightly to cover this case, at least, in a better
way.
I have included a minimally modified version of quasi that I think
achieves this and the demo shown above.=20
With the changed version the performance, in this case, is identical to
what you get above when mustart is supplied. The changes cannot affect
performance with any other variance functions and with this variance
function should only make things better, but it just _might_ make things
work worse in extreme and unusual cases. I have not found one, though.
Bill Venables.=20
--please do not edit the information below--
Version:
platform =3D i386-pc-mingw32
arch =3D i386
os =3D mingw32
system =3D i386, mingw32
status =3D=20
major =3D 2
minor =3D 2.1
year =3D 2005
month =3D 12
day =3D 20
svn rev =3D 36812
language =3D R
Windows XP Professional (build 2600) Service Pack 2.0
Locale:
LC_COLLATE=3DEnglish_Australia.1252;LC_CTYPE=3DEnglish_Australia.1252;LC_=
MON
ETARY=3DEnglish_Australia.1252;LC_NUMERIC=3DC;LC_TIME=3DEnglish_Australia=
.1252
Search Path:
.GlobalEnv, package:mgcv, package:AusNew, package:MASS, package:RODBC,
package:lattice, package:splines, package:methods, package:stats,
package:graphics, package:grDevices, package:datasets, package:RBigData,
package:mvbutils, mvb.session.info, package:tools, package:utils,
package:RBigData, package:RUtilities, package:RBigLibrary,
package:g.data, Autoloads, package:base
Bill Venables,=20
CMIS, CSIRO Laboratories,=20
PO Box 120, Cleveland, Qld. 4163=20
AUSTRALIA=20
Office Phone (email preferred): +61 7 3826 7251=20
Fax (if absolutely necessary):+61 7 3826 7304=20
Mobile (rarely used):+61 4 1963 4642=20
Home Phone: +61 7 3286 7700=20
mailto:[EMAIL PROTECTED]
http://www.cmis.csiro.au/bill.venables/=20
--_=_NextPart_001_01C61962.212F35AB
Content-Type: application/octet-stream;
name="_quasi.R"
Content-Transfer-Encoding: base64
Content-Description: _quasi.R
Content-Disposition: attachment;
filename="_quasi.R"
InF1YXNpIiA8LQ0KZnVuY3Rpb24gKGxpbmsgPSAiaWRlbnRpdHkiLCB2YXJpYW5jZSA9ICJjb25z
dGFudCIpIA0Kew0KICAgIGxpbmt0ZW1wIDwtIHN1YnN0aXR1dGUobGluaykNCiAgICBpZiAoaXMu
ZXhwcmVzc2lvbihsaW5rdGVtcCkgfHwgaXMuY2FsbChsaW5rdGVtcCkpIA0KICAgICAgICBsaW5r
dGVtcCA8LSBsaW5rDQogICAgZWxzZSBpZiAoIWlzLmNoYXJhY3Rlc
Re: [Rd] Provide both shlib and standard versions of R?
On Mon, 16 Jan 2006, Bo Peng wrote: >> then either build your own with correct options or talk to your >> distribution's packaging team. > > It seems that my knowledge about this option is outdated. When I > first encountered this problem two years ago, the R/rpm distribution > came with no libR.so. I was told that --enable-R-shlib would lead to > 10% - 20% performance loss, and I had to re-compile R if I need to > embed it. > > So I guess performance is no longer an issue and shared libraries are > provided as default on all platforms now? I certainly welcome this > change and I apologize for my unfounded accusation to R. Why guess? There are accurate statements in the R-admin manual, and the RH RPM change was discussed on this list in 2006: https://stat.ethz.ch/pipermail/r-devel/2006-January/036118.html > BTW, shouldn't --enable-R-shlib be yes by default during ./configure?. No, for the reasons given in the R-admin manual. They include that there are platforms on which --enable-R-shlib cannot be used. We have been working (in R-devel) on changes which are designed to reduce the overhead of the shlib version of R: they do, but it is still over 10% on the platforms checked. (The figures given earlier are optimistic in the sense that they include time spent in compiled code in packages such as stats in a typical R session: worst-case scenarios have up to double that.) Please do think hard before you tell other people what they `should' do for you. -- 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] initialize expression in 'quasi' (PR#8486)
Bill,
As you see, R-bugs does not work with encoded (binary) attachments.
Could you please send this again to R-devel with (if possible) text
attachments?
The source code says
# 0.1 fudge here matches poisson: S has 1/6.
initialize <- expression({ n <- rep.int(1, nobs); mustart <- y + 0.1 * (y
== 0)})
although I believe S-PLUS has diverged here.
Brian
On Sun, 15 Jan 2006 [EMAIL PROTECTED] wrote:
> This is a multi-part message in MIME format.
>
> --_=_NextPart_001_01C61962.212F35AB
> Content-Type: text/plain;
> charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
>
> This is not so much a bug as an infelicity in the code that can easily
> be fixed.
>
> The initialize expression in the quasi family function is, (uniformly
> for all links and all variance functions):
>
>
>initialize <- expression({
>n <- rep.int(1, nobs)
>mustart <- y + 0.1 * (y =3D=3D 0)
>})
>
> This is inappropriate (and often fails) for variance function
> "mu(1-mu)". Here is a short demo to show it:
> #
>
> set.seed(666)
> dat <- data.frame(x =3D rep((-10):10, each =3D 5), w =3D rep(1:5, 21))
> dat <- transform(dat, y =3D rbinom(x, size =3D w, prob =3D pcauchy(1 + =
> 2*x)))
>
> modFit <- glm(y/w ~ x, quasi(link =3D cauchit, variance =3D "mu(1-mu)"),
> dat, weights =3D w, trace =3D T)
>
> Deviance =3D 309.2785 Iterations - 1=20
> Deviance =3D 3257.501 Iterations - 2=20
> Deviance =3D 1043.455 Iterations - 3=20
> ..
> Deviance =3D 1733.824 Iterations - 24=20
> Deviance =3D 1665.487 Iterations - 25=20
> Warning message:
> algorithm did not converge in: glm.fit(x =3D X, ...
> #
>
> A comprehensive fix would involve tying the initialize expression to
> both the link and the variance function, but that would involve changing
> make.link(), which is probably not a good idea for other reasons (though
> ultimately that might be the way to go). There are at least three
> possible work-arounds:
>
> 1) use quasibinomial for this kind of model (but that's not possible
> here and an unnecessary complication if you are transferring S-PLUS
> code, which is how I found the problem) but quasibinomial could be
> extended to take this link as well, of course.
>
> 2) warn people in the help information that with quasi() they should
> always give the algorithm a bit more help and supply an appropriate
> mustart. This works fine (even if the coefficient estimates are a bit
> ropey!):
>
> #
> modFit <- glm(y/w ~ x, quasi(link =3D cauchit, variance =3D "mu(1-mu)"),
> dat, weights =3D w, trace =3D T, mustart =3D pmax(0.001, pmin(0.999, =
> y/w)))
>
> Deviance =3D 218.9552 Iterations - 1=20
> Deviance =3D 123.2773 Iterations - 2=20
> Deviance =3D 86.13804 Iterations - 3=20
> Deviance =3D 74.23746 Iterations - 4=20
> Deviance =3D 72.03787 Iterations - 5=20
> Deviance =3D 71.89566 Iterations - 6=20
> Deviance =3D 71.89395 Iterations - 7=20
> Deviance =3D 71.89395 Iterations - 8=20
> Deviance =3D 71.89395 Iterations - 9=20
>> =20
> #
>
> 3) change quasi() slightly to cover this case, at least, in a better
> way.
>
> I have included a minimally modified version of quasi that I think
> achieves this and the demo shown above.=20
>
> With the changed version the performance, in this case, is identical to
> what you get above when mustart is supplied. The changes cannot affect
> performance with any other variance functions and with this variance
> function should only make things better, but it just _might_ make things
> work worse in extreme and unusual cases. I have not found one, though.
>
> Bill Venables.=20
>
>
>
> --please do not edit the information below--
>
> Version:
> platform =3D i386-pc-mingw32
> arch =3D i386
> os =3D mingw32
> system =3D i386, mingw32
> status =3D=20
> major =3D 2
> minor =3D 2.1
> year =3D 2005
> month =3D 12
> day =3D 20
> svn rev =3D 36812
> language =3D R
>
> Windows XP Professional (build 2600) Service Pack 2.0
>
> Locale:
> LC_COLLATE=3DEnglish_Australia.1252;LC_CTYPE=3DEnglish_Australia.1252;LC_=
> MON
> ETARY=3DEnglish_Australia.1252;LC_NUMERIC=3DC;LC_TIME=3DEnglish_Australia=
> .1252
>
> Search Path:
> .GlobalEnv, package:mgcv, package:AusNew, package:MASS, package:RODBC,
> package:lattice, package:splines, package:methods, package:stats,
> package:graphics, package:grDevices, package:datasets, package:RBigData,
> package:mvbutils, mvb.session.info, package:tools, package:utils,
> package:RBigData, package:RUtilities, package:RBigLibrary,
> package:g.data, Autoloads, package:base
>
> Bill Venables,=20
> CMIS, CSIRO Laboratories,=20
> PO Box 120, Cleveland, Qld. 4163=20
> AUSTRALIA=20
> Office Phone (email preferred): +61 7 3826 7251=20
> Fax (if absolutely necessary):+61 7 3826 7304=20
> Mobile (rarely used):+61 4 1963 4642=20
> Home Phone:
Re: [Rd] help.start() and Debian packaging (PR#8483)
While I agree with you, I find that the Debian packager does not. I already reported the problem to Debian, and they said that enough people want light-weight installations that they will continue splitting R into several parts. The package maintainer is Dirk Eddelbuettel <[EMAIL PROTECTED]>, and the relevant bug report is 348051. His response was this: | > Ok, that confirms that all you need to do is to install r-doc-html. No bug, | > it is designed this way. Consequently, I can only appeal to your humanity and to good programming practice. It is good programming practice to protect the user from his/her own mistakes, even if those mistakes are made easier/encouraged by Debian. It is also good programming practice to provide appropriate error messages when something goes wrong, even if it "shouldn't" ever go wrong. So, yeah, you can make an argument that you don't have to do it, but R will be a better piece of software if you make the change. Prof Brian Ripley wrote: > This is all based on a false premise: that a partial install of Debian > files is 'R'. > > R's own scripts do always install the HTML documentation, so > help.start() is entitled to assume that it is present. ... > > Note that your version of 'R' is not current. > > If there is a bug here, it is in the Debian re-packaging. I trust the > Debian packages do contain a bug reporting address other than this one: > please use the correct one. (The other binary distributions that I am > aware of, e.g. RPMs, do seem to include all of R.) > > On Sat, 14 Jan 2006 [EMAIL PROTECTED] wrote: > >> Full_Name: Greg Kochanski >> Version: 2.2.0 >> OS: Debian Linux on i686 >> Submission from: (NULL) (212.159.16.190) >> >> >> Debian packages the R documentation separately from the R core code. >> Consequently, it is possible for people to have R without >> the HTML documentation. (In fact, the docs are not installed by >> default, >> so it's very likely.) >> >> >> Thus, help.start() cannot depend on the HTML documentation being there. >> It should check for one (or a few) files and produce some reasonable >> error message if it is not there. Maybe something like >> "Warning: the HTML documentation is not installed." >> >> Alternatively, help.start() could produce references to some on-line >> HTML documentation, instead of local documentation. >> >> >> >> A related bug is that if one calls >> help.start() when the HTML documentation does not exist, >> all future calls to help() will lead to errors. > > > Working as documented is not a bug. > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] _pei386_runtime_relocator ? (PR#8491)
Hi, The problem arises when I try to use /bin/Rcmd shlib to create a DLL for external fortran code to do numerical integration from Dr. Alan Genz's website. I tried this yesterday after downloading R-tools, activePerl, mingw and cygwin and reinstalling R. I used the following command c:\"program files"\R\rw2010\bin\Rcmd shlib ranrth.f I got the following error message: In function 'DllMainCRTStartup': d:/src/mingw/build/runtime/../..runtime/dllcrt1.c:67: undefined reference to '_pei386_runtime_relocator' I am a new user, but I searched the R web-site first, and couldn't find this error message. A google search confirmed that it is a cygwin error message, but it was in an exchange between two cygwin developers, and I couldn't figure out what the message means. The only google hits were on the cygwin web-site. The cygwin web-site also said that they would flame any new users who asked stupid questions, and I am hoping you guys are more tolerant. thanks warmly, Marian Ewell __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Provide both shlib and standard versions of R?
> Why guess? There are accurate statements in the R-admin manual, I read the manual 2 years ago, and the info I got was still correct. > and the RH RPM change was discussed on this list in 2006: > https://stat.ethz.ch/pipermail/r-devel/2006-January/036118.html I simply do not know RPMs have been built with this option on, and there is no definite place/word I can be assured about this. > No, for the reasons given in the R-admin manual. Even the reason I gave in my first email was not up to date (most binary distributions are compiled with this option), my suggest is still valid: why not provide two binaries? Most users can use standard R without sacrificing performance and embedding applications use libR.so and, if needed, a separate binary R_embed. Cheers, Bo __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Provide both shlib and standard versions of R?
On Mon, 2006-01-16 at 00:45 -0600, Bo Peng wrote:
> > then either build your own with correct options or talk to your
> > distribution's packaging team.
>
> It seems that my knowledge about this option is outdated. When I
> first encountered this problem two years ago, the R/rpm distribution
> came with no libR.so. I was told that --enable-R-shlib would lead to
> 10% - 20% performance loss, and I had to re-compile R if I need to
> embed it.
>
> So I guess performance is no longer an issue and shared libraries are
> provided as default on all platforms now? I certainly welcome this
> change and I apologize for my unfounded accusation to R.
What changed was that a sufficient number of people asked me to create
an RPM with the shared library and I changed my mind. The aim of the
precompiled binaries is to satisfy most of the people most of the time,
and when I get repeated requests for the same feature, I have to bear
that in mind. People who require optimal performance can still compile
their own.
As for the idea of compiling two distinct binaries packages for R, I am
not especially keen, and not just out of laziness. The problem is that R
packages depend on libR.so, when it exists, so if you uninstall R with a
shared library and then install R without the shared library you get a
broken system.
You can look at the CAPABILITIES file in the same directory as the RPM
to see how it was compiled.
Martyn
> BTW, shouldn't --enable-R-shlib be yes by default during ./configure?.
>
> Cheers,
> Bo
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
---
This message and its attachments are strictly confidential. ...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] problem unpacking R sources (PR#8492)
Full_Name: Steven L. Scott Version: 2.2.1 OS: Windows-Cygwin Submission from: (NULL) (128.125.60.50) I've had problems unpacking the R source coded downloaded from http://lib.stat.cmu.edu/R/CRAN/src/base/R-2/R-2.2.1.tar.gz Version info for tar and gunzip provided below (GNU legalese edited out), along with the error messages I get. Thanks. Steve /notcygwin[506] gunzip --version gunzip 1.3.5 (2002-09-30) Copyright 2002 Free Software Foundation Copyright 1992-1993 Jean-loup Gailly Compilation options: DIRENT UTIME STDC_HEADERS HAVE_UNISTD_H HAVE_MEMORY_H HAVE_STRING_H HAVE_LSTAT ASMV Written by Jean-loup Gailly. /notcygwin[507] tar --version tar (GNU tar) 1.13.25 Copyright (C) 2001 Free Software Foundation, Inc. Written by John Gilmore and Jay Fenlason. /notcygwin[508] gunzip R-2.2.1.tar.gz R-2.2.1.tar.gz: 0.2% -- replaced with R-2.2.1.tar /notcygwin[509] tar xf R-2.2.1.tar tar: This does not look like a tar archive tar: Skipping to next header tar: Archive contains obsolescent base-64 headers tar: Error exit delayed from previous errors __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] problem unpacking R sources (PR#8492)
[EMAIL PROTECTED] wrote: > Full_Name: Steven L. Scott > Version: 2.2.1 > OS: Windows-Cygwin > Submission from: (NULL) (128.125.60.50) > > > I've had problems unpacking the R source coded downloaded from >http://lib.stat.cmu.edu/R/CRAN/src/base/R-2/R-2.2.1.tar.gz This is not a bug in R!!! The Statlib mirror is known to be broken. Please download from another mirror. Please check the archives before submitting a bug report! Uwe Ligges > Version info for tar and gunzip provided below (GNU legalese edited out), > along > with the error messages I get. > Thanks. > Steve > > /notcygwin[506] gunzip --version > gunzip 1.3.5 > (2002-09-30) > Copyright 2002 Free Software Foundation > Copyright 1992-1993 Jean-loup Gailly > Compilation options: > DIRENT UTIME STDC_HEADERS HAVE_UNISTD_H HAVE_MEMORY_H HAVE_STRING_H HAVE_LSTAT > ASMV > Written by Jean-loup Gailly. > > /notcygwin[507] tar --version > tar (GNU tar) 1.13.25 > Copyright (C) 2001 Free Software Foundation, Inc. > Written by John Gilmore and Jay Fenlason. > > /notcygwin[508] gunzip R-2.2.1.tar.gz > R-2.2.1.tar.gz: 0.2% -- replaced with R-2.2.1.tar > > /notcygwin[509] tar xf R-2.2.1.tar > tar: This does not look like a tar archive > tar: Skipping to next header > tar: Archive contains obsolescent base-64 headers > tar: Error exit delayed from previous errors > > __ > 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] initialize expression in 'quasi' (PR#8486)
My apologies, I thought it was going as a text attachement. Looks like
Microsoft second guessing me again.
The problem is the 'mustart' value (if you are going to base it on the
variance structure and not the link as well) should not allow values to
touch the point
where the variance becomes zero. The fudge that is in there now obeys
this
'rule' for all but the mu(1-mu). It is a bit too strong for the
'constant'
case, but I guess we are stuck with that now for back compatibility
reasons.
Here is my suggestion:
##(cut
here)##
quasi <- function (link = "identity", variance = "constant") {
linktemp <- substitute(link)
if (is.expression(linktemp) || is.call(linktemp))
linktemp <- link
else if (!is.character(linktemp))
linktemp <- deparse(linktemp)
if (is.character(linktemp))
stats <- make.link(linktemp)
else stats <- linktemp
variancetemp <- substitute(variance)
if (!is.character(variancetemp)) {
variancetemp <- deparse(variancetemp)
if (linktemp == "variance")
variancetemp <- eval(variance)
}
initialize <- NULL
###change
switch(variancetemp,
constant = {
variance <- function(mu) rep.int(1, length(mu))
dev.resids <- function(y, mu, wt) wt * ((y - mu)^2)
validmu <- function(mu) TRUE
},
"mu(1-mu)" = {
variance <- function(mu) mu * (1 - mu)
validmu <- function(mu) all(mu > 0) && all(mu < 1)
dev.resids <- function(y, mu, wt) 2 * wt * (y * log(ifelse(y ==
0, 1, y/mu)) + (1 - y) * log(ifelse(y == 1, 1, (1 -
y)/(1 - mu
initialize <- expression({
###change
n <- rep.int(1, nobs)
###change
mustart <- pmax(0.001, pmin(0.999, y))###change
})
###change
},
mu = {
variance <- function(mu) mu
validmu <- function(mu) all(mu > 0)
dev.resids <- function(y, mu, wt) 2 * wt * (y * log(ifelse(y ==
0, 1, y/mu)) - (y - mu))
},
"mu^2" = {
variance <- function(mu) mu^2
validmu <- function(mu) all(mu > 0)
dev.resids <- function(y, mu, wt) pmax(-2 * wt * (log(ifelse(y
==
0, 1, y)/mu) - (y - mu)/mu), 0)
},
"mu^3" = {
variance <- function(mu) mu^3
validmu <- function(mu) all(mu > 0)
dev.resids <- function(y, mu, wt) wt * ((y - mu)^2)/(y *
mu^2)
},
stop(gettextf("'variance' \"%s\" is invalid: possible values are
\"mu(1-mu)\", \"mu\", \"mu^2\", \"mu^3\" and \"constant\"",
variancetemp), domain = NA))
if(is.null(initialize))
###change
initialize <- expression({
n <- rep.int(1, nobs)
mustart <- y + 0.1 * (y == 0)
})
aic <- function(y, n, mu, wt, dev) NA
structure(list(family = "quasi", link = linktemp, linkfun =
stats$linkfun,
linkinv = stats$linkinv, variance = variance, dev.resids =
dev.resids,
aic = aic, mu.eta = stats$mu.eta, initialize = initialize,
validmu = validmu, valideta = stats$valideta, varfun =
variancetemp),
class = "family")
}
###(cut here)##
Bill Venables,
CMIS, CSIRO Laboratories,
PO Box 120, Cleveland, Qld. 4163
AUSTRALIA
Office Phone (email preferred): +61 7 3826 7251
Fax (if absolutely necessary):+61 7 3826 7304
Mobile (rarely used):+61 4 1963 4642
Home Phone: +61 7 3286 7700
mailto:[EMAIL PROTECTED]
http://www.cmis.csiro.au/bill.venables/
-Original Message-
From: Prof Brian Ripley [mailto:[EMAIL PROTECTED]
Sent: Monday, 16 January 2006 6:28 PM
To: Venables, Bill (CMIS, Cleveland)
Cc: r-devel@stat.math.ethz.ch
Subject: Re: [Rd] initialize expression in 'quasi' (PR#8486)
Bill,
As you see, R-bugs does not work with encoded (binary) attachments.
Could you please send this again to R-devel with (if possible) text
attachments?
The source code says
# 0.1 fudge here matches poisson: S has 1/6.
initialize <- expression({ n <- rep.int(1, nobs); mustart <- y +
0.1 * (y == 0)})
although I believe S-PLUS has diverged here.
Brian
On Sun, 15 Jan 2006 [EMAIL PROTECTED] wrote:
> This is a multi-part message in MIME format.
>
> --_=_NextPart_001_01C61962.212F35AB
> Content-Type: text/plain;
> charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
>
> This is not so much a bug as an infelicity in the code that can easily
> be fixed.
>
> The initialize expression in the quasi family function is, (uniformly
> for all links and all variance functions):
>
>
>initialize <- expression({
>n <- rep.int(1, nobs)
>mustart <- y + 0.1 * (y =3D=3D 0)
>})
>
> This is inappropriate (and often fails) for variance function
> "mu(1-mu)". Here is a short demo to show it:
> #
>
> set.seed(666)
> dat <- data.fra
[Rd] Error handling in solve.default (PR#8494)
Hi, this is a minor problem in solve.default but I didn't see anyone
mention it. The function does not give "correct" error-handling if given
non-square matrix, LINPACK=F, and matrix has names attributes (either
row or column names).
Demo:
##"correct" error handling of non-square matrix
> temp<-diag(1,5)[,1:4]
> solve(temp,LINPACK=F)
Error in solve.default(diag(1, 5)[, 1:4], LINPACK = F) :
'A' (5 x 4) must be square
#indeciferable error handling when same matrix is given names attributes
> temp<-diag(1,5)[,1:4]
> rownames(temp)<-as.character(1:5)
> colnames(temp)<-as.character(1:4)
> solve(temp,LINPACK=F)
Error in "rownames<-"(`*tmp*`, value = c("1", "2", "3", "4")) :
length of 'dimnames' [1] not equal to array extent
I think the problem is that if LINPACK=F, then the error handling of the
argument "a" is not done until after creating a matrix "b", when none
was given. Then, the function creates a square identity matrix for "b",
to which it tries to assign row and column names of "a". Of course,
since "a" is not square, they are not of the correct length.
Best,
Elizabeth
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
