Re: [Rd] POSIX time anomaly (PR#7317)
This is intentional: why did you send a bug report? Please read the
section on BUGS in the FAQ and tell us how this contradicts the
documentation.
If you want a particular output format, you need to specify it:
x <- strptime("10/5/2004 00:00:00 CDT", "%m/%d/%Y %H:%M:%S %Z")
format(x, "%Y-%m-%d %H:%M:%S")
[1] "2004-10-05 00:00:00"
but print() is allowed to suppress 0's. Did you bother to read the code:
> format.POSIXlt
function (x, format = "", usetz = FALSE, ...)
{
if (!inherits(x, "POSIXlt"))
stop("wrong class")
if (format == "") {
times <- unlist(unclass(x)[1:3])
format <- if (all(times[!is.na(times)] == 0))
"%Y-%m-%d"
else "%Y-%m-%d %H:%M:%S"
}
.Internal(format.POSIXlt(x, format, usetz))
}
?
On Thu, 28 Oct 2004 [EMAIL PROTECTED] wrote:
> Full_Name: Allen McIntosh
> Version: 2.0.0
> OS: RedHat 9.0
> Submission from: (NULL) (67.80.175.118)
>
>
> The POSIX time printing routine gives strange results when asked to print a time
> that is exactly midnight:
>
> TZ=CST6CDT R -q --no-save
> > strptime("10/5/2004 00:00:01 CDT", "%m/%d/%Y %H:%M:%S %Z")
> [1] "2004-10-05 00:00:01"
> > strptime("10/5/2004 00:00:00 CDT", "%m/%d/%Y %H:%M:%S %Z")
> [1] "2004-10-05"
> > strptime("10/4/2004 24:00:00 CDT", "%m/%d/%Y %H:%M:%S %Z")
> [1] NA
>
> The first time is OK. The second is missing the HH:MM:SS.
> I'm OK with the last one being NA,
We don't need your permission: this is as documented.
> just did it to see if that was the way that
> the code wanted midnight.
>
> Get the underlying # seconds:
>
> > zz <- as.POSIXct(strptime("10/5/2004 00:00:00 CDT", "%m/%d/%Y %H:%M:%S %Z"))
> > attr(zz,"class") <- NULL
> > zz
> [1] 1096952400
> attr(,"tzone")
> [1] ""
> >
>
> and (just to see if the problem is glibc or something):
> $ cat ct.c
> #include
> #include
> main() {
> time_t z = 1096952400;
> printf("%s\n", ctime(&z));
> return 0;
> }
> $ gcc -o ct ct.c
> $ TZ=CST6CDT ./ct
> Tue Oct 5 00:00:00 2004
What has ctime() to do with this?
> This problem also observed with R 1.6.0 and R 1.8.1 (RedHat 7.3)
> The timezone doesn't seem to matter - this is just the first date that tripped
> over this problem.
--
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
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] POSIX time anomaly (PR#7317)
Full_Name: Allen McIntosh
Version: 2.0.0
OS: RedHat 9.0
Submission from: (NULL) (67.80.175.118)
The POSIX time printing routine gives strange results when asked to print a time
that is exactly midnight:
TZ=CST6CDT R -q --no-save
> strptime("10/5/2004 00:00:01 CDT", "%m/%d/%Y %H:%M:%S %Z")
[1] "2004-10-05 00:00:01"
> strptime("10/5/2004 00:00:00 CDT", "%m/%d/%Y %H:%M:%S %Z")
[1] "2004-10-05"
> strptime("10/4/2004 24:00:00 CDT", "%m/%d/%Y %H:%M:%S %Z")
[1] NA
The first time is OK. The second is missing the HH:MM:SS.
I'm OK with the last one being NA, just did it to see if that was the way that
the code wanted midnight.
Get the underlying # seconds:
> zz <- as.POSIXct(strptime("10/5/2004 00:00:00 CDT", "%m/%d/%Y %H:%M:%S %Z"))
> attr(zz,"class") <- NULL
> zz
[1] 1096952400
attr(,"tzone")
[1] ""
>
and (just to see if the problem is glibc or something):
$ cat ct.c
#include
#include
main() {
time_t z = 1096952400;
printf("%s\n", ctime(&z));
return 0;
}
$ gcc -o ct ct.c
$ TZ=CST6CDT ./ct
Tue Oct 5 00:00:00 2004
This problem also observed with R 1.6.0 and R 1.8.1 (RedHat 7.3)
The timezone doesn't seem to matter - this is just the first date that tripped
over this problem.
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Another problem with next method
Gabor Grothendieck myway.com> writes:
:
: I have another problem with NextMethod. Not sure if its related
: to the last problem.
:
: In this example, we have a generic called ff with methods
: for AsIs and test classes. We call the generic with an
: object of AsIs class. The corresponding method adds 1 to it
: and then changes the class to test followed by issuing a
: NextMethod. However, that results in this error (using R
: 2.0.0, 2004-10-04 Windows XP):
:
: Error in NextMethod("ff") : No method to invoke
:
: Why can't NextMethod find ff.test ?
:
: I also tried a number of variations of this including adding x = x
: to the NExtMethod argument list but none of these variations worked.
:
: ---
:
: ff <- function(x, ...) UseMethod("ff")
: ff.AsIs <- function(x, ...) {
: x <- x + 1
: class(x) <- "test"
: NextMethod("ff")
: }
: ff.test <- function(x, ...) cat(x, class(x), ..., "\n")
: ff(I(3))
Just in case there is some doubt the following example is almost
identical to the one on page 74 of the Writing Extensions manual
and gives the same error message cited above:
ff <- function(x) UseMethod("ff")
ff.data.frame <- function(x)
{
x <- as.matrix(x)
NextMethod("ff")
}
ff.matrix <- function(x) dim(x)
data(iris)
ff(iris)
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Another problem with next method
I have another problem with NextMethod. Not sure if its related
to the last problem.
In this example, we have a generic called ff with methods
for AsIs and test classes. We call the generic with an
object of AsIs class. The corresponding method adds 1 to it
and then changes the class to test followed by issuing a
NextMethod. However, that results in this error (using R
2.0.0, 2004-10-04 Windows XP):
Error in NextMethod("ff") : No method to invoke
Why can't NextMethod find ff.test ?
I also tried a number of variations of this including adding x = x
to the NExtMethod argument list but none of these variations worked.
---
ff <- function(x, ...) UseMethod("ff")
ff.AsIs <- function(x, ...) {
x <- x + 1
class(x) <- "test"
NextMethod("ff")
}
ff.test <- function(x, ...) cat(x, class(x), ..., "\n")
ff(I(3))
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] errors compiling R-2.0.0
Hi. I get exactly the same error when installing R v2.0.0 on Sun Solaris 9
(also as root). R has been installing perfectly fine since at least R v1.4.1
on the same machine. Unfortunately, I haven't got around to troubleshoot
much, but now I at least know that it's not just our Sun Solaris system that
is the problem.
Regards,
Henrik Bengtsson
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> [EMAIL PROTECTED]
> Sent: Wednesday, October 27, 2004 10:13 PM
> To: [EMAIL PROTECTED]
> Subject: [Rd] errors compiling R-2.0.0
>
>
> Dear R-devel,
>
> I have been trying to compile R-2.0.0 on under linux, with the usual
>
> ./configure
> make
>
> I get the errors
>
> Warning message:
> package seems to be using lazy loading already in:
> makeLazyLoading("tools")
> Error in get(x, envir, mode, inherits) : variable
> ".install_package_description" was not found
> Execution halted
>
> This same configuration of linux successfully installed and
> runs R-1.9.1.
>
> Any suggestions for where to look for problems? I noticed
> that someone
> experienced similar problem under Windows.
>
> thanks,
>
> Clayton
> [[alternative HTML version deleted]]
>
> __
> [EMAIL PROTECTED] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] errors compiling R-2.0.0
Dear R-devel,
I have been trying to compile R-2.0.0 on under linux, with the usual
./configure
make
I get the errors
Warning message:
package seems to be using lazy loading already in:
makeLazyLoading("tools")
Error in get(x, envir, mode, inherits) : variable
".install_package_description" was not found
Execution halted
This same configuration of linux successfully installed and runs R-1.9.1.
Any suggestions for where to look for problems? I noticed that someone
experienced similar problem under Windows.
thanks,
Clayton
[[alternative HTML version deleted]]
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] wish - cor.test output order change (PR#7315)
Full_Name: Rob Baer Version: 2.0.0 OS: Windows Submission from: (NULL) (198.209.172.106) Request/wish summary: state the alternative hypothesis before the t-test and p-value A typical cor.test output looks like the following: > x=runif(30)*10 > y=runif(30)*10 > cor.test(x,y) Pearson's product-moment correlation data: x and y t = 0.6161, df = 28, p-value = 0.5428 alternative hypothesis: true correlation is not equal to 0 95 percent confidence interval: -0.2552588 0.4568795 sample estimates: cor 0.1156454 -- Rationale I have the recurring problem of students misinterpreting the alternative hypothesis statement as an interpretation of the t-test p-value not as a "tail decision". The "quick students" think R has made a mistake. The "slow students" (please save me) accept the alternative hypothesis with huge p-values "because the program told them to". All students seem confused. If this had affected a single group of students, I'd let it go, but this is a recurring theme with each new crop. Proposed fix. Generaly, we decide on an alternative hypothesis (or should) as an a priori statement. I think that there would be MUCH LESS confusing if the printed hypothesis statement came BEFORE the t-test and p-value output. This should put it in conceptual sequence; it would not be so easily confused with an interpretation. This same problem happens in some other test output as well. For these, a similar order change could greatly reduce confusion about what is being stated. If the output code is shared, the fix would only have to be done once. Thanks for considering it. __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NextMethod ignoring changed argument
Uwe Ligges <[EMAIL PROTECTED]> wrote:
:
: Gabor Grothendieck wrote:
:
: >
: > Is this a bug? We define the [ operator for class test.
: > All it does is force drop to be FALSE and then calls
: > the NextMethod. If we specify drop= in the call then
: > it works as expected (### 2 and ### 3) but if we do not
: > specify drop (### 1) then it acts as if drop=TRUE
: > even though we have set it to FALSE within [.test .
: >
: >
: >>"[.test" <- function(x, i, j, drop = TRUE) {
: >
: > + drop <- FALSE
: > + NextMethod("[")
: > + }
: >
: >>x <- structure(matrix(1:12, 4, 3), class = "test")
: >
: >
: >>x[1,] ### 1 - why does it ignore drop=FALSE in [.test
: >
: > [1] 1 5 9
: >
: >
: >>x[1,,drop = TRUE] ### 2 - ok
: >
: > [,1] [,2] [,3]
: > [1,] 1 5 9
: >
: >>x[1,,drop = FALSE] ### 3 - ok
: >
: > [,1] [,2] [,3]
: > [1,] 1 5 9
: >
: >>R.version.string # windows XP
: >
: > [1] "R version 2.0.0, 2004-10-04"
: >
:
:
: Well, the *arguments* of the encolsing function are taken, but not the
: objects defined therein. What you can do is:
:
: "[.test" <- function(x, i, j, drop = TRUE) {
: NextMethod("[", drop = FALSE)
: }
:
: Uwe Ligges
Thanks. That worked. Is that a workaround or is it a bug?
Note that if I set both i and drop within the [.test method then
the modified i gets passed but the modified drop does not:
R> "[.test" <- function(x, i, j, drop = TRUE) {
+ i <- 2; drop <- FALSE
+ NextMethod("[")
+ }
R> x <- structure(matrix(1:12, 4, 3), class = "test")
R> x[1,]
[1] 2 6 10
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] rhyper has too high variance (PR#7314)
[EMAIL PROTECTED] writes:
> On Tue, 26 Oct 2004 13:38:21 +0200 (CEST), [EMAIL PROTECTED] wrote :
>
> >
> >Dear all,
> >
> >it looks like rhyper() gives wrong results compared to theory and compared
> >to sample() and rghyper(SuppDists).
>
> I agree, these results look wrong. The mean also seems high:
Yup, and inconsistent with phyper and dhyper (which is a good thing I
suppose)
> mean(rhyper(1e5,100,60,50))
[1] 31.47707
> sum(phyper(0:50,100,60,50,lower=F))
[1] 31.25
> sum(0:50*dhyper(0:50,100,60,50))
[1] 31.25
Looks like the effect is not due to the choice of random number
generator:
> RNGkind("Super-Duper")
> mean(rhyper(1e5,100,60,50))
[1] 31.45755
--
O__ Peter Dalgaard Blegdamsvej 3
c/ /'_ --- Dept. of Biostatistics 2200 Cph. N
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Re: [R] persp(), scatterplot3d(), "..." argument
Jari Oksanen wrote:
On Wed, 2004-10-27 at 11:11, Uwe Ligges wrote:
Jari Oksanen wrote:
On Wed, 2004-10-27 at 10:04, Uwe Ligges wrote:
This is a larger problem if
1. one of the underlying functions does not have "..."
2. you want to relay arguments to two or more underlying functions, and
3. you don't want to list all possible arguments in your function
definition, since it is long enough already.
The solution is still there, but it is (black) magic. For instance,
'arrows' does not have "...", so you must add them with this magical
mystery string:
formals(arrows) <- c(formals(arrows), alist(... = ))
You don't need it for simple things like:
foo <- function(...){
plot(1:10)
arrows(1,1,7,7,...)
}
foo(lwd=5) # works!
That's why I had point 2 above: it really would work with simpler
things. However, the following may fail:
parrow <-
function (x, y, ...)
{
plot(x, y, ...)
arrows(0, 0, x, y, ...)
invisible()
}
parrow(runif(10), runif(10), col="red") # works
parrow(runif(10), runif(10), col="red", pch=16)
Error in arrows(0, 0, x, y, ...) : unused argument(s) (pch ...)
Adding formals would help.
As always, useful patches are welcome.
I don't know if this counts as a "useful patch", but it is patch anyway:
diff -u2r old/arrows.R new/arrows.R
--- old/arrows.R2004-10-27 11:32:25.0 +0300
+++ new/arrows.R2004-10-27 11:32:53.0 +0300
@@ -1,5 +1,5 @@
"arrows" <-
function (x0, y0, x1, y1, length = 0.25, angle = 30, code = 2,
-col = par("fg"), lty = NULL, lwd = par("lwd"), xpd = NULL)
+col = par("fg"), lty = NULL, lwd = par("lwd"), xpd = NULL, ...)
{
.Internal(arrows(x0, y0, x1, y1, length = length, angle = angle,
[moved to r-devel!]
At least a patch for the docs is missing (pointing out that passing args
through "..." won't have any effect) - and depending on what R-core
thinks about this issue.
Uwe Ligges
cheers, jari oksanen
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NextMethod ignoring changed argument
Gabor Grothendieck wrote:
Is this a bug? We define the [ operator for class test.
All it does is force drop to be FALSE and then calls
the NextMethod. If we specify drop= in the call then
it works as expected (### 2 and ### 3) but if we do not
specify drop (### 1) then it acts as if drop=TRUE
even though we have set it to FALSE within [.test .
"[.test" <- function(x, i, j, drop = TRUE) {
+ drop <- FALSE
+ NextMethod("[")
+ }
x <- structure(matrix(1:12, 4, 3), class = "test")
x[1,] ### 1 - why does it ignore drop=FALSE in [.test
[1] 1 5 9
x[1,,drop = TRUE] ### 2 - ok
[,1] [,2] [,3]
[1,]159
x[1,,drop = FALSE] ### 3 - ok
[,1] [,2] [,3]
[1,]159
R.version.string # windows XP
[1] "R version 2.0.0, 2004-10-04"
Well, the *arguments* of the encolsing function are taken, but not the
objects defined therein. What you can do is:
"[.test" <- function(x, i, j, drop = TRUE) {
NextMethod("[", drop = FALSE)
}
Uwe Ligges
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
