Re: [Rd] bug in by.data.frame, R-2.6.1 (PR#10506)
It transpires that package survey relies on the current behaviour (which is not new in 2.6.1: R 2.0.0 did it). The suggested fix is reasonable if 'data' was originally a data frame, but the default method promotes vectors to data frames, and the data frame method used to drop them back to vectors. I've backed the fix out of R-patched. I am not sure if the current undocumented behaviour on vectors is 100% desirable, but will amend by.default in R-devel to preserve it. Thomas: I think svymean() needs not to assume that 1-column data frames will be dropped. On Mon, 10 Dec 2007, [EMAIL PROTECTED] wrote: > by() fails for 1-column matrices and dataframes: > > X <- data.frame(a=1:10) > g <- gl(2,5) > by(X, g, colMeans) > > > Suggested fix: > > --- by-old.R2007-12-10 15:26:22.501086600 +0100 > +++ by.R2007-12-10 15:25:58.390477200 +0100 > @@ -26,7 +26,7 @@ > IND[[1]] <- INDICES > names(IND) <- deparse(substitute(INDICES))[1] > } else IND <- INDICES > -FUNx <- function(x) FUN(data[x,], ...) > +FUNx <- function(x) FUN(data[x, , drop=FALSE], ...) > nd <- nrow(data) > ans <- eval(substitute(tapply(1:nd, IND, FUNx)), data) > attr(ans, "call") <- match.call() > > > >_ > platform i386-pc-mingw32 > arch i386 > os mingw32 > system i386, mingw32 > status > major 2 > minor 6.1 > year 2007 > month 11 > day26 > svn rev43537 > language R > version.string R version 2.6.1 (2007-11-26) > > > Uwe Ligges > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] interactive graphics devices
On Tue, 18 Dec 2007, Byron Ellis wrote: > I probably missed this discussion, but why not just ASK the device if > it is interactive? I can easily imagine a case where a device might be > interactive or not depending on how it was started. In fact, I don't > have to imagine a case since the Quartz device in R-devel can have > exactly this behavior. Something like a Cairo device might also have > this behavior, though I don't know if the current Cairo devices > support it. You cannot ASK a device you have not yet opened: see the 'orNone' argument to dev.interactive(). Beyond that, there is nothing in the graphics device API to ask an open device. There are two Cairo devices in two packages and they behave differently: that makes it rather difficult to determine the behaviour by name. > On Dec 18, 2007 4:34 PM, Paul Murrell <[EMAIL PROTECTED]> wrote: >> Hi >> >> For all developers of add-on graphics devices: please note the >> existence of deviceIsInteractive() for adding your device to the list of >> devices for which dev.interactive() returns TRUE. (Available since R >> 2.6.0; thanks to Brian Ripley I think) And Deepayan Sarkar. >> Paul >> -- >> Dr Paul Murrell >> Department of Statistics >> The University of Auckland >> Private Bag 92019 >> Auckland >> New Zealand >> 64 9 3737599 x85392 >> [EMAIL PROTECTED] >> http://www.stat.auckland.ac.nz/~paul/ >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > > > -- 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] available.packages() not accurate?
> > pkgs <-
> > as.data.frame(available.packages(contrib.url("http://cran.r-project.org";)))
> > pkgs[c("sn", "GOSim", "GammaTest"), c("Package", "Version")]
> Package Version
> sn sn 0.4-4
> GOSim GOSim 1.1.2
> NA
>
> which match CRAN (which doesn't have GammaTest). So not sure what's going on.
I just figured it out:
> contrib.url(contrib.url("http://cran.r-project.org";))
[1]
"http://cran.r-project.org/bin/macosx/universal/contrib/2.6/bin/macosx/universal/contrib/2.6";
> contrib.url("http://cran.r-project.org";, type="source")
[1] "http://cran.r-project.org/src/contrib";
Oops - thanks for the help.
Hadley
--
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] available.packages() not accurate?
On 12/18/07, hadley wickham <[EMAIL PROTECTED]> wrote:
> On 12/18/07, Deepayan Sarkar <[EMAIL PROTECTED]> wrote:
> > On 12/18/07, hadley wickham <[EMAIL PROTECTED]> wrote:
> > > > pkgs <-
> > > > as.data.frame(available.packages(contrib.url("http://cran.r-project.org";)))
> > > > pkgs["sn", c("Package", "Version")]
> > >
> > > But looking at http://cran.r-project.org/src/contrib/ only sn_0.4-2 is
> > > available. Any ideas?
> >
> > I see 0.4-4. Could be a caching problem on your browser.
>
> Oh sorry - I explained it the wrong way around - available.packages
> lists 0.4-2 as the latest version, but 0.4-4 is available from
> src/contrib. The following packages also have a version mismatch
> between available.packages and CRAN:
>
> GOSim (1.0.2), GammaTest (2.1), InfNet (0.1), RcppTemplate (5.2),
> SNPassoc (1.4-8), StoppingRules (1.1), actuar (0.9-3), ape (2.0-1),
> bcp (1.7.2), dtw (0.3-1), edci (1.0-1), gstat (0.9-40), kappalab
> (0.4-0), mlegp (1.1), polycor (0.7-3), pwt (6.1-1), rcompletion
> (0.1-2), relaimpo (1.2-2), roblm (0.6), seewave (1.4.3), sfsmisc
> (0.95-13)
I see
> pkgs <-
> as.data.frame(available.packages(contrib.url("http://cran.r-project.org";)))
> pkgs[c("sn", "GOSim", "GammaTest"), c("Package", "Version")]
Package Version
sn sn 0.4-4
GOSim GOSim 1.1.2
NA
which match CRAN (which doesn't have GammaTest). So not sure what's going on.
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] available.packages() not accurate?
On 12/18/07, Deepayan Sarkar <[EMAIL PROTECTED]> wrote:
> On 12/18/07, hadley wickham <[EMAIL PROTECTED]> wrote:
> > > pkgs <-
> > > as.data.frame(available.packages(contrib.url("http://cran.r-project.org";)))
> > > pkgs["sn", c("Package", "Version")]
> >
> > But looking at http://cran.r-project.org/src/contrib/ only sn_0.4-2 is
> > available. Any ideas?
>
> I see 0.4-4. Could be a caching problem on your browser.
Oh sorry - I explained it the wrong way around - available.packages
lists 0.4-2 as the latest version, but 0.4-4 is available from
src/contrib. The following packages also have a version mismatch
between available.packages and CRAN:
GOSim (1.0.2), GammaTest (2.1), InfNet (0.1), RcppTemplate (5.2),
SNPassoc (1.4-8), StoppingRules (1.1), actuar (0.9-3), ape (2.0-1),
bcp (1.7.2), dtw (0.3-1), edci (1.0-1), gstat (0.9-40), kappalab
(0.4-0), mlegp (1.1), polycor (0.7-3), pwt (6.1-1), rcompletion
(0.1-2), relaimpo (1.2-2), roblm (0.6), seewave (1.4.3), sfsmisc
(0.95-13)
Hadley
--
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] available.packages() not accurate?
On 12/18/07, hadley wickham <[EMAIL PROTECTED]> wrote:
> > pkgs <-
> > as.data.frame(available.packages(contrib.url("http://cran.r-project.org";)))
> > pkgs["sn", c("Package", "Version")]
>
> But looking at http://cran.r-project.org/src/contrib/ only sn_0.4-2 is
> available. Any ideas?
I see 0.4-4. Could be a caching problem on your browser.
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] available.packages() not accurate?
> pkgs <-
> as.data.frame(available.packages(contrib.url("http://cran.r-project.org";)))
> pkgs["sn", c("Package", "Version")]
But looking at http://cran.r-project.org/src/contrib/ only sn_0.4-2 is
available. Any ideas?
Thanks,
Hadley
--
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] interactive graphics devices
On 12/18/07, Byron Ellis <[EMAIL PROTECTED]> wrote:
> I probably missed this discussion, but why not just ASK the device if
> it is interactive?
That's done if the device is open. deviceIsInteractive() takes away
the guessing even when it's not (the use-case is when you type
example(something) without a device open, and R has to decide whether
to set par(ask = TRUE) just by looking at getOption("device")).
> I can easily imagine a case where a device might be
> interactive or not depending on how it was started. In fact, I don't
> have to imagine a case since the Quartz device in R-devel can have
> exactly this behavior. Something like a Cairo device might also have
> this behavior, though I don't know if the current Cairo devices
> support it.
If there's ambiguity, you can choose not to use deviceIsInteractive.
You'll still be OK once the device is open (I don't think there's much
more that can be done).
-Deepayan
> On Dec 18, 2007 4:34 PM, Paul Murrell <[EMAIL PROTECTED]> wrote:
> > Hi
> >
> > For all developers of add-on graphics devices: please note the
> > existence of deviceIsInteractive() for adding your device to the list of
> > devices for which dev.interactive() returns TRUE. (Available since R
> > 2.6.0; thanks to Brian Ripley I think)
> >
> > Paul
> > --
> > Dr Paul Murrell
> > Department of Statistics
> > The University of Auckland
> > Private Bag 92019
> > Auckland
> > New Zealand
> > 64 9 3737599 x85392
> > [EMAIL PROTECTED]
> > http://www.stat.auckland.ac.nz/~paul/
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
>
>
> --
> Byron Ellis ([EMAIL PROTECTED])
> "Oook" -- The Librarian
>
> __
> 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] interactive graphics devices
I probably missed this discussion, but why not just ASK the device if it is interactive? I can easily imagine a case where a device might be interactive or not depending on how it was started. In fact, I don't have to imagine a case since the Quartz device in R-devel can have exactly this behavior. Something like a Cairo device might also have this behavior, though I don't know if the current Cairo devices support it. On Dec 18, 2007 4:34 PM, Paul Murrell <[EMAIL PROTECTED]> wrote: > Hi > > For all developers of add-on graphics devices: please note the > existence of deviceIsInteractive() for adding your device to the list of > devices for which dev.interactive() returns TRUE. (Available since R > 2.6.0; thanks to Brian Ripley I think) > > Paul > -- > Dr Paul Murrell > Department of Statistics > The University of Auckland > Private Bag 92019 > Auckland > New Zealand > 64 9 3737599 x85392 > [EMAIL PROTECTED] > http://www.stat.auckland.ac.nz/~paul/ > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Byron Ellis ([EMAIL PROTECTED]) "Oook" -- The Librarian __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] interactive graphics devices
Hi For all developers of add-on graphics devices: please note the existence of deviceIsInteractive() for adding your device to the list of devices for which dev.interactive() returns TRUE. (Available since R 2.6.0; thanks to Brian Ripley I think) Paul -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 [EMAIL PROTECTED] http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Improvement of SignRank functions
On Sat, 15 Dec 2007, Martin Maechler wrote: > Hi Ivo, > >> "IU" == Ivo Ugrina <[EMAIL PROTECTED]> >> on Sat, 15 Dec 2007 14:13:10 +0100 writes: > >IU> Martin Maechler wrote: >>> do you have evidence for your belief? >>> i.e. a set of system.time(.) calls where you see the >>> difference? > >IU> system.time(dsignrank(17511, 400)) >IU> user system elapsed >IU> 1.010 0.120 1.145 >IU> system.time(dsignrank((0:17511), 400)) >IU> user system elapsed >IU> 1.250.131.40 >IU> system.time(dsignrank((0:17511), 500)) >IU> user system elapsed >IU> 2.040 0.220 2.296 >IU> system.time(psignrank((0:17511), 600)) >IU> user system elapsed >IU> 20.670 0.580 21.403 >IU> system.time(qsignrank(0.56, 300)) >IU> user system elapsed >IU> 0.700 0.050 0.753 >IU> == >IU> system.time(dsignrank(17511, 400)) >IU> user system elapsed >IU> 0.070 0.000 0.078 >IU> system.time(dsignrank((0:17511), 400)) >IU> user system elapsed >IU> 0.100 0.000 0.104 >IU> system.time(dsignrank((0:17511), 500)) >IU> user system elapsed >IU> 0.160 0.000 0.164 >IU> system.time(psignrank((0:17511), 600)) >IU> user system elapsed >IU> 16.330 0.370 16.729 >IU> system.time(qsignrank(0.56, 300)) >IU> user system elapsed >IU> 0.020 0.010 0.029 > > > >IU> system.time(dsignrank((0:2), 600)) >IU> user system elapsed >IU> 3.470 0.280 3.745 >IU> RAM: ~130MB >IU> == >IU> system.time(dsignrank((0:2), 600)) >IU> user system elapsed >IU> 0.250 0.010 0.26 >IU> RAM: ~1MB > > that's quite convincing; thank you! > and I can verify part of it on my computer. > > I think I'd just commit your signrank.c > (with a few cosmetic changes) to the sources, right? > > *Not* using a static with all the previously computed counts > is probably not possible without a (CPU time) efficiency loss; > and to make this thread-safe one could use a "thread-global" > array, but how to do that would really depend on the threading > system used, and that's not at all given. I'ts possible to handle this sort of thing with OpenMP, which is I think the way we want to go, but it does require some care. luke > > Thank you for your contribution! > Martin > > > >>> BTW: If you had a smart idea to *not* use a static 'w' and still >>> be memory efficient, >>> that could lead to make that code "thread-safe", but I am >>> not at all sure this is possible without using >>> "thread-library C code". > >IU> I'll look into it. > > >IU> With respect, >IU> -- >IU> Ivo Ugrina >IU> ICQ: 47508335 | www.iugrina.com >IU> --- >IU> baza matematickih pojmova >IU> http://baza.iugrina.com >IU> --- >IU> anime, manga, Japan fanzin >IU> http://yoshi.iugrina.com > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Luke Tierney Chair, Statistics and Actuarial Science Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: [EMAIL PROTECTED] Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Fortran 90 and Windows
Thank you kindly Professor Ripley, Peter Dalgaard and Jari Oksanen. Although I had searched for Fortran 90 in various R locations, I hadn't thought to search for Fortran 95, and so hadn't seen Professor Ripley's reply to John Fox. I just joined this list yesterday, and saw the December archive just after posting. As pointed out by Professor Ripley, my approach (Fortran 90 constructs in *.f files) relies on the idiosyncrasies of gcc and R CMD SHLIB, and is clearly not portable. However, given that gcc is the engine of R, it seems almost worth the gamble. Fortran 90 array intrinsics are almost like compiled S, and very compelling in some circumstances. I was unaware of win-builder.r-project.org, and will certainly give that a shot. On the other hand, if I hear from very old *nixes that my code won't work, I'll probably relent. Again, thank you all, Dave Prof Brian Ripley wrote: > On Mon, 17 Dec 2007, Dave Roberts wrote: > >> I have been revising some FORTRAN 77 routines in R packages I have >> previously submitted. Since R is now using gfortan I experimented with >> some Fortran 90 code (array intrinsics primarily). So far the code is >> still in F77 fixed format, in files suffixed .f (not .f90), but >> incorporates some F90 constructs. It has worked fine in linux/R. I >> tried to follow the thread of previous discussions on this subject, but >> as fast as things are changing, it was somewhat dated, and not too >> definitive. > > 'Writing R Extensions' is both up-to-date and definitive, so please read > the primary documentation. In particular, we have strengthened the > comments about not using Fortran I/O, which can cause severe problems > when using the GUI version of R under Windows (although we now have a > workaround). > >> I don't so my own Windows versions of packages, but rather rely on CRAN >> to do the conversions, and I don't want to send them code that won't >> work on Windows. Does anybody have extensive experience on what >> elements of F90 can be used in R packages for Windows? If R CMD SHLIB >> is happy with it, is it likely to work? > > Since Windows' builds nowadays use gcc 4.2.1, if it works on your > unspecified version of gfortran on Linux it will very likely work on > Windows. And you can check that for yourself via > win-builder.r-project.org. > > However, using F9x code suffixed .f is not portable, and there are > plenty of other systems where it will fail, some of which would accept > .f90 or .f95 extensions. > > See also my reply to John Fox: > > https://stat.ethz.ch/pipermail/r-devel/2007-December/047695.html > -- David W. Roberts office 406-994-4548 Professor and Head FAX 406-994-3190 Department of Ecology email [EMAIL PROTECTED] Montana State University Bozeman, MT 59717-3460 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] small bug in panel.cor in example for pairs?
Dear all,
in the Example section of pairs there is
panel.cor <- function(x, y, digits=2, prefix="", cex.cor)
{
usr <- par("usr"); on.exit(par(usr))
par(usr = c(0, 1, 0, 1))
r <- abs(cor(x, y))
txt <- format(c(r, 0.123456789), digits=digits)[1]
txt <- paste(prefix, txt, sep="")
if(missing(cex.cor)) cex <- 0.8/strwidth(txt)
text(0.5, 0.5, txt, cex = cex * r)
}
Shouldn't the last two lines read
if(missing(cex.cor)) cex.cor <- 0.8/strwidth(txt)
text(0.5, 0.5, txt, cex = cex.cor * r)
?
Best,
Matthias
--
Dr. Matthias Kohl
Mathematical Statistics
University of Bayreuth
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] branch cuts of log() and sqrt()
Dear developers
Neither Math.Rd nor Log.Rd mention the branch cuts
that appear for complex arguments. I think it's important
to include such information.
Please find following two context diffs for Log.Rd and Math.Rd.
[The pedants amongst us will observe that
both sqrt() and log() have a branch point at complex
infinity, which is not mentioned in the patch. Comments
anyone?]
rksh
245-10:~/scratch/R-devel/src/library/base/man% diff -c Log.Rd
new_Log.Rd
*** Log.Rd Fri Jul 27 16:51:42 2007
--- new_Log.Rd Tue Dec 18 08:57:03 2007
***
*** 66,71
--- 66,75
\code{logb} is a wrapper for \code{log} for compatibility with
S. If
(S3 or S4) methods are set for \code{log} they will be dispatched.
Do not set S4 methods on \code{logb} itself.
+
+ For complex arguments, the branch cut is standard: there is a branch
+ point at zero and a cut along the negative real axis; continuity
+ is from above.
}
\section{S4 methods}{
\code{exp}, \code{expm1}, \code{log}, \code{log10}, \code{log2} and
245-10:~/scratch/R-devel/src/library/base/man%
245-10:~/scratch/R-devel/src/library/base/man% diff -c Math.Rd
new_Math.Rd
*** Math.Rd Fri Jul 27 16:51:44 2007
--- new_Math.Rd Tue Dec 18 09:01:35 2007
***
*** 22,32
\details{
These are generic functions: methods can be defined for them
individually or via the \code{\link[base:groupGeneric]{Math}}
! group generic. For complex arguments (and the default method),
\code{z},
! \code{abs(z) == \link{Mod}(z)} and \code{sqrt(z) == z^0.5}.
\code{abs(x)} returns an \code{\link{integer}} vector when \code
{x} is
\code{integer} or \code{\link{logical}}.
}
\section{S4 methods}{
Both are S4 generic and members of the
--- 22,39
\details{
These are generic functions: methods can be defined for them
individually or via the \code{\link[base:groupGeneric]{Math}}
! group generic.
\code{abs(x)} returns an \code{\link{integer}} vector when \code
{x} is
\code{integer} or \code{\link{logical}}.
+
+ For complex arguments (and the default method), \code{z},
+ \code{abs(z) == \link{Mod}(z)} and \code{sqrt(z) == z^0.5}.
+
+ The branch cut of \code{sqrt()} is standard: there is a branch point
+ at zero and a cut along the negative real axis; continuity is from
+ above.
+
}
\section{S4 methods}{
Both are S4 generic and members of the
245-10:~/scratch/R-devel/src/library/base/man%
--
Robin Hankin
Uncertainty Analyst and Neutral Theorist,
National Oceanography Centre, Southampton
European Way, Southampton SO14 3ZH, UK
tel 023-8059-7743
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] help files for load and related functions
> "DM" == Duncan Murdoch <[EMAIL PROTECTED]>
> on Mon, 17 Dec 2007 09:36:48 -0500 writes:
DM> On 12/17/2007 9:06 AM, Oleg Sklyar wrote:
>> Dear Patrick,
>>
>> Firstly, and most importantly, I do not think that your post qualified
>> for Rd! Please use the correct mail list for such things: R-help. I do
>> not think anybody on Rd wants mailboxes clogged with irrelevant
>> messages.
{ Oleg, you may have to be told that Pat Burns has been
acquainted with the S language for a very long time, maybe
about as long as you know to read... }
DM> Since Patrick's message was about changes to the documentation, I think
DM> it is relevant to this list.
yes indeed!
And the technicality of the discussion further down
is another good reason.
DM> Duncan Murdoch
>> Back to your question: it is not clear if you are confused, or your
>> 'user' is confused, but all three help pages look pretty clear and
>> straight forward to me. Moreover, I do not see any connection between
>> attach and library, which you find logical:
>>
>> - load - the general use of this one is to load external data sets, e.g.
>> load serialised R object(s) (as the example shows). Until you load, you
>> cannot use the object as it has no relation to the R session and can be
>> e.g. a file sitting somewhere on a network
>>
>> - attach - the general use of this one would be to access elements of a
>> data set directly, without the data set name specifier and the accessor
>> operator, such as $, thus as the help page states - it is used to add
>> the data set to the search path (as the example shows). If you look at
>> the example, you do not have to call attach to be able to use data, data
>> could have existed there before and what you effectively get with attach
>> is a more convenient way of dealing with the data
>>
>> - library - is used to load *and* attach an R package, which is not
>> exactly the same as a serialised R object(s), but a full set of other
>> functionality. Attaching packages is just a part of the loading process,
>> which occurs basically when the package becomes visible to the user.
>> Same as with load, you cannot use the package until you load it. There
>> is not a hint of similarity between loading a package and attaching a
>> data set as I see it.
Hmm, I think there is, . and there's more :
The function load() is well known for loading R objects into the
global environment; well known, easy to understand. However, it
can load into any other environment; and environments are the
crucial entities here.
BUT when talking about loading in the context of R packages *and*
namespaces (!), there are other things:
One important point I think was not mentioned yet, and is probably *the*
reason of potential confusion of useRs and even programmeRs: here
library() does conceptually two things
1) it *loads* the (exported) objects from the installed package
(or with lazy-loading just loads "stubs") into a new environment.
2) it "attaches" the names of those objects to the search() path
where things happen a bit differently for namespaced and other
packages.
For namespaced packages the two steps are really nicely
separable on a user level: I hope you've known
loadNamespace(), unloadNamespace(), attachNamespace() and the
fact that e.g. cluster::pam() loads cluster's package namespace
but does not attach cluster to search().
{ If you want to delve and hence to look at the library()
function, please do so in the sources, e.g.,
https://svn.r-project.org/R/trunk/src/library/base/R/library.R
which has many comments that are all gone in the 'library' function object.
}
I'd say: Because the loading part is the more delicate one than the
attach one, help(library) talks more about loading the package
than attaching..
Regards, Martin
>> Regards,
>> Oleg
>>
>> On Mon, 2007-12-17 at 11:00 +, Patrick Burns wrote:
>>> I recently had a discussion with a user about loading
>>> and attaching in R. I was surprised that the help files
>>> don't provide a very clear picture.
>>>
>>> From my point of view 'load' and 'attach' are very
>>> similar operations, the difference being that 'attach'
>>> creates a new database on the search list while 'load'
>>> puts all the objects into the global environment.
>>>
>>> The help file for 'load' is inexplicit that this is what
>>> happens. The 'load' and 'attach' help files neither refer
>>> to the other in their See Also.
>>>
>>> Furthermore, the 'library' help file talks about "loading"
>>> packages. I would suggest that it should use "attaching"
>>> as that is the analogous operation.
>>>
>>> None of these three help files (nor that of 'save') has a
>>> Side Effects section. Personally I think that all help
Re: [Rd] Fortran 90 and Windows
On Mon, 17 Dec 2007, Dave Roberts wrote: > I have been revising some FORTRAN 77 routines in R packages I have > previously submitted. Since R is now using gfortan I experimented with > some Fortran 90 code (array intrinsics primarily). So far the code is > still in F77 fixed format, in files suffixed .f (not .f90), but > incorporates some F90 constructs. It has worked fine in linux/R. I > tried to follow the thread of previous discussions on this subject, but > as fast as things are changing, it was somewhat dated, and not too > definitive. 'Writing R Extensions' is both up-to-date and definitive, so please read the primary documentation. In particular, we have strengthened the comments about not using Fortran I/O, which can cause severe problems when using the GUI version of R under Windows (although we now have a workaround). > I don't so my own Windows versions of packages, but rather rely on CRAN > to do the conversions, and I don't want to send them code that won't > work on Windows. Does anybody have extensive experience on what > elements of F90 can be used in R packages for Windows? If R CMD SHLIB > is happy with it, is it likely to work? Since Windows' builds nowadays use gcc 4.2.1, if it works on your unspecified version of gfortran on Linux it will very likely work on Windows. And you can check that for yourself via win-builder.r-project.org. However, using F9x code suffixed .f is not portable, and there are plenty of other systems where it will fail, some of which would accept .f90 or .f95 extensions. See also my reply to John Fox: https://stat.ethz.ch/pipermail/r-devel/2007-December/047695.html -- 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Fortran 90 and Windows
Dave Roberts wrote:
> I have been revising some FORTRAN 77 routines in R packages I have
> previously submitted. Since R is now using gfortan I experimented with
> some Fortran 90 code (array intrinsics primarily). So far the code is
> still in F77 fixed format, in files suffixed .f (not .f90), but
> incorporates some F90 constructs. It has worked fine in linux/R. I
> tried to follow the thread of previous discussions on this subject, but
> as fast as things are changing, it was somewhat dated, and not too
> definitive.
>
> I don't so my own Windows versions of packages, but rather rely on CRAN
> to do the conversions, and I don't want to send them code that won't
> work on Windows. Does anybody have extensive experience on what
> elements of F90 can be used in R packages for Windows? If R CMD SHLIB
> is happy with it, is it likely to work?
>
> Thanks, Dave
>
The Windows toolkit is also GCC, hence gfortran for new enough R. The
thing to worry about is the "other" category of machines. Either
oldish/specialized Unixes which ship with their own toolchains and
optimized libraries, or commercial compilers like the ones from Intel.
Brian Ripley and/or http://cran.r-project.org/doc/manuals/R-exts.html
can fill you in on the details. See also Brian's reply to John Fox on
December 9 ("I wouldn't let that deter you.").
--
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
[Rd] Fortran 90 and Windows
I have been revising some FORTRAN 77 routines in R packages I have previously submitted. Since R is now using gfortan I experimented with some Fortran 90 code (array intrinsics primarily). So far the code is still in F77 fixed format, in files suffixed .f (not .f90), but incorporates some F90 constructs. It has worked fine in linux/R. I tried to follow the thread of previous discussions on this subject, but as fast as things are changing, it was somewhat dated, and not too definitive. I don't so my own Windows versions of packages, but rather rely on CRAN to do the conversions, and I don't want to send them code that won't work on Windows. Does anybody have extensive experience on what elements of F90 can be used in R packages for Windows? If R CMD SHLIB is happy with it, is it likely to work? Thanks, Dave -- David W. Roberts office 406-994-4548 Professor and Head FAX 406-994-3190 Department of Ecology email [EMAIL PROTECTED] Montana State University Bozeman, MT 59717-3460 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
