[Rd] possible minor mis-spelling in "R Data Import/Export"
Good morning,
Could this be a mis-spelling in the development (revision 53854) and release
version of "R Data Import/Export" ?
Kind regards,
Sean O'Riordain
Dublin
un-affiliated...
svn diff r-devel/R/doc/manual/
Index: r-devel/R/doc/manual/R-data.texi
===
--- r-devel/R/doc/manual/R-data.texi(revision 53854)
+++ r-devel/R/doc/manual/R-data.texi(working copy)
@@ -1252,7 +1252,7 @@
object, and then a call to @code{dbConnect} opens a database connection
which can subsequently be closed by a call to the generic function
@code{dbDisconnect}. Use @code{dbDriver("Oracle")},
-...@code{dbddriver("PostgreSQL")} or @code{dbDriver("SQLite")} with those
+...@code{dbdriver("PostgreSQL")} or @code{dbDriver("SQLite")} with those
DBMSs and packages @pkg{ROracle}, @pkg{RPostgreSQL} or @pkg{RSQLite}
respectively.
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] postscript failure manifests in plot.TukeyHSD
On 10-12-16 12:09 AM, Jari Oksanen wrote: > On 16/12/10 04:24 AM, "Paul Murrell" wrote: > >> Hi >> >> According to the PostScript Language Reference Manual and the PDF >> Reference, in both PDF and PostScript ... >> >> ... a line width of zero is valid, but not recommended (and is clearly >> not supported by some viewers). >> >> ... a line dash pattern cannot be specified as all zero lengths. >> (So, because R generates the line dash pattern proportional to the line >> width, a specification of lwd=0 and >> lty=anything-other-than-"solid"-or-"none" does not make sense.) >> >> I think three fixes are required: >> >> (i) Enforce a minimum line width of 0.01 (mainly because that is not >> zero, but also because that is the smallest value greater than zero when >> you round to 2dp like the PDF and PostScript devices do and it's still >> REALLY thin). >> >> (ii) If the line dash pattern ends up as all zeroes (to 2dp), because >> the line width is so small (thin), force the dash pattern to "solid" >> instead. >> >> (iii) plot.TukeyHSD() should not use lwd=0 (0.5 is plenty difference to >> be obviously "lighter" than the main plot lines) >> >> I will commit these unless there are better suggestions or bitter >> objections. >> > Paul, > > The difference between working previous (of R 2.11.1) and failing > current-still-yesterday (R 2.12.1 RC) was: > > $ diff -U2 oldtukeyplot.ps /Volumes/TIKKU/tukeyplot.ps > --- oldtukeyplot.ps2010-12-14 12:06:07.0 +0200 > +++ /Volumes/TIKKU/tukeyplot.ps2010-12-14 12:13:32.0 +0200 > @@ -172,5 +172,5 @@ > 0 setgray > 0.00 setlinewidth > -[ 3.00 5.00] 0 setdash > +[ 0.00 0.00] 0 setdash > np > 660.06 91.44 m > > So 0.00 setlinewidth worked, but [0.00 0.00] 0 setdash failed. Assuming > PostScript is anything like English, it is the all-zero dash that caused the > failure. > > Cheers, Jari Oksanen Yes; I think Paul's fix #2 does this, and fixes #1 and #3 are trying to avoid problems in the future ... cheers Ben Bolker __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] 'libRblas.so' missing in R 2.12.1
Dear R developers, I just compiled the latest version of R (2.12.1) and noticed that 'libRblas.so' is missing in the '/x86_64/src/extra/blas' subdirectory of my R-installation. Did I miss ongoing discussions on the Mailinglist about this or might it be a local problem? Thanks for this brilliant software. Best Christian -- Christian Kohler Institute of Functional Genomics ~ Statistical Bioinformatics ~ University of Regensburg (BioPark I) D-93053 Regensburg (Germany) Tel. +49 941 943 5055 Fax +49 941 943 5020 christian.koh...@klinik.uni-regensburg.de __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] faster base::sequence
Hi Romain,
FWIW I see at least 2 small differences in the way sequence_c()
behaves with respect to good old sequence(): zeros and names.
> sequence(c(a=5, b=0, c=2))
a1 a2 a3 a4 a5 c1 c2
1 2 3 4 5 1 2
sequence_c() ignores the names and doesn't support zeros in the input.
Cheers,
H.
On 11/28/2010 01:56 AM, Romain Francois wrote:
Le 28/11/10 10:30, Prof Brian Ripley a écrit :
Is sequence used enough to warrant this? As the help page says
Note that ‘sequence <- function(nvec) unlist(lapply(nvec,
seq_len))’ and it mainly exists in reverence to the very early
history of R.
I don't know. Would it be used more if it were more efficient ?
I regard it as unsafe to assume that NA_INTEGER will always be negative,
and bear in mind that at some point not so far off R integers (or at
least lengths) will need to be more than 32-bit.
sure. updated and dressed up as a patch.
I've made it a .Call because I'm not really comfortable with .Internal,
etc ...
Do you mean that I should also use something else instead of "int" and
"int*". Is there some future proof typedef or macro for the type
associated with INTSXP ?
On Sun, 28 Nov 2010, Romain Francois wrote:
Hello,
Based on yesterday's R-help thread (help: program efficiency), and
following Bill's suggestions, it appeared that sequence:
sequence
function (nvec)
unlist(lapply(nvec, seq_len))
could benefit from being written in C to avoid unnecessary memory
allocations.
I made this version using inline:
require( inline )
sequence_c <- local( {
fx <- cfunction( signature( x = "integer"), '
int n = length(x) ;
int* px = INTEGER(x) ;
int x_i, s = 0 ;
/* error checking */
for( int i=0; i
x <- 1:1
system.time( a <- sequence(x ) )
utilisateur système écoulé
0.191 0.108 0.298
system.time( b <- sequence_c(x ) )
utilisateur système écoulé
0.060 0.063 0.122
identical( a, b )
[1] TRUE
system.time( for( i in 1:1) sequence(1:10) )
utilisateur système écoulé
0.119 0.000 0.119
system.time( for( i in 1:1) sequence_c(1:10) )
utilisateur système écoulé
0.019 0.000 0.019
I would write a proper patch if someone from R-core is willing to push
it.
Romain
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
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
