Re: [Rd] pnorm
Hi, thanks to all for the helpful information. In fact our colleague is indeed keen to check for the difference. More importantly, I was in too much a haste to drop the message as I now recalled we got around in a similar way in Stata and SAS for a more extreme case before. JH > Date: Thu, 7 Feb 2008 13:04:58 -0800 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > CC: [EMAIL PROTECTED] > Subject: Re: [Rd] pnorm > > On Thu, 7 Feb 2008, jing hua zhao wrote: > > > > I calculated a two-sided p values according to 2*(1-pnorm(8.104474)), > > which gives 4.440892e-16. However, it appears to be 5.30E-16 by a > > colleague and 5.2974E-16 from SAS. I tried to get around with mvtnorm > > package but it turns out to be using pnorm for univariate case. I should > > have missed some earlier discussions, but for the moment is there any > > short answer for a higher precision? > > pnorm(8.104474,lower.tail=FALSE)*2 gives the same answer as SAS, and > pnorm(8.104474,lower.tail=FALSE,log=TRUE)/log(10)+log(2,10) > gives the (base-10) logarithm of the p-value, which is often the preferred > genetics scale. These are much more accurate. > > > > Somehow these days, statistical > > geneticists are infatuated with such tiny p values! > > Yes, but in my experience they are at least fairly realistic about the > lack of difference between 4e-16 and 5e-16. > > -thomas > > Thomas Lumley Assoc. Professor, Biostatistics > [EMAIL PROTECTED] University of Washington, Seattle _ Free games, great prizes - get gaming at Gamesbox. [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] xspline(..., draw=FALSE) fails if there is no open device (PR#10727)
[EMAIL PROTECTED] wrote:
> Full_Name: Jari Oksanen
> Version: 2.6.2 RC (2008-02-07 r44369)
> OS: Linux
> Submission from: (NULL) (130.231.102.145)
>
>
> Even if function xspline() is called with argument draw=FALSE, it requires a
> graphics device (that it won't use since it was draw=FALSE). I run into this
> because I intended to use xspline within a function (that does not yet draw:
> there is plot method for that), and the function failed when called in a
> virgin
> environment.
>
> Here is an example in a virgin environemt just after starting R:
>
>
>> out <- xspline(c(0,1,0), c(1,0,1), draw=FALSE)
>>
> Error in xspline(c(0, 1, 0), c(1, 0, 1), draw = FALSE) :
> plot.new has not been called yet
>
>> str(out)
>>
> Error in str(out) : object "out" not found
>
> This works:
>
>
>> plot(0)
>> out <- xspline(c(0,1,0), c(1,0,1), draw=FALSE)
>> str(out)
>>
> List of 2
> $ x: num [1:3] 0 1 0
> $ y: num [1:3] 1 0 1
>
> This won't:
>
>
>> dev.off()
>>
> null device
> 1
>
>> xspline(c(0,1,0), c(1,0,1), draw=FALSE)
>>
> Error in xspline(c(0, 1, 0), c(1, 0, 1), draw = FALSE) :
> plot.new has not been called yet
>
> R graphics internal are black magic to me. However, it seems that the error
> messge comes from function GCheckState(DevDesc *dd) in graphics.c, which is
> called by do_xspline(SEXP call, SEXP op, SEXP args, SEXP env) in plot.c even
> when xspline was called with draw = FALSE (and even before getting the
> argument
> draw into do_xspline). It seems that graphics device is needed somewhere even
> with draw = FALSE, since moving the GCheckState() test after findig the value
> draw, and executing the test only if draw=TRUE gave NaN as the numeric
> output.
>
> If this is documented behaviour, the documentation escaped my attention and
> beg
> for pardon. It may be useful to add a comment on the help page saying that an
> open graphics device is needed even when unused with draw=FALSE.
>
>
I think the reason is that 2d splines are aspect ratio dependent.
There's this loop inside,
for (i = 0; i < nx; i++) {
xx[i] = x[i];
yy[i] = y[i];
GConvert(&(xx[i]), &(yy[i]), USER, DEVICE, dd);
}
and that will not work without knowing how to convert to device
coordinates. The default for "border" may get you first, though. That
seems to be documented incorrectly, by the way.
-p
> Cheers, Jari Oksanen
>
> platform = i686-pc-linux-gnu
> arch = i686
> os = linux-gnu
> system = i686, linux-gnu
> status = RC
> major = 2
> minor = 6.2
> year = 2008
> month = 02
> day = 07
> svn rev = 44369
> language = R
> version.string = R version 2.6.2 RC (2008-02-07 r44369)
>
> Locale:
> LC_CTYPE=en_GB.UTF-8;LC_NUMERIC=C;LC_TIME=en_GB.UTF-8;LC_COLLATE=en_GB.UTF-8;LC_MONETARY=en_GB.UTF-8;LC_MESSAGES=en_GB.UTF-8;LC_PAPER=en_GB.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_GB.UTF-8;LC_IDENTIFICATION=C
>
> Search Path:
> .GlobalEnv, package:stats, package:graphics, package:grDevices,
> package:utils,
> package:datasets, package:methods, Autoloads, package:base
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] xspline(..., draw=FALSE) fails if there is no open device (PR#10728)
[EMAIL PROTECTED] wrote:
> Full_Name: Jari Oksanen
> Version: 2.6.2 RC (2008-02-07 r44369)
> OS: Linux
> Submission from: (NULL) (130.231.102.145)
>
>
> Even if function xspline() is called with argument draw=3DFALSE, it req=
uires a
> graphics device (that it won't use since it was draw=3DFALSE). I run in=
to this
> because I intended to use xspline within a function (that does not yet =
draw:
> there is plot method for that), and the function failed when called in =
a virgin
> environment.=20
>
> Here is an example in a virgin environemt just after starting R:
>
> =20
>> out <- xspline(c(0,1,0), c(1,0,1), draw=3DFALSE)
>>=20
> Error in xspline(c(0, 1, 0), c(1, 0, 1), draw =3D FALSE) :=20
> plot.new has not been called yet
> =20
>> str(out)
>>=20
> Error in str(out) : object "out" not found
>
> This works:
>
> =20
>> plot(0)
>> out <- xspline(c(0,1,0), c(1,0,1), draw=3DFALSE)
>> str(out)
>>=20
> List of 2
> $ x: num [1:3] 0 1 0
> $ y: num [1:3] 1 0 1
>
> This won't:
>
> =20
>> dev.off()
>>=20
> null device=20
> 1=20
> =20
>> xspline(c(0,1,0), c(1,0,1), draw=3DFALSE)
>>=20
> Error in xspline(c(0, 1, 0), c(1, 0, 1), draw =3D FALSE) :=20
> plot.new has not been called yet
>
> R graphics internal are black magic to me. However, it seems that the e=
rror
> messge comes from function GCheckState(DevDesc *dd) in graphics.c, whic=
h is
> called by do_xspline(SEXP call, SEXP op, SEXP args, SEXP env) in plot.c=
even
> when xspline was called with draw =3D FALSE (and even before getting th=
e argument
> draw into do_xspline). It seems that graphics device is needed somewher=
e even
> with draw =3D FALSE, since moving the GCheckState() test after findig =
the value
> draw, and executing the test only if draw=3DTRUE gave NaN as the numeri=
c output.=20
>
> If this is documented behaviour, the documentation escaped my attention=
and beg
> for pardon. It may be useful to add a comment on the help page saying t=
hat an
> open graphics device is needed even when unused with draw=3DFALSE.
>
> =20
I think the reason is that 2d splines are aspect ratio dependent. =20
There's this loop inside,
for (i =3D 0; i < nx; i++) {
xx[i] =3D x[i];
yy[i] =3D y[i];
GConvert(&(xx[i]), &(yy[i]), USER, DEVICE, dd);
}
=20
and that will not work without knowing how to convert to device=20
coordinates. The default for "border" may get you first, though. That=20
seems to be documented incorrectly, by the way.
-p
> Cheers, Jari Oksanen
>
> platform =3D i686-pc-linux-gnu
> arch =3D i686
> os =3D linux-gnu
> system =3D i686, linux-gnu
> status =3D RC
> major =3D 2
> minor =3D 6.2
> year =3D 2008
> month =3D 02
> day =3D 07
> svn rev =3D 44369
> language =3D R
> version.string =3D R version 2.6.2 RC (2008-02-07 r44369)
>
> Locale:
> LC_CTYPE=3Den_GB.UTF-8;LC_NUMERIC=3DC;LC_TIME=3Den_GB.UTF-8;LC_COLLATE=3D=
en_GB.UTF-8;LC_MONETARY=3Den_GB.UTF-8;LC_MESSAGES=3Den_GB.UTF-8;LC_PAPER=3D=
en_GB.UTF-8;LC_NAME=3DC;LC_ADDRESS=3DC;LC_TELEPHONE=3DC;LC_MEASUREMENT=3D=
en_GB.UTF-8;LC_IDENTIFICATION=3DC
>
> Search Path:
> .GlobalEnv, package:stats, package:graphics, package:grDevices, packag=
e:utils,
> package:datasets, package:methods, Autoloads, package:base
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> =20
--=20
O__ Peter Dalgaard =D8ster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327=
918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327=
907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] xspline(..., draw=FALSE) fails if there is no open device (PR#10727)
Full_Name: Jari Oksanen Version: 2.6.2 RC (2008-02-07 r44369) OS: Linux Submission from: (NULL) (130.231.102.145) Even if function xspline() is called with argument draw=FALSE, it requires a graphics device (that it won't use since it was draw=FALSE). I run into this because I intended to use xspline within a function (that does not yet draw: there is plot method for that), and the function failed when called in a virgin environment. Here is an example in a virgin environemt just after starting R: > out <- xspline(c(0,1,0), c(1,0,1), draw=FALSE) Error in xspline(c(0, 1, 0), c(1, 0, 1), draw = FALSE) : plot.new has not been called yet > str(out) Error in str(out) : object "out" not found This works: > plot(0) > out <- xspline(c(0,1,0), c(1,0,1), draw=FALSE) > str(out) List of 2 $ x: num [1:3] 0 1 0 $ y: num [1:3] 1 0 1 This won't: > dev.off() null device 1 > xspline(c(0,1,0), c(1,0,1), draw=FALSE) Error in xspline(c(0, 1, 0), c(1, 0, 1), draw = FALSE) : plot.new has not been called yet R graphics internal are black magic to me. However, it seems that the error messge comes from function GCheckState(DevDesc *dd) in graphics.c, which is called by do_xspline(SEXP call, SEXP op, SEXP args, SEXP env) in plot.c even when xspline was called with draw = FALSE (and even before getting the argument draw into do_xspline). It seems that graphics device is needed somewhere even with draw = FALSE, since moving the GCheckState() test after findig the value draw, and executing the test only if draw=TRUE gave NaN as the numeric output. If this is documented behaviour, the documentation escaped my attention and beg for pardon. It may be useful to add a comment on the help page saying that an open graphics device is needed even when unused with draw=FALSE. Cheers, Jari Oksanen platform = i686-pc-linux-gnu arch = i686 os = linux-gnu system = i686, linux-gnu status = RC major = 2 minor = 6.2 year = 2008 month = 02 day = 07 svn rev = 44369 language = R version.string = R version 2.6.2 RC (2008-02-07 r44369) Locale: LC_CTYPE=en_GB.UTF-8;LC_NUMERIC=C;LC_TIME=en_GB.UTF-8;LC_COLLATE=en_GB.UTF-8;LC_MONETARY=en_GB.UTF-8;LC_MESSAGES=en_GB.UTF-8;LC_PAPER=en_GB.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_GB.UTF-8;LC_IDENTIFICATION=C Search Path: .GlobalEnv, package:stats, package:graphics, package:grDevices, package:utils, package:datasets, package:methods, Autoloads, package:base __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] bad variable names when printing a data frame containing a matrix (PR#10730)
library(glmpath) data(heart.data) # heart.data is a list, $y a vector, $x a matrix data <- data.frame(x=I(heart.data$x), y = heart.data$y) > data[1:2,] x.1 x.2 x.3 x.4 x.5 x.6 x.7 x.8 x.9 y 1 16012 5.73 23.11 149 25.3 97.252 1 2 144 0.01 4.41 28.61 055 28.87 2.0663 1 > dimnames(heart.data$x)[[2]] [1] "sbp" "tobacco" "ldl" "adiposity" "famhist" "typea" [7] "obesity" "alcohol" "age" Note that the printed variable names do not use the column names of the matrix. In contrast, in S-PLUS the names are used; the printout begins: x.sbp x.tobacco x.ldl x.adiposity x.famhist x.typea x.obesity x.alcohol --please do not edit the information below-- Version: platform = i386-pc-mingw32 arch = i386 os = mingw32 system = i386, mingw32 status = major = 2 minor = 6.1 year = 2007 month = 11 day = 26 svn rev = 43537 language = R version.string = R version 2.6.1 (2007-11-26) Windows XP (build 2600) Service Pack 2.0 Locale: LC_COLLATE=English_United States.1252;LC_CTYPE=English_United States.1252;LC_MONETARY=English_United States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252 Search Path: .GlobalEnv, package:glmpath, package:survival, package:splines, package:stats, package:graphics, package:grDevices, package:utils, package:datasets, package:methods, Autoloads, package:base __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] lm with factors for which only one level occurs
Consider the following: > lm(conc ~ Type, CO2, subset = Plant == "Quebec") Error in `contrasts<-`(`*tmp*`, value = "contr.treatment") : contrasts can be applied only to factors with 2 or more levels Here Type is a factor for which only one level occurs within the "Quebec" subset. This is something that one would think would be possible to handle in lm. (Note that singular.ok = TRUE is the default.) I came across this when automatically performing lm's on the levels of a conditioning variable, such as Plant in the above example, and found I had to unexpectedly special case situations like the above. lmList() in lme4 is likely adversely affected by this as well. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
