[Rd] base::as.Date inconsistency/bug
Dear all, I would like point out a potential bug (or at least inconsistency) in the way the R base package converts numeric numbers to dates. Specifically, consider the following two calls: > as.Date(0.5, origin="1969-12-31") [1] "1970-01-01" > as.Date(0.5, origin="1970-01-01") [1] "1970-01-01" As you can see, both calls produce the same output on the screen. Curiously, the output is NOT the same for other consecutive origins: > as.Date(0.5, origin="2009-12-31") [1] "2009-12-31" > as.Date(0.5, origin="2010-01-01") [1] "2010-01-01" Best regards, Andreas Eckner -- > sessionInfo() R version 2.11.0 (2010-04-22) i386-pc-mingw32 locale: [1] LC_COLLATE=English_United States.1252 LC_CTYPE=English_United States.1252 [3] LC_MONETARY=English_United States.1252 LC_NUMERIC=C [5] LC_TIME=English_United States.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] base::as.Date inconsistency/bug
Well, 2.11.0 is overdue for an update: see the posting guide.
You've confused the printed representation with the object. If there
is an issue, it is in the formatting (and hence printing) of
fractional dates before the epoch ("1970-01-01 00:00"). As the help
page says
It is intended that the date should be an integer, but this is not
enforced in the internal representation. Fractional days will be
ignored when printing.
and you've fallen foul of ignoring that warning. I think it does
actually work as documented, but it might confuse
non-readers-of-help-pages less if it always rounded to the previous
midnight, and R-patched now does that.
For your obsolete version of R, simply heed the warning and do not use
fractional days.
On Mon, 8 Nov 2010, Andreas Eckner wrote:
Dear all,
I would like point out a potential bug (or at least inconsistency) in the
way the R base package converts numeric numbers to dates. Specifically,
consider the following two calls:
as.Date(0.5, origin="1969-12-31")
[1] "1970-01-01"
as.Date(0.5, origin="1970-01-01")
[1] "1970-01-01"
As you can see, both calls produce the same output on the screen. Curiously,
the output is NOT the same for other consecutive origins:
as.Date(0.5, origin="2009-12-31")
[1] "2009-12-31"
as.Date(0.5, origin="2010-01-01")
[1] "2010-01-01"
Best regards,
Andreas Eckner
--
sessionInfo()
R version 2.11.0 (2010-04-22)
i386-pc-mingw32
locale:
[1] LC_COLLATE=English_United States.1252 LC_CTYPE=English_United
States.1252
[3] LC_MONETARY=English_United States.1252 LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, rip...@stats.ox.ac.uk
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] incorrect DLL path for Rbitmap.dll on Windows
On 08/11/2010 3:14 PM, Dan Tenenbaum wrote: Hello, I think there is a problem in recent devel builds of R on Windows with various devices from the grDevices package. This should be fixed now, as of today's build. Thanks for the report (and thanks to Brian Ripley for fixing it). Duncan Murdoch For example: > capabilities() jpeg png tifftcltk X11 aqua http/ftp sockets TRUE TRUE TRUE TRUEFALSEFALSE TRUE TRUE libxml fifo clediticonv NLS profmemcairo TRUEFALSE TRUE TRUE TRUE TRUEFALSE > jpeg() Error in jpeg() : unable to start jpeg() device In addition: Warning messages: 1: In jpeg() : Unable to load Rbitmap.dll 2: In jpeg() : opening device failed In the GUI version, a dialog appears saying: Unable to load 'C:\PROGRA~1\R\R-213~1.0DE\library\grDevices\libs\Rbitmap.dll' It seems that there should be an architecture folder (i386 or x64) after "libs", because that is where the dll is located. Same thing happens with png(), tiff(), etc. > sessionInfo() R version 2.13.0 Under development (unstable) (2010-11-07 r53537) Platform: i386-pc-mingw32/i386 (32-bit) locale: [1] LC_COLLATE=English_United States.1252 [2] LC_CTYPE=English_United States.1252 [3] LC_MONETARY=English_United States.1252 [4] LC_NUMERIC=C [5] LC_TIME=English_United States.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base Thanks! Dan [[alternative HTML version deleted]] __ 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] typo in ?eapply
Hi,
Found in ?eapply (in current R-devel):
\value{
A named (unless \code{USE.NAMES = FALSE}) list. Note that the order of
the components is arbitrary for hashed environments: currently it will
be in the order the name-value pairs were added for unhashed
hashed?
environments.
}
This looks like a typo.
Thanks,
H.
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M2-B876
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fhcrc.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
