[Rd] Use of R and Rscript in configure/Makevars in packages
We have seen problems with a number of packages which use R/Rscript to
run R code in configure or makefiles.
(a) You must give a full path: there need be no version of R in the
path, and if there is it might not be the version/build of R under
which package installation is being done. So the general form is to
use
${R_HOME}/bin/R
to select the right version. And since ${R_HOME} might contain
spaces, you need something like ${R_HOME}/bin/R.
There appear to be bare uses of Rscript in Rcpp RQuantLib bifactorial
mvabund, of bare R in ROracle pgfSweave rcom and many more packages
without quotes.
(b) There are further issues with platforms which use
sub-architectures (mainly Mac OS X and R-devel Windows). On Windows
the architecture-dependent executables will (as from R 2.12.0) be in
subdirectories of ${R_HOME}/bin, so the general form is to use one of
${R_HOME}/bin${R_ARCH_BIN}/Rscript.exe
${R_HOME}/bin${R_ARCH_BIN}/Rterm.exe
${R_HOME}/bin${R_ARCH_BIN}/Rcmd.exe
On R-devel Windows ${R_HOME}/bin/R.exe and ${R_HOME}/bin/Rscript.exe
do exist and are 32-bit executables whose sole task is to launch the
appropriate executable from a sub-directory. Since process creation
is expensive on Windows, this intermediate step is best avoided.
On Mac OS X, ${R_HOME}/bin/R is a script that launches the
architecture-dependent executables from a subdirectory, and on CRAN
builds ${R_HOME}/bin/Rscript is a 'fat' (multi-arch) executable, so
the issues have been worked around (but not necessarily for user
installs).
(c) Calling R in configure.win will typically call 32-bit R with
R-devel Windows. If the result needs to depend on the architecture
(and e.g. the library dirs may well) then the work needs to be done in
src/Makevars.win: see the R-devel 'Writing R Extensions' manual for
how to achieve this.
(The reason is that configure.win is called once, and then
src/Makevars.win is called for each architecture.)
BDR
--
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] Use of R and Rscript in configure/Makevars in packages
Hello,
Thank you for these clear guidelines.
Given these subtleties, would it make sense to have a configure.R that
would win over configure and configure.win, and have R invoking it
correctly, as below ?
Romain
Le 20/05/10 08:51, Prof Brian Ripley a écrit :
We have seen problems with a number of packages which use R/Rscript to
run R code in configure or makefiles.
(a) You must give a full path: there need be no version of R in the
path, and if there is it might not be the version/build of R under which
package installation is being done. So the general form is to use
${R_HOME}/bin/R
to select the right version. And since ${R_HOME} might contain spaces,
you need something like ${R_HOME}/bin/R.
There appear to be bare uses of Rscript in Rcpp RQuantLib bifactorial
mvabund, of bare R in ROracle pgfSweave rcom and many more packages
without quotes.
(b) There are further issues with platforms which use sub-architectures
(mainly Mac OS X and R-devel Windows). On Windows the
architecture-dependent executables will (as from R 2.12.0) be in
subdirectories of ${R_HOME}/bin, so the general form is to use one of
${R_HOME}/bin${R_ARCH_BIN}/Rscript.exe
${R_HOME}/bin${R_ARCH_BIN}/Rterm.exe
${R_HOME}/bin${R_ARCH_BIN}/Rcmd.exe
On R-devel Windows ${R_HOME}/bin/R.exe and ${R_HOME}/bin/Rscript.exe do
exist and are 32-bit executables whose sole task is to launch the
appropriate executable from a sub-directory. Since process creation is
expensive on Windows, this intermediate step is best avoided.
On Mac OS X, ${R_HOME}/bin/R is a script that launches the
architecture-dependent executables from a subdirectory, and on CRAN
builds ${R_HOME}/bin/Rscript is a 'fat' (multi-arch) executable, so the
issues have been worked around (but not necessarily for user installs).
(c) Calling R in configure.win will typically call 32-bit R with R-devel
Windows. If the result needs to depend on the architecture (and e.g. the
library dirs may well) then the work needs to be done in
src/Makevars.win: see the R-devel 'Writing R Extensions' manual for how
to achieve this.
(The reason is that configure.win is called once, and then
src/Makevars.win is called for each architecture.)
BDR
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/bklUXt : RcppArmadillo 0.2.1
|- http://bit.ly/936ck2 : Rcpp 0.8.0
`- http://bit.ly/9aKDM9 : embed images in Rd documents
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] pretty.Date(): new halfmonth time step
Felix, I see your point about the halfway point acting like the first day of the month in its relativity to the ending date of the month: they're both variable. I'm an actuary. Like accountants, actuaries tend to measure financial time in months because of how the books close. But in our mathematical models time takes on a continuous nature. So our problem is how to build a computer representation of time that reflects both its continuous nature as well as the varying-length, discrete nature of financial months. I've found that a fixed value for a halfway point complicates actuarial calculations. It could serve other purposes just fine, however. Best regards, Dan On Wed, May 19, 2010 at 7:48 PM, Felix Andrews fe...@nfrac.org wrote: On 20 May 2010 11:56, Daniel Murphy chiefmur...@gmail.com wrote: Much better to implement directly what this is trying to do: i.e. to have a halfmonth time step. This is just the union of two monthly sequences, one on the 1st of each month and another on the 15th of each month. For some applications that might be true. But not for others. For a month with 31 days, there are 14 days before the 15th of the month and 16 days after the 15th, so, for example, March 16th (specifically noon) rather than March 15th would be the halfway point if you define halfway in terms of the distances to the beginning and end of the month. For a month with 30 days -- like April -- the halfway point would be the instant between the 15th and the 16th of the month. Do you label that instant April 15 or April 16? (I prefer 15.) Don't get me started on February. Dan, you are correct: the midpoint of a 30 day month is the 16th at 00:00. That instant is called the 16th according to print.POSIXt. junstart - as.POSIXct(2000-06-01 00:00, tz=GMT) julstart - as.POSIXct(2000-07-01 00:00, tz=GMT) junstart + ((julstart - junstart) / 2) #[1] 2000-06-16 GMT How embarassing... So I think it would be better to use 16 rather than 15 for the halfmonth time step. Yes, months have variable lengths, but I think it is best to use a consistent date (the 16th) than to calculate exact midpoints, just as a normal monthly series has a consistent date (the 1st) and has variable lengths. Regards -Felix - Dan Murphy [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Felix Andrews / å®ç¦ç« Postdoctoral Fellow Integrated Catchment Assessment and Management (iCAM) Centre Fenner School of Environment and Society [Bldg 48a] The Australian National University Canberra ACT 0200 Australia M: +61 410 400 963 T: + 61 2 6125 4670 E: felix.andr...@anu.edu.au CRICOS Provider No. 00120C -- http://www.neurofractal.org/felix/ [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Use of R and Rscript in configure/Makevars in packages
Le 20/05/10 09:40, Prof Brian Ripley a écrit :
On Thu, 20 May 2010, Romain Francois wrote:
Hello,
Thank you for these clear guidelines.
Given these subtleties, would it make sense to have a configure.R
that would win over configure and configure.win, and have R invoking
it correctly, as below ?
Only if someone in R-core volunteers to implement it, and this would not
solve the issue until R 2.12.0 and all the packages involved moved to it.
Sure. This leaves plently of time to test it then.
Reading the above literally, I will not work on a patch, but I can offer
my time to test it if someone in R-core does volunteer.
Romain
Romain
Le 20/05/10 08:51, Prof Brian Ripley a écrit :
We have seen problems with a number of packages which use R/Rscript to
run R code in configure or makefiles.
(a) You must give a full path: there need be no version of R in the
path, and if there is it might not be the version/build of R under which
package installation is being done. So the general form is to use
${R_HOME}/bin/R
to select the right version. And since ${R_HOME} might contain spaces,
you need something like ${R_HOME}/bin/R.
There appear to be bare uses of Rscript in Rcpp RQuantLib bifactorial
mvabund, of bare R in ROracle pgfSweave rcom and many more packages
without quotes.
(b) There are further issues with platforms which use sub-architectures
(mainly Mac OS X and R-devel Windows). On Windows the
architecture-dependent executables will (as from R 2.12.0) be in
subdirectories of ${R_HOME}/bin, so the general form is to use one of
${R_HOME}/bin${R_ARCH_BIN}/Rscript.exe
${R_HOME}/bin${R_ARCH_BIN}/Rterm.exe
${R_HOME}/bin${R_ARCH_BIN}/Rcmd.exe
On R-devel Windows ${R_HOME}/bin/R.exe and ${R_HOME}/bin/Rscript.exe do
exist and are 32-bit executables whose sole task is to launch the
appropriate executable from a sub-directory. Since process creation is
expensive on Windows, this intermediate step is best avoided.
On Mac OS X, ${R_HOME}/bin/R is a script that launches the
architecture-dependent executables from a subdirectory, and on CRAN
builds ${R_HOME}/bin/Rscript is a 'fat' (multi-arch) executable, so the
issues have been worked around (but not necessarily for user installs).
(c) Calling R in configure.win will typically call 32-bit R with R-devel
Windows. If the result needs to depend on the architecture (and e.g. the
library dirs may well) then the work needs to be done in
src/Makevars.win: see the R-devel 'Writing R Extensions' manual for how
to achieve this.
(The reason is that configure.win is called once, and then
src/Makevars.win is called for each architecture.)
BDR
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/bklUXt : RcppArmadillo 0.2.1
|- http://bit.ly/936ck2 : Rcpp 0.8.0
`- http://bit.ly/9aKDM9 : embed images in Rd documents
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/bklUXt : RcppArmadillo 0.2.1
|- http://bit.ly/936ck2 : Rcpp 0.8.0
`- http://bit.ly/9aKDM9 : embed images in Rd documents
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] pretty.Date(): new halfmonth time step
Note that in the zoo package that as.Date.yearmon has a frac= argument, e.g. library(zoo) ym - as.yearmon(2010-01) as.Date(ym, frac = 0.5) [1] 2010-01-16 On Wed, May 19, 2010 at 9:56 PM, Daniel Murphy chiefmur...@gmail.com wrote: Much better to implement directly what this is trying to do: i.e. to have a halfmonth time step. This is just the union of two monthly sequences, one on the 1st of each month and another on the 15th of each month. For some applications that might be true. But not for others. For a month with 31 days, there are 14 days before the 15th of the month and 16 days after the 15th, so, for example, March 16th (specifically noon) rather than March 15th would be the halfway point if you define halfway in terms of the distances to the beginning and end of the month. For a month with 30 days -- like April -- the halfway point would be the instant between the 15th and the 16th of the month. Do you label that instant April 15 or April 16? (I prefer 15.) Don't get me started on February. - Dan Murphy [[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
Re: [Rd] pretty.Date(): new halfmonth time step
I see, an interesting perspective. The current purpose is just to look pretty, or to follow the principle of least surprise, which is difficult to the extent that it is subjective and sometimes context dependent... Cheers -Felix On 20 May 2010 17:38, Daniel Murphy chiefmur...@gmail.com wrote: Felix, I see your point about the halfway point acting like the first day of the month in its relativity to the ending date of the month: they're both variable. I'm an actuary. Like accountants, actuaries tend to measure financial time in months because of how the books close. But in our mathematical models time takes on a continuous nature. So our problem is how to build a computer representation of time that reflects both its continuous nature as well as the varying-length, discrete nature of financial months. I've found that a fixed value for a halfway point complicates actuarial calculations. It could serve other purposes just fine, however. Best regards, Dan On Wed, May 19, 2010 at 7:48 PM, Felix Andrews fe...@nfrac.org wrote: On 20 May 2010 11:56, Daniel Murphy chiefmur...@gmail.com wrote: Much better to implement directly what this is trying to do: i.e. to have a halfmonth time step. This is just the union of two monthly sequences, one on the 1st of each month and another on the 15th of each month. For some applications that might be true. But not for others. For a month with 31 days, there are 14 days before the 15th of the month and 16 days after the 15th, so, for example, March 16th (specifically noon) rather than March 15th would be the halfway point if you define halfway in terms of the distances to the beginning and end of the month. For a month with 30 days -- like April -- the halfway point would be the instant between the 15th and the 16th of the month. Do you label that instant April 15 or April 16? (I prefer 15.) Don't get me started on February. Dan, you are correct: the midpoint of a 30 day month is the 16th at 00:00. That instant is called the 16th according to print.POSIXt. junstart - as.POSIXct(2000-06-01 00:00, tz=GMT) julstart - as.POSIXct(2000-07-01 00:00, tz=GMT) junstart + ((julstart - junstart) / 2) #[1] 2000-06-16 GMT How embarassing... So I think it would be better to use 16 rather than 15 for the halfmonth time step. Yes, months have variable lengths, but I think it is best to use a consistent date (the 16th) than to calculate exact midpoints, just as a normal monthly series has a consistent date (the 1st) and has variable lengths. Regards -Felix - Dan Murphy [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Felix Andrews / 安福立 Postdoctoral Fellow Integrated Catchment Assessment and Management (iCAM) Centre Fenner School of Environment and Society [Bldg 48a] The Australian National University Canberra ACT 0200 Australia M: +61 410 400 963 T: + 61 2 6125 4670 E: felix.andr...@anu.edu.au CRICOS Provider No. 00120C -- http://www.neurofractal.org/felix/ -- Felix Andrews / 安福立 Postdoctoral Fellow Integrated Catchment Assessment and Management (iCAM) Centre Fenner School of Environment and Society [Bldg 48a] The Australian National University Canberra ACT 0200 Australia M: +61 410 400 963 T: + 61 2 6125 4670 E: felix.andr...@anu.edu.au CRICOS Provider No. 00120C -- http://www.neurofractal.org/felix/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Build R static
Does anyone know if it's possible to create a static build of R?
Thanks,
From: Alex Bryant
Sent: Monday, May 10, 2010 2:50 PM
To: 'r-devel@r-project.org'
Subject: Build R static
Hi, I am having trouble building R static on Solaris 5.10. I have a
requirement to run R within a specific user account on Solaris 5.10 and I do
not have access to compilers and or shared libraries on the target machine. I
thought I could build R static ( I've build it locally on Solaris with shared
libraries) and just ftp the build to the target Solaris box. Can any help with
what ./configure Make flags need to be set for this, assuming it is possible?
Here is what my currently built ./bin/exec/R executable is using.
$ ldd R
libRblas.so = (file not found)
libg2c.so.0 = /usr/local/lib/libg2c.so.0
libm.so.2 = /usr/lib/libm.so.2
libreadline.so.6 = /usr/local/lib/libreadline.so.6
libcurses.so.1 =/usr/lib/libcurses.so.1
libnsl.so.1 = /usr/lib/libnsl.so.1
libsocket.so.1 =/usr/lib/libsocket.so.1
libdl.so.1 =/usr/lib/libdl.so.1
libiconv.so.2 = /usr/local/lib/libiconv.so.2
libicuuc.so.3 = /usr/lib/libicuuc.so.3
libicui18n.so.3 = /usr/lib/libicui18n.so.3
libc.so.1 = /usr/lib/libc.so.1
libgcc_s.so.1 = /usr/local/lib/libgcc_s.so.1
libmp.so.2 =/usr/lib/libmp.so.2
libmd5.so.1 = /usr/lib/libmd5.so.1
libscf.so.1 = /usr/lib/libscf.so.1
libicudata.so.3 = /usr/lib/libicudata.so.3
libpthread.so.1 = /usr/lib/libpthread.so.1
libCrun.so.1 = /usr/lib/libCrun.so.1
libdoor.so.1 = /usr/lib/libdoor.so.1
libuutil.so.1 = /usr/lib/libuutil.so.1
/platform/SUNW,Sun-Fire-280R/lib/libc_psr.so.1
/platform/SUNW,Sun-Fire-280R/lib/libmd5_psr.so.1
Thanks for your help,
Alex
//
// Alex Bryant
// Software Developer
// Integrated Clinical Systems, Inc.
// 908-996-7208
Confidentiality Note: This e-mail, and any attachment to...{{dropped:13}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] pretty.Date(): new halfmonth time step
Yes. I looked at that feature of zoo. But it forced me to keep track of fractional months in the Date world. Square one. I ended up implementing a class under the paradigm of whole and fractional months. It allows me to do all my time arithmetic in ways that accountants expect. For example, accountants think of the close of business June 30th as being the halfway point of the year, but it's certainly not half the year as the crow flies. -Dan On Thu, May 20, 2010 at 4:01 AM, Gabor Grothendieck ggrothendi...@gmail.com wrote: Note that in the zoo package that as.Date.yearmon has a frac= argument, e.g. library(zoo) ym - as.yearmon(2010-01) as.Date(ym, frac = 0.5) [1] 2010-01-16 On Wed, May 19, 2010 at 9:56 PM, Daniel Murphy chiefmur...@gmail.com wrote: Much better to implement directly what this is trying to do: i.e. to have a halfmonth time step. This is just the union of two monthly sequences, one on the 1st of each month and another on the 15th of each month. For some applications that might be true. But not for others. For a month with 31 days, there are 14 days before the 15th of the month and 16 days after the 15th, so, for example, March 16th (specifically noon) rather than March 15th would be the halfway point if you define halfway in terms of the distances to the beginning and end of the month. For a month with 30 days -- like April -- the halfway point would be the instant between the 15th and the 16th of the month. Do you label that instant April 15 or April 16? (I prefer 15.) Don't get me started on February. - Dan Murphy [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Suggestion: Add DESCRIPTION/NEWS files to the Rtools compilations
Hi, I'd like to suggest that DESCRIPTION and/or NEWS files, or other information revealing the version, would be added to the different Rtools compilations (http://www.murdoch-sutherland.com/Rtools/). Currently it's not easy to figure out which version is installed. Another suggestion is to have Rtools install in different subdirectories depending on version, much like how R is installed into different directories, e.g. C:/Rtools-2.10/ and C:/Rtools-2.11dev/. That would make it easier to setup one tool chain for R release and one for R devel. BTW, is there a reason (e.g. spaces in paths) for not installing Rtools in %ProgramFiles%/R/, where R is installed? Is it safe to have it there? Thanks for putting Rtools together Henrik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Build R static
On May 20, 2010, at 8:50 AM, Alex Bryant wrote:
Does anyone know if it's possible to create a static build of R?
That depends heavily on the OS and tools used and has nothing to do with R
itself. You'll need static versions of all libraries you depend on and
compilers capable of using them (=and having static libs themselves). In
addition, packages are shared libraries in R so all static libraries that can
be potentially used need to be PIC-safe (which is normally not the case).
That said, your motivation doesn't seem to be relevant here, because you can
simply ship dynamic libraries with R which is much easier and more efficient
(since you won't be copying them over and over for each binary and package).
The usual motivation for a purely static binary is to ship it as one file but
since that's not possible with R (it needs packages etc.) you don't gain
anything at all.
Cheers,
Simon
Thanks,
From: Alex Bryant
Sent: Monday, May 10, 2010 2:50 PM
To: 'r-devel@r-project.org'
Subject: Build R static
Hi, I am having trouble building R static on Solaris 5.10. I have a
requirement to run R within a specific user account on Solaris 5.10 and I do
not have access to compilers and or shared libraries on the target machine.
I thought I could build R static ( I've build it locally on Solaris with
shared libraries) and just ftp the build to the target Solaris box. Can any
help with what ./configure Make flags need to be set for this, assuming it
is possible?
Here is what my currently built ./bin/exec/R executable is using.
$ ldd R
libRblas.so = (file not found)
libg2c.so.0 = /usr/local/lib/libg2c.so.0
libm.so.2 = /usr/lib/libm.so.2
libreadline.so.6 = /usr/local/lib/libreadline.so.6
libcurses.so.1 =/usr/lib/libcurses.so.1
libnsl.so.1 = /usr/lib/libnsl.so.1
libsocket.so.1 =/usr/lib/libsocket.so.1
libdl.so.1 =/usr/lib/libdl.so.1
libiconv.so.2 = /usr/local/lib/libiconv.so.2
libicuuc.so.3 = /usr/lib/libicuuc.so.3
libicui18n.so.3 = /usr/lib/libicui18n.so.3
libc.so.1 = /usr/lib/libc.so.1
libgcc_s.so.1 = /usr/local/lib/libgcc_s.so.1
libmp.so.2 =/usr/lib/libmp.so.2
libmd5.so.1 = /usr/lib/libmd5.so.1
libscf.so.1 = /usr/lib/libscf.so.1
libicudata.so.3 = /usr/lib/libicudata.so.3
libpthread.so.1 = /usr/lib/libpthread.so.1
libCrun.so.1 = /usr/lib/libCrun.so.1
libdoor.so.1 = /usr/lib/libdoor.so.1
libuutil.so.1 = /usr/lib/libuutil.so.1
/platform/SUNW,Sun-Fire-280R/lib/libc_psr.so.1
/platform/SUNW,Sun-Fire-280R/lib/libmd5_psr.so.1
Thanks for your help,
Alex
//
// Alex Bryant
// Software Developer
// Integrated Clinical Systems, Inc.
// 908-996-7208
Confidentiality Note: This e-mail, and any attachment to...{{dropped:13}}
__
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 in sandbox/jail (long question)
On Tue, May 18, 2010 at 7:38 PM, Assaf Gordon assafgor...@gmail.com wrote: I've found this old thread: http://r.789695.n4.nabble.com/R-in-a-sandbox-jail-td921991.html But for technical reasons I'd prefer not to setup a chroot jail. I would also point out that the state of the art in the operating system community has moved on significantly since 1982 when chroot was added. BSD Jails, Solaris Zones/Containers, SELinux, etc. all provide much more control over the system calls, network connections, and file and device access granted to applications in different jails/zones. These operating system capabilities solve exactly some of the problems you are trying to solve by painstakingly modifying R, but in a more secure and configurable manner. - Murray __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] pretty.Date(): changes to axis() methods?
Hi all.
pretty() is now generic in R-2.12 and there are new methods for Date
and POSIXt classes. These methods could potentially be used inside
axis.Date and axis.POSIXt (and Axis methods), although that has not
been decided yet.
The main advantage of the new method is that it is flexible, in the
sense that users can specify the desired number of ticks on an axis.
(e.g. one could easily draw, say, labelled ticks with n = 5, and then
sub-ticks with n = 15). Of course one can do this manually but
it is not so convenient.
[[ On this issue: I don't use base graphics much, but given how
awkward it is to specify par(xaxp) / par(yaxp), perhaps a new
axis.Date() should gain arguments 'n' and 'min.n' to pass on to
pretty(). Example given below. ]]
The current version of pretty.Date / pretty.POSIXt gives different
results in some cases to axis.Date / axis.POSIXt: the format strings
for time steps of 1 day, 12 hours and 6 hours are different; and some
different time steps are allowed, such as 10 minutes, 3 hours, 3
months... the full list of possible time steps and their current
default format strings is listed at:
http://svn.r-project.org/R/trunk/src/library/grDevices/R/prettyDate.R
The current axis.Date / axis.POSIXt code, including format strings, is
http://svn.r-project.org/R/trunk/src/library/graphics/R/datetime.R
These settings reflect my personal choices, but are somewhat
arbitrary. I would encourage R-core to make this function their own,
by choosing default format strings and time steps with which they are
comfortable. It could be made more similar to the current axis
methods. E.g. it wouldn't much bother me to remove the 15 mins time
steps altogether, and a 20 mins time step could be added.
Here is an example of changing the number of requested ticks on an
axis: (this example does not depend on R 2.12)
source(http://svn.r-project.org/R/trunk/src/library/grDevices/R/prettyDate.R;)
times - as.Date(c(2000-04-02, 2000-06-02))
devAskNewPage(TRUE)
lapply(c(2,4,6,8,10,20,60), function(n) {
plot(0:1 ~ times, type = n, yaxt = n, ylab = )
x - par(usr)[1:2]
text(x[1], 0.5, format(times[1]), pos = 4)
text(x[2], 0.5, format(times[2]), pos = 2)
text(mean(x), 0.05, current axis.Date())
text(mean(x), 0.95, proposed new pretty() axis, with)
text(mean(x), 0.85, paste(n =, n), cex = 1.5)
## draw new proposed axis function at top of plot
timelim - par(usr)[1:2]
mostattributes(timelim) - attributes(times)
at - prettyDate(timelim, n = n)
axis(side = 3, at = at, labels = attr(at, labels))
})
Here is a posible modification to axis.Date. As it calls pretty(), it
will only work in R 2.12.
axis.Date - function(side, x = NA, at, format, labels = TRUE, n = NULL, ...)
{
mat - missing(at) || is.null(at)
if(!mat) x - as.Date(at) else x - as.Date(x)
range - par(usr)[if(side %%2) 1L:2L else 3:4L]
range[1L] - ceiling(range[1L])
range[2L] - floor(range[2L])
class(range) - Date
## not sure why we need this (from axis.Date):
z - c(range, x[is.finite(x)])
class(z) - Date
if (!mat) {
## tick mark locations given
z - x[is.finite(x)]
if (missing(format)) format -
} else {
## calculate about 'n' pretty intervals
if (is.null(n)) {
is.x - side %% 2 == 1
axp - par(if (is.x) xaxp else yaxp)
n - abs(axp[3L])
}
z - pretty(z, n = n)
if (missing(format) identical(labels, TRUE))
labels - attr(z, labels)
}
keep - z = range[1L] z = range[2L]
z - z[keep]
z - sort(unique(z)); class(z) - Date
if (!is.logical(labels)) labels - labels[keep]
else if (identical(labels, TRUE))
labels - format.Date(z, format = format)
else if (identical(labels, FALSE))
labels - rep(, length(z)) # suppress labelling of ticks
axis(side, at = z, labels = labels, ...)
}
Whether to modify axis() methods is up to R-core of course, but I
thought it was worth discussing.
By the way, this new functionality is already included in lattice
0.18-5, which was released with, and depends on, R 2.11.0. (There is
one known issue: the Date method in lattice 0.18-5 can miss a tick at
one end of the axis if your local time zone is not GMT. Also that
version does not include the new halfmonth time step.)
-Felix
--
Felix Andrews / 安福立
Postdoctoral Fellow
Integrated Catchment Assessment and Management (iCAM) Centre
Fenner School of Environment and Society [Bldg 48a]
The Australian National University
Canberra ACT 0200 Australia
M: +61 410 400 963
T: + 61 2 6125 4670
E: felix.andr...@anu.edu.au
CRICOS Provider No. 00120C
--
http://www.neurofractal.org/felix/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
