Re: [Rd] slots of type "double"
On Tue, 13 Nov 2007, Prof Brian Ripley wrote:
> On Tue, 13 Nov 2007, John Chambers wrote:
>
>> What's the proposal here? To eliminate "double" as a class? No objection
>
> Eliminate "double" and "single".
>
>> from this corner. As I remember, it was put in early in the
>> implementation of methods, when I was confused about what R intended in
>> this area (well, I'm not totally unconfused even now).
>>
>> If this is the proposal, we could implement it in r-devel and see if
>> there are complaints.
>
> I was going to propose so after running some tests over CRAN/BioC (which
> will take a few hours).
Which showed up problems in packages Matrix and matlab.
Matrix clearly has a different view of these classes:
## "atomic vectors" (-> ?is.atomic ) --
## --- those that we want to convert from old-style "matrix"
setClassUnion("atomicVector", ## numeric = {integer, double} but all 3
should *directly* be atomic
members = c("logical", "integer", "double", "numeric",
"complex", "raw", "character"))
If I remove "double" there, I get an error in an example:
> stopifnot(is(scm, "sparseVector"),
+ identical(cm, as.numeric(scm)))
Error in as([EMAIL PROTECTED], mode) :
no method or default for coercing "numeric" to "double"
and looking at the code suggests that "double" is used as the class name
in several places.
Package matlab is simpler: test mkconstarray.R fails at
> test.mkconstarray(list(class.type = "double", value = pi, size = 4),
rep(pi, 4))
Error in as(value, match.arg(class.type)) :
no method or default for coercing "numeric" to "double"
and needs the author to rectify his confusion between "class" and "type".
I'd like to give the Matrix authors a chance to look into this before
making the change. Loking at the packages has reinforced my impression
that having "double" as an S4 class is only adding confusion, so the
change is desirable.
--
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
[Rd] When to use LazyLoad, LazyData and ZipData?
Dear developeRs, I've searched the documentation, FAQ, and mailing lists, but haven't found the answer(*) to the following: When should one specify LazyLoad, LazyData, and ZipData? And what is the default if they are left unspecified? (*)Except that 1) If the package you are writing uses the methods package, specify LazyLoad: yes, and 2) The optional ZipData field controls whether the automatic Windows build will zip up the data directory or no: set this to no if your package will not work with a zipped data directory. -- Sincerely, Bjørn-Helge Mevik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] When to use LazyLoad, LazyData and ZipData?
On 11/14/2007 7:01 AM, Bjørn-Helge Mevik wrote: > Dear developeRs, > > I've searched the documentation, FAQ, and mailing lists, but haven't > found the answer(*) to the following: > > When should one specify LazyLoad, LazyData, and ZipData? > > And what is the default if they are left unspecified? > > > (*)Except that > 1) If the package you are writing uses the methods package, specify > LazyLoad: yes, and > 2) The optional ZipData field controls whether the automatic Windows > build will zip up the data directory or no: set this to no if your > package will not work with a zipped data directory. I think that you shouldn't care about these things, and should accept the default for them unless one of those two pieces of advice applies to you. Let the package install code decide on what values to use. If you want to know the current defaults, look at the INSTALL script in R_HOME/bin, but don't expect them to stay the same as versions change. For example, lazy loading saves memory but may take extra time; the code chooses a tradeoff based on the amount of data involved, and the details of that choice could easily change. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] When to use LazyLoad, LazyData and ZipData?
On Wed, 14 Nov 2007, Bjørn-Helge Mevik wrote: Dear developeRs, I've searched the documentation, FAQ, and mailing lists, but haven't found the answer(*) to the following: When should one specify LazyLoad, LazyData, and ZipData? Preferably always, and I would suggest all should be 'yes' if your package will work with them. And what is the default if they are left unspecified? It varies by R version and platform. But as a guide LazyLoad: yes for all but small packages (those with less than 25Kb of R code) LazyData: no ZipData: yes on Windows if there is more than 100Kb of data and no duplicate namestems (e.g. foo.R and foo.tab). (*)Except that 1) If the package you are writing uses the methods package, specify LazyLoad: yes, and 2) The optional ZipData field controls whether the automatic Windows build will zip up the data directory or no: set this to no if your package will not work with a zipped data directory. -- 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] When to use LazyLoad, LazyData and ZipData?
On Nov 14, 2007 7:01 AM, Bjørn-Helge Mevik <[EMAIL PROTECTED]> wrote: > Dear developeRs, > > I've searched the documentation, FAQ, and mailing lists, but haven't > found the answer(*) to the following: > > When should one specify LazyLoad, LazyData, and ZipData? > > And what is the default if they are left unspecified? > > > (*)Except that > 1) If the package you are writing uses the methods package, specify > LazyLoad: yes, and > 2) The optional ZipData field controls whether the automatic Windows > build will zip up the data directory or no: set this to no if your > package will not work with a zipped data directory. There is some information and links regarding LazyLoad on the proto package home page, http://r-proto.googlecode.com, in the last section entitled Avoiding R Bugs in point #1. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] When to use LazyLoad, LazyData and ZipData?
Duncan Murdoch wrote:
> On 11/14/2007 7:01 AM, Bjørn-Helge Mevik wrote:
>
>> When should one specify LazyLoad, LazyData, and ZipData?
>
> I think that you shouldn't care about these things, and should accept
> the default for them unless one of those two pieces of advice applies
> to you. Let the package install code decide on what values to use.
Thank you. That seems like a reasonable strategy. :-)
The only small `snag' I can see is how to document the usage of data
sets. As I understand from `Writing R Extensions' (`The \usage entry
is always bar or (for packages which do not use lazy-loading of data)
data(bar).') It is preferrable to use \usage{bar} when LazyData is
true, and \usage{data(bar)} otherwise. Since data(bar) always works,
I guess the best strategy (when leaving LazyData to its default) is to
use \usage{data(bar)}.
> If you want to know the current defaults, look at the INSTALL script
> in R_HOME/bin,
Ah. I should have thought about that. :-)
--
Bjørn-Helge Mevik
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] slots of type "double"
On Wed, November 14, 2007 09:09, Prof Brian Ripley wrote:
> On Tue, 13 Nov 2007, Prof Brian Ripley wrote:
>
>> On Tue, 13 Nov 2007, John Chambers wrote:
>>
>>> What's the proposal here? To eliminate "double" as a class? No
>>> objection
>>
>> Eliminate "double" and "single".
>>
>>> from this corner. As I remember, it was put in early in the
>>> implementation of methods, when I was confused about what R intended in
>>> this area (well, I'm not totally unconfused even now).
>>>
>>> If this is the proposal, we could implement it in r-devel and see if
>>> there are complaints.
>>
>> I was going to propose so after running some tests over CRAN/BioC (which
>> will take a few hours).
>
> Which showed up problems in packages Matrix and matlab.
>
> Matrix clearly has a different view of these classes:
>
> ## "atomic vectors" (-> ?is.atomic ) --
> ## --- those that we want to convert from old-style "matrix"
> setClassUnion("atomicVector", ## numeric = {integer, double} but all 3
> should *directly* be atomic
>members = c("logical", "integer", "double", "numeric",
>"complex", "raw", "character"))
>
> If I remove "double" there, I get an error in an example:
>
>> stopifnot(is(scm, "sparseVector"),
> + identical(cm, as.numeric(scm)))
> Error in as([EMAIL PROTECTED], mode) :
>no method or default for coercing "numeric" to "double"
>
> and looking at the code suggests that "double" is used as the class name
> in several places.
>
>
> Package matlab is simpler: test mkconstarray.R fails at
>
>> test.mkconstarray(list(class.type = "double", value = pi, size = 4),
> rep(pi, 4))
>Error in as(value, match.arg(class.type)) :
> no method or default for coercing "numeric" to "double"
>
> and needs the author to rectify his confusion between "class" and "type".
>
> I'd like to give the Matrix authors a chance to look into this before
> making the change. Loking at the packages has reinforced my impression
> that having "double" as an S4 class is only adding confusion, so the
> change is desirable.
I think (without having had time to check all implications) that I agree
quite a bit. I don't think that I was not partly confused about things,
either as they were in Matrix when I "entered the project" or as they
turned out to work or fail, when we started to use those class definitions
quite a few R versions back, when also "methods" / "base" may have behaved
a bit differently than now.
I must admit that I did not program according to documented behavior, but
rather to work behavior :-) ;-)
I'm very busy the rest of this week, in out'of'town meetings,
so won't be able to comment much more.
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] isOpen on closed connections
As far as I can tell, 'isOpen' cannot return FALSE in the case when 'rw = ""'.
If the connection has already been closed by 'close' or some other function,
then isOpen will produce an error. The problem is that when isOpen calls
'getConnection', the connection cannot be found and 'getConnection' produces an
error. The check to see if it is open is never actually done.
This came up in some code where I'm trying to clean up connections after
successfully opening them. The problem is that if I try to close a connection
that has already been closed, I get an error (because 'getConnection' cannot
find it). But then there's no way for me to find out if a connection has
already been closed. Perhaps there's another approach I should be taking? The
context is basically,
con <- file("foo", "w")
tryCatch({
## Do stuff that might fail
writeLines(stuff, con)
close(con)
file.copy("foo", "bar")
}, finally = {
close(con)
})
So the problem is that if the block in the 'tryCatch' succeeds, the 'finally'
will produce an error.
I'm not exactly sure of what I'd want since it seems modifying 'getConnection'
would not be a great idea as it is used elsewhere.
-roger
--
Roger D. Peng | http://www.biostat.jhsph.edu/~rpeng/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] package installation order
I have roughly 80 or so packages sources. These were obtained by taking
a snapshot of certain CRAN packages a few months ago using
install.packages(
pkgs = pckNames,
destdir = "/home/max",
repos = "http://cran.r-project.org";
dependencies = c("Depends", "Imports", "Suggests"))
We need to install these versions of the packages across a few different
architectures/systems (linux, solaris, 32- and 64-bit). Right now, we
are constrained to version 2.5.1 (I know, I know).
Right now, I'd use
tarList <- list.files()
tarList <- grep(".tar.gz", tarList, fixed = TRUE, value = TRUE)
install.packages (tarList, repos = NULL)
to install, but the package dependencies are ignored. For example, XML
gets installed after other packages that depend on it.
I've looked through ?install.packages and I have tried using
install.packages (
tarList, repos = NULL,
dependencies = c("Depends", "Imports", "Suggests"))
but this did not appear to change the install ordering.
Is there a simpler way to do this rather than trial and error?
Thanks,
Max
> sessionInfo()
R version 2.5.1 (2007-06-27)
i686-pc-linux-gnu
locale:
C
attached base packages:
[1] "stats" "graphics" "grDevices" "utils" "datasets"
"methods"
[7] "base"
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] package installation order
Hi Max,
On 14 November 2007 at 09:34, Kuhn, Max wrote:
| I have roughly 80 or so packages sources. These were obtained by taking
| a snapshot of certain CRAN packages a few months ago using
|
|install.packages(
| pkgs = pckNames,
| destdir = "/home/max",
| repos = "http://cran.r-project.org";
| dependencies = c("Depends", "Imports", "Suggests"))
|
| We need to install these versions of the packages across a few different
| architectures/systems (linux, solaris, 32- and 64-bit). Right now, we
| are constrained to version 2.5.1 (I know, I know).
|
| Right now, I'd use
|
|tarList <- list.files()
|tarList <- grep(".tar.gz", tarList, fixed = TRUE, value = TRUE)
|install.packages (tarList, repos = NULL)
|
| to install, but the package dependencies are ignored. For example, XML
| gets installed after other packages that depend on it.
|
| I've looked through ?install.packages and I have tried using
|
|install.packages (
| tarList, repos = NULL,
| dependencies = c("Depends", "Imports", "Suggests"))
|
| but this did not appear to change the install ordering.
|
| Is there a simpler way to do this rather than trial and error?
When trying to package the by-now-gargantuan Rmetrics for Debian (which is
still ongoing), I looked around for some Depends builders. Turns out that
BioC has this. E.g. the following worked for:
## > install.packages("Biobase", repo="http://www.bioconductor.org";)
## > repos <- Biobase:::biocReposList()
## > install.packages("pkgDepTools", repos=repos["bioc"])
## > library(pkgDepTools)
## Loading required package: graph
## Loading required package: RBGL
## > CRANdeps <- makeDepGraph(repos["cran"], type="source")
## > getInstallOrder("Rmetrics", CRANdeps, needed.only=FALSE)
worked for me. I meant to add some code for Graphviz visualization (or look
for it, Seth et al probably already wrote it) but what you get from
getInstallOrder() should suit your needs here.
Hth, Dirk
--
Three out of two people have difficulties with fractions.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] package installation order
Dirk,
Thanks for the email.
> When trying to package the by-now-gargantuan Rmetrics for Debian
(which is
> still ongoing), I looked around for some Depends builders. Turns out
that
> BioC has this. E.g. the following worked for:
>
> ## > install.packages("Biobase", repo="http://www.bioconductor.org";)
> ## > repos <- Biobase:::biocReposList()
> ## > install.packages("pkgDepTools", repos=repos["bioc"])
> ## > library(pkgDepTools)
> ## Loading required package: graph
> ## Loading required package: RBGL
> ## > CRANdeps <- makeDepGraph(repos["cran"], type="source")
> ## > getInstallOrder("Rmetrics", CRANdeps, needed.only=FALSE)
>
> worked for me. I meant to add some code for Graphviz visualization
(or look
> for it, Seth et al probably already wrote it) but what you get from
> getInstallOrder() should suit your needs here.
That should approximate it. The dependencies for some packages will have
changed since my snapshot. Next time I'll get the CRAN dependencies when
I get the packages.
Max
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] package installation order
On Wed, 14 Nov 2007, Kuhn, Max wrote:
> I have roughly 80 or so packages sources. These were obtained by taking
> a snapshot of certain CRAN packages a few months ago using
>
> install.packages(
> pkgs = pckNames,
> destdir = "/home/max",
> repos = "http://cran.r-project.org";
> dependencies = c("Depends", "Imports", "Suggests"))
>
> We need to install these versions of the packages across a few different
> architectures/systems (linux, solaris, 32- and 64-bit). Right now, we
> are constrained to version 2.5.1 (I know, I know).
>
> Right now, I'd use
>
> tarList <- list.files()
> tarList <- grep(".tar.gz", tarList, fixed = TRUE, value = TRUE)
> install.packages (tarList, repos = NULL)
You need the information from available.packages() to do the ordering, so
you need a non-NULL repository. This works if you convert your local
collection into a local repository. You will need a PACKAGES file, but
tools::write_PACKAGES can re-create one for you.
There are also dependency tools in package tools and on BioC.
> to install, but the package dependencies are ignored. For example, XML
> gets installed after other packages that depend on it.
>
> I've looked through ?install.packages and I have tried using
>
> install.packages (
> tarList, repos = NULL,
> dependencies = c("Depends", "Imports", "Suggests"))
>
> but this did not appear to change the install ordering.
>
> Is there a simpler way to do this rather than trial and error?
>
> Thanks,
>
> Max
--
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] package installation order
Professor Ripley, > You need the information from available.packages() to do the ordering, so > you need a non-NULL repository. This works if you convert your local > collection into a local repository. You will need a PACKAGES file, but > tools::write_PACKAGES can re-create one for you. > > There are also dependency tools in package tools and on BioC. This is probably a better option for me given that my source files are a little out of date. I couldn't get it to work though. I put the tar.gz files into a sub-directory (./src/contrib) I ran write_PACAKGES referencing that directory and type = "source" and verbose = TRUE. No error messages were given and it resulted in PACKAGES and PACKAGES.gz files that appeared to have all the right info in it. I figured out the package names by parsing the names of the tar.gz files. I then ran install.packages(pckList[1:3], repos = "/home/max/tmp/r-2.5.1-pkgs-updated/src/contrib", contriburl = "/home/max/tmp/r-2.5.1-pkgs-updated/src/contrib", type = "source") No packages were installed and I had the warnings: Warning: unable to access index for repository /home/max/tmp/r-2.5.1-pkgs-updated/src/contrib Warning message: packages 'Cairo', 'Design', 'ElemStatLearn' are not available in: install.packages(pckList[1:3], repos = "/home/max/tmp/r-2.5.1-pkgs-updated/src/contrib", (those particular packages are in ./src/contrib.) I also tried different variations of using the file names etc. I'm assuming that I don't have a proper repository. Am I missing something obvious here and/or is there some documentation on what the elements of a repository are? Thanks again, Max __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] package installation order
On Wed, 14 Nov 2007, Kuhn, Max wrote:
> Professor Ripley,
>
>> You need the information from available.packages() to do the ordering,
> so
>> you need a non-NULL repository. This works if you convert your local
>> collection into a local repository. You will need a PACKAGES file, but
>
>> tools::write_PACKAGES can re-create one for you.
>>
>> There are also dependency tools in package tools and on BioC.
>
> This is probably a better option for me given that my source files are a
> little out of date. I couldn't get it to work though.
>
> I put the tar.gz files into a sub-directory (./src/contrib)
>
> I ran write_PACAKGES referencing that directory and type = "source" and
> verbose = TRUE. No error messages were given and it resulted in PACKAGES
> and PACKAGES.gz files that appeared to have all the right info in it.
>
> I figured out the package names by parsing the names of the tar.gz
> files.
>
> I then ran
>
> install.packages(pckList[1:3],
> repos = "/home/max/tmp/r-2.5.1-pkgs-updated/src/contrib",
> contriburl = "/home/max/tmp/r-2.5.1-pkgs-updated/src/contrib",
> type = "source")
It does say 'URL(s)', hence
repos = "file:///home/max/tmp/r-2.5.1-pkgs-updated"
is I think all you need. Here's a (working) example local to me:
> install.packages("yags", repos="file:///data/ftp/pub/RWin")
>
> No packages were installed and I had the warnings:
>
> Warning: unable to access index for repository
> /home/max/tmp/r-2.5.1-pkgs-updated/src/contrib
> Warning message:
> packages 'Cairo', 'Design', 'ElemStatLearn' are not available in:
> install.packages(pckList[1:3], repos =
> "/home/max/tmp/r-2.5.1-pkgs-updated/src/contrib",
>
> (those particular packages are in ./src/contrib.) I also tried different
> variations of using the file names etc.
>
> I'm assuming that I don't have a proper repository. Am I missing
> something obvious here and/or is there some documentation on what the
> elements of a repository are?
There is, in the R-admin manual.
> Thanks again,
>
> Max
>
--
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] package installation order
Professor Ripley, > It does say 'URL(s)', hence > > repos = "file:///home/max/tmp/r-2.5.1-pkgs-updated" That works. Thanks for your expertise. Max __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] library path in Rd link
On 11/14/2007 8:49 AM, Adrian Dusa wrote:
> Dear all,
>
> When creating new functions in a package, there is a "See also" component in
> the Rd file.
> Usually one uses \link{otherfun}, if the other function is from the same
> package, or \link[otherpackage]{otherfun} otherwise.
>
> The trouble is that I install new packages not in the default R library
> folder, but into some other subfolder in my home, so the link searches
> for "otherpackage" in my home subfolder.
>
> Is there a method to create links to functions from the base package, for
> example (which is installed by default in the normal library folder)?
I believe this is normally automatic in platforms other than Windows.
On Windows, the answer is no.
The problem is that in most cases R isn't in charge of the help file
viewing. There isn't a good way to make a link from an HTML file to a
location that isn't known in advance, for example.
On Unix-alikes, the workaround is to build soft links to all the
packages in a standard location; but soft links don't work on Windows
(and we don't want to get into the almost-undocumented hard links that
exist on some Windows file systems).
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] library path in Rd link
On Wed, 14 Nov 2007, Adrian Dusa wrote:
>
> Dear all,
>
> When creating new functions in a package, there is a "See also" component in
> the Rd file.
> Usually one uses \link{otherfun}, if the other function is from the same
> package, or \link[otherpackage]{otherfun} otherwise.
I think you have misread the manual here:
There are two other forms of optional argument specified as
\link[pkg]{foo} and \link[pkg:bar]{foo} to link to the package pkg, to
files foo.html and bar.html respectively. These are rarely needed,
perhaps to refer to not-yet-installed packages (but there the HTML
help system will resolve the link at run time) or in the normally
undesirable event that more than one package offers help on a topic
(in which case the present package has precedence so this is only
needed to refer to other packages)
Note: 'rarely needed'.
> The trouble is that I install new packages not in the default R library
> folder, but into some other subfolder in my home, so the link searches
> for "otherpackage" in my home subfolder.
>
> Is there a method to create links to functions from the base package, for
> example (which is installed by default in the normal library folder)?
What OS is this? (As I recall you used Linux last time you posted.)
In any case, on all OSes you will be able to do cross-library links to the
base package without having to do anything further (and CRAN packages are
full of them). On Unix-alikes the help files are all linked into a single
virtual library, and on Windows links to the base package (and a few
others) from other libraries are fixed up on installation by
link.html.help (see its help).
--
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
[Rd] stats package, optim and other optimization methods: more parameters?
Dear R developers, concerning the stats package, is there a way to access more of the 'internal' parameters of the optim() methods (e.g. BFGS), without me rewriting optim code and using it as an internal, patched stats package? It may not sound useful to you, but for me it is important to be able to change the parameters as I want to apply parameter tuning methods. Currently, I'm doing so only on the very limited parameter set available via the control parameter, but e.g. for the CG and BFGS methods, this is practically empty. But there are internally set parameters (e.g. for the line searches), just they are not accessible from the outside. Best wishes and many thanks, Mike Preuss __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] library path in Rd link
Dear all,
When creating new functions in a package, there is a "See also" component in
the Rd file.
Usually one uses \link{otherfun}, if the other function is from the same
package, or \link[otherpackage]{otherfun} otherwise.
The trouble is that I install new packages not in the default R library
folder, but into some other subfolder in my home, so the link searches
for "otherpackage" in my home subfolder.
Is there a method to create links to functions from the base package, for
example (which is installed by default in the normal library folder)?
Thank you,
Adrian
--
Adrian Dusa
Romanian Social Data Archive
1, Schitu Magureanu Bd
050025 Bucharest sector 5
Romania
Tel./Fax: +40 21 3126618 \
+40 21 3120210 / int.101
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] stats package, optim and other optimization methods: more parameters?
On Wed, 14 Nov 2007, Mike Preuss wrote: > Dear R developers, > > concerning the stats package, > is there a way to access more of the 'internal' > parameters of the optim() methods (e.g. BFGS), > without me rewriting optim code and using it as > an internal, patched stats package? It may not > sound useful to you, but for me it is important > to be able to change the parameters as I want > to apply parameter tuning methods. Currently, > I'm doing so only on the very limited parameter > set available via the control parameter, but > e.g. for the CG and BFGS methods, this is practically > empty. But there are internally set parameters > (e.g. for the line searches), just they are not > accessible from the outside. Why don't you read the C code to find out? You probably also need to read the reference to understand the choices made, and why the author didn't feel it useful to make them accessible. -- 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] slots of type "double"
still found a bit time for more remarks.
> "MM" == Martin Mächler <[EMAIL PROTECTED]>
> on Wed, 14 Nov 2007 14:23:12 +0100 (CET) writes:
MM> On Wed, November 14, 2007 09:09, Prof Brian Ripley
MM> wrote:
>> On Tue, 13 Nov 2007, Prof Brian Ripley wrote:
>>
>>> On Tue, 13 Nov 2007, John Chambers wrote:
>>>
What's the proposal here? To eliminate "double" as a
class? No objection
>>>
>>> Eliminate "double" and "single".
>>>
from this corner. As I remember, it was put in early
in the implementation of methods, when I was confused
about what R intended in this area (well, I'm not
totally unconfused even now).
If this is the proposal, we could implement it in
r-devel and see if there are complaints.
>>>
>>> I was going to propose so after running some tests over
>>> CRAN/BioC (which will take a few hours).
>>
>> Which showed up problems in packages Matrix and matlab.
>> Matrix clearly has a different view of these classes:
>>
>> ## "atomic vectors" (-> ?is.atomic ) -- ##
>> --- those that we want to convert from
>> old-style "matrix" setClassUnion("atomicVector", ##
>> numeric = {integer, double} but all 3 should *directly*
>> be atomic members = c("logical", "integer", "double",
>> "numeric", "complex", "raw", "character"))
>>
>> If I remove "double" there, I get an error in an example:
>>
>>> stopifnot(is(scm, "sparseVector"),
>> + identical(cm, as.numeric(scm))) Error in as([EMAIL PROTECTED], mode)
>> : no method or default for coercing "numeric" to "double"
>>
>> and looking at the code suggests that "double" is used as
>> the class name in several places.
yes.
As you mention and I had in the comment above,
I've worked from the premise of something like a class union of
numeric = {integer, double}
-- which corresponds to S3'sis.numeric() which we all know
differs from the semantic of as.numeric()
and now know why I had done so {empty lines deleted}:
> showClass("numeric")
No Slots, prototype of class "numeric"
Extends: "vector"
Known Subclasses: "double", "integer"
> showClass("double")
No Slots, prototype of class "numeric"
Extends: "vector", "numeric"
> showClass("integer")
No Slots, prototype of class "integer"
Extends: "vector", "numeric"
which you partially also mentioned in your initial posting.
As a 2nd thought I wonder if we should not keep this current
scheme and fix its behavior where needed (the problem the OP had):
The notion of numeric := union(double, integer)
does now appeal to me again;
in particular since eliminating "double" in the S4 world will
not eliminate it from other places, and the basic problem of
is.numeric / as.numeric inconsistency is - I think - not
something we'd want to eliminate, just because it would break too
much existing code (and books on S and R).
Of course I may have overlooked other reasonings;
as mentioned, I'm quite a bit time limited at the moment.
Martin
[]
>> I'd like to give the Matrix authors a chance to look into
>> this before making the change.
Thanks, indeed!
>> Loking at the packages has reinforced my impression that
>> having "double" as an S4 class is only adding confusion,
>> so the change is desirable.
well or maybe it's just the lack of comprehensive documentation
of S4 classes as in 'methods' in R -- where I think JMC did want
to do a few things slightly differently than they are in S-PLUS..
MM> I think (without having had time to check all
MM> implications) that I agree quite a bit. I don't think
MM> that I was not partly confused about things, either as
MM> they were in Matrix when I "entered the project" or as
MM> they turned out to work or fail, when we started to use
MM> those class definitions quite a few R versions back,
MM> when also "methods" / "base" may have behaved a bit
MM> differently than now. I must admit that I did not
MM> program according to documented behavior, but rather to
MM> work behavior :-) ;-)
MM> I'm very busy the rest of this week, in out'of'town
MM> meetings, so won't be able to comment much more. Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] stats package, optim and other optimization methods: more parameters?
Dear Brian, thanks for the hint. But my question is more concerned with the technical procedure. Of course, I can change the C code locally. And then use a locally changed package. But then nobody else beside myself can use it, right? If changes were made in the official code (and it's not really changing the code, only adding some parameters to the interface), my experiments could be repeated by others. And if the official code is then changed again, I'd have to update the local code every time. Or is that unlikely? Or am I missing some important point here? Best, Mike Prof Brian Ripley wrote: > On Wed, 14 Nov 2007, Mike Preuss wrote: > >> Dear R developers, >> >> concerning the stats package, >> is there a way to access more of the 'internal' >> parameters of the optim() methods (e.g. BFGS), >> without me rewriting optim code and using it as >> an internal, patched stats package? It may not >> sound useful to you, but for me it is important >> to be able to change the parameters as I want >> to apply parameter tuning methods. Currently, >> I'm doing so only on the very limited parameter >> set available via the control parameter, but >> e.g. for the CG and BFGS methods, this is practically >> empty. But there are internally set parameters >> (e.g. for the line searches), just they are not >> accessible from the outside. > > Why don't you read the C code to find out? > > You probably also need to read the reference to understand the choices > made, and why the author didn't feel it useful to make them accessible. > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] library path in Rd link
On Thu, 15 Nov 2007, Adrian Dusa wrote:
> Dear Prof. Ripley,
>
> On Wednesday 14 November 2007, Prof Brian Ripley wrote:
>> On Wed, 14 Nov 2007, Adrian Dusa wrote:
>>> Dear all,
>>>
>>> When creating new functions in a package, there is a "See also" component
>>> in the Rd file.
>>> Usually one uses \link{otherfun}, if the other function is from the same
>>> package, or \link[otherpackage]{otherfun} otherwise.
>>
>> I think you have misread the manual here:
>>
>>There are two other forms of optional argument specified as
>>\link[pkg]{foo} and \link[pkg:bar]{foo} to link to the package pkg, to
>>files foo.html and bar.html respectively. These are rarely needed,
>>perhaps to refer to not-yet-installed packages (but there the HTML
>>help system will resolve the link at run time) or in the normally
>>undesirable event that more than one package offers help on a topic
>>(in which case the present package has precedence so this is only
>>needed to refer to other packages)
>>
>> Note: 'rarely needed'.
>
> Ah-haa, thanks for the clarification. I could have directly used
> \code{\link{anova}}
> to refer to the anova() from package stats which is also installed by default
> in the same installation folder as the base package.
>
>
>>> The trouble is that I install new packages not in the default R library
>>> folder, but into some other subfolder in my home, so the link searches
>>> for "otherpackage" in my home subfolder.
>>>
>>> Is there a method to create links to functions from the base package, for
>>> example (which is installed by default in the normal library folder)?
>>
>> What OS is this? (As I recall you used Linux last time you posted.)
>
> Linux it is, I only thought the question should be platform independent.
>
>> In any case, on all OSes you will be able to do cross-library links to the
>> base package without having to do anything further (and CRAN packages are
>> full of them). On Unix-alikes the help files are all linked into a single
>> virtual library, and on Windows links to the base package (and a few
>> others) from other libraries are fixed up on installation by
>> link.html.help (see its help).
>
> Indeed, link.html.help() resolves all the links under Windows (where I
> suspected the biggest trouble would be). It is strangely under Linux that I
> am not able to resolve the links (most surely I do something wrong).
>
> Using as above:
> \code{\link{anova}}
>
> the html help file directs to
> file:///home/adi/myRlibrary/stats/html/anova.html
I hope it is actually ../../stats/html/anova.html and the browser is
interpreting that as a full URL.
> instead of
> file:///usr/lib/R/library/stats/html/anova.html
But at run time help.start() creates links into a subdirectory of
tempdir(). As in
> help.start()
Making links in per-session dir ...
If '/home/ripley/bin/firefox' is already running, it is *not*
restarted, and you must switch to its window.
Otherwise, be patient ...
and without that
> help("anova", htmlhelp=TRUE)
Help for 'anova' is shown in browser /home/ripley/bin/firefox ...
Use
help("anova", htmlhelp = FALSE)
or
options(htmlhelp = FALSE)
to revert.
Warning message:
In .show_help_on_topic_as_HTML(file, topic) :
Using non-linked HTML file: style sheet and hyperlinks may be incorrect
and note the last line.
(In case anyone wonders about the browser path: I am running 32-bit
Firefox on x86_64 Linux.)
--
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] library path in Rd link
On 14/11/2007 6:09 PM, Adrian Dusa wrote: > On Wednesday 14 November 2007, Duncan Murdoch wrote: >> On 11/14/2007 8:49 AM, Adrian Dusa wrote: >>> [...] >>> >>> Is there a method to create links to functions from the base package, for >>> example (which is installed by default in the normal library folder)? >> I believe this is normally automatic in platforms other than Windows. >> On Windows, the answer is no. > > This is what I thought, too. But if I link for example to function anova() in > pacakge stats, the html link after installing the new package is: > > file:///home/adi/myRlibrary/stats/html/anova.html > > where the stats package is by default installed in: > > /usr/lib/R/library/ > > (indeed my question was related to Windows too, not only on Linux) > > >> The problem is that in most cases R isn't in charge of the help file >> viewing. There isn't a good way to make a link from an HTML file to a >> location that isn't known in advance, for example. >> >> On Unix-alikes, the workaround is to build soft links to all the >> packages in a standard location; but soft links don't work on Windows >> (and we don't want to get into the almost-undocumented hard links that >> exist on some Windows file systems). > > I understand, thank you. I learned from Prof. Ripley's answer that Windows > has > link.html.help() function to resolve the html help files from all installed > packages. I didn't know about that; I mainly use the CHMHELP files. They don't support this, being precompiled when the binary package is built. Another reason to switch. The link is probably "../../stats/html/anova.html", and is just being displayed by your browser that way. This is correct: R installs soft links to all packages in one place. The HTML code doesn't get fixed up the way it needs to be on Windows. Are you browsing the files from outside of R? As far as I know (and I rarely use Unix so this may be out of date info) the links are set up in a temporary directoy when you call .libPaths(), and are removed at the end of your session. I don't know if calling library(foo, lib.loc="mine") is enough to link the foo help into the system. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] library path in Rd link
On 14/11/2007 6:44 PM, Adrian Dusa wrote:
> On Thursday 15 November 2007, Prof Brian Ripley wrote:
>> [...]
>>> Using as above:
>>> \code{\link{anova}}
>>>
>>> the html help file directs to
>>> file:///home/adi/myRlibrary/stats/html/anova.html
>> I hope it is actually ../../stats/html/anova.html and the browser is
>> interpreting that as a full URL.
>>
>>> instead of
>>> file:///usr/lib/R/library/stats/html/anova.html
>> But at run time help.start() creates links into a subdirectory of
>> tempdir(). As in
>>
>>> help.start()
>
> I got it.
> Perhaps it would be useful to have another startup option, something like:
> options(htmlLinksResolve=TRUE)
>
> that one could use in the .First() function from .Rprofile
>
> I tried using help.start() in .Rprofile, but it throws a (probably obvious)
> error:
> Error: could not find function "help.start"
That's just because .Rprofile is run before most packages are attached;
you should be able to say utils::help.start() to get it to run.
>
>
> For my personal purposes, all questions have been answered though.
> Thank you very much,
> Adrian
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] library path in Rd link
On Thursday 15 November 2007, Duncan Murdoch wrote: > [...] > > > > I understand, thank you. I learned from Prof. Ripley's answer that > > Windows has link.html.help() function to resolve the html help files from > > all installed packages. > > I didn't know about that; I mainly use the CHMHELP files. They don't > support this, being precompiled when the binary package is built. > Another reason to switch. > > The link is probably "../../stats/html/anova.html", and is just being > displayed by your browser that way. This is correct: R installs soft > links to all packages in one place. The HTML code doesn't get fixed up > the way it needs to be on Windows. It is true, the link was "../../" (my misunderstanding) > Are you browsing the files from outside of R? As far as I know (and I > rarely use Unix so this may be out of date info) the links are set up in > a temporary directoy when you call .libPaths(), and are removed at the > end of your session. I don't know if calling library(foo, > lib.loc="mine") is enough to link the foo help into the system. I use: options(htmlhelp=TRUE) options(browser="firefox") I just tried library(myPackage, lib.loc="myRlibrary") but I still get Warning message: In .show_help_on_topic_as_HTML(file, topic) : Using non-linked HTML file: style sheet and hyperlinks may be incorrect so it seems foo help is not linked into the system. But there are (at least on Linux) two more than acceptable solutions: - soft link the folders from /usr/lib/R/library/ to myRlibrary/ (your suggestion, I like it very much and it makes me a happy Linux user) - use help.start() which links all packages help in a tmp directory (Prof.Ripley's solution) Best regards, Adrian -- Adrian Dusa Romanian Social Data Archive 1, Schitu Magureanu Bd 050025 Bucharest sector 5 Romania Tel./Fax: +40 21 3126618 \ +40 21 3120210 / int.101 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] library path in Rd link
On Thursday 15 November 2007, Duncan Murdoch wrote: > [...] > > I tried using help.start() in .Rprofile, but it throws a (probably > > obvious) error: > > Error: could not find function "help.start" > > That's just because .Rprofile is run before most packages are attached; > you should be able to say utils::help.start() to get it to run. Smooth :o) -- Adrian Dusa Romanian Social Data Archive 1, Schitu Magureanu Bd 050025 Bucharest sector 5 Romania Tel./Fax: +40 21 3126618 \ +40 21 3120210 / int.101 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] library path in Rd link
On Nov 14, 2007 4:36 PM, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > > On Unix-alikes, the workaround is to build soft links to all the > packages in a standard location; but soft links don't work on Windows > (and we don't want to get into the almost-undocumented hard links that > exist on some Windows file systems). Symbolic links are available on Windows Vista: C:\> mklink /? Creates a symbolic link. MKLINK [[/D] | [/H] | [/J]] Link Target /D Creates a directory symbolic link. Default is a file symbolic link. /H Creates a hard link instead of a symbolic link. /J Creates a Directory Junction. Linkspecifies the new symbolic link name. Target specifies the path (relative or absolute) that the new link refers to. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] library path in Rd link
On Thursday 15 November 2007, Prof Brian Ripley wrote:
> [...]
> >
> > Using as above:
> > \code{\link{anova}}
> >
> > the html help file directs to
> > file:///home/adi/myRlibrary/stats/html/anova.html
>
> I hope it is actually ../../stats/html/anova.html and the browser is
> interpreting that as a full URL.
>
> > instead of
> > file:///usr/lib/R/library/stats/html/anova.html
>
> But at run time help.start() creates links into a subdirectory of
> tempdir(). As in
>
> > help.start()
I got it.
Perhaps it would be useful to have another startup option, something like:
options(htmlLinksResolve=TRUE)
that one could use in the .First() function from .Rprofile
I tried using help.start() in .Rprofile, but it throws a (probably obvious)
error:
Error: could not find function "help.start"
For my personal purposes, all questions have been answered though.
Thank you very much,
Adrian
--
Adrian Dusa
Romanian Social Data Archive
1, Schitu Magureanu Bd
050025 Bucharest sector 5
Romania
Tel./Fax: +40 21 3126618 \
+40 21 3120210 / int.101
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] faqs
An extremely modest proposal: It would be nice if packages could have a FAQ and if faq(package.name) would produce this faq. And if, by default faq() FAQ() would produce the admirable R faq... Apologies in advance if there is already a mechanism like this, but help.search() didn't reveal anything. url:www.econ.uiuc.edu/~rogerRoger Koenker email [EMAIL PROTECTED] Department of Economics vox:217-333-4558University of Illinois fax:217-244-6678Champaign, IL 61820 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] faqs
Another possibility is to just place it at the end of the vignette. That is where it is in the proto package: http://cran.r-project.org/doc/vignettes/proto/proto.pdf Package documentation is already quite scattered and adding a faq() command would add just one more thing one has to do. Here are some places one might look already for documentation: package?mypackage vignette(...) library(help = mypackage) ?mycommand home page WISHLIST file NEWS file THANKS file svn log I personally would give a much higher priority to a standardized place to find change information. Some packages provide it. Some don't which is very frustrating since you see a new version and have no idea what has changed. If they do document it you often have to download the source just to get at the change information. On Nov 14, 2007 8:22 PM, roger koenker <[EMAIL PROTECTED]> wrote: > An extremely modest proposal: > > It would be nice if packages could have a FAQ and if > >faq(package.name) > > would produce this faq. And if, by default > >faq() >FAQ() > > would produce the admirable R faq... Apologies in advance > if there is already a mechanism like this, but help.search() > didn't reveal anything. > > url:www.econ.uiuc.edu/~rogerRoger Koenker > email [EMAIL PROTECTED] Department of Economics > vox:217-333-4558University of Illinois > fax:217-244-6678Champaign, IL 61820 > > __ > 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] Help about nnet library
Hello, First of all I am french, so please forgive me, if there are some big language mistakes in my sentences. I do not know if it is the good mail address to send my question, if not please tell me and forgive me, I have also sent this quetion to r-help, because the answer could be known from the programmers and the other R users :). I am working on a project, and I use the nnet library. Our customers do not want us to install R on their machine, so we just use R for making the training of our neurons network. This part is good and we have the weights for each neurons and each links. The neuron network we used is a very simple one : 4 inputs for *one linear output* unit with just one hidden layer (with 5 neurons) between the inputs and the ouputs. So in R it is translated by the following network : 4-5-1. We have also a decay of 0.3, but I do not think that fact interfers in our computation. And our problem is to recompute the output with those weights. When we program it or making the computation by hand, we do not find the same result than R. We check our program, we remake the computation by hand and we find always the same result. So one of our hypothesis is that, we do not use the good transfert function or the good activation function. For example for the neuron 1 of the hidden layer we have the weights as follows : b(which is I suppose the input set to one)->h1=w0 i1->h1=w1 i2->h1=w2 i3->h1=w3 i4->h1=w4 So first we make this computation : sum=w0 + i1*w1 + i2*w2 + i3*w3 + i4*w4 (the transfert function) And for computing h1 we use the classic sigmoid function : h1=1/(1+exp(-sum)). And for calculating the output we have those weights : b->o=wo0 i1->o=wo1 i2->o=wo2 i3->o=wo3 i4->o=wo4 h1->o=wo5 h2->o=wo6 h3->o=wo7 h4->o=wo8 h5->o=wo9 And the ouput is computed as follows : o=wo0+wo1*i1+wo2*i2+wo3*i3+wo4*i4+wo5*h1+wo6*h2+wo7*h3+wo8*h4+wo9*h5. So I would like to know, where is our error. Is it the sigmoid function that we used ? The transfert function ? Please answer me, I really need to know it. Thanks in advance. Pierre-Henri BUSSIERE -- Pierre-Henri BUSSIERE Ingénieur Informatique NUMTECH 6, allée Alan Turing Parc Technologique de la Pardieu BP 30242 63175 AUBIERE Cedex FRANCE Tél. 04.73.28.75.95 Fax. 04.73.28.75.99 [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] library path in Rd link
On 14/11/2007 7:44 PM, Gabor Grothendieck wrote: > On Nov 14, 2007 4:36 PM, Duncan Murdoch <[EMAIL PROTECTED]> wrote: >> On Unix-alikes, the workaround is to build soft links to all the >> packages in a standard location; but soft links don't work on Windows >> (and we don't want to get into the almost-undocumented hard links that >> exist on some Windows file systems). > > Symbolic links are available on Windows Vista: Does this work on FAT file systems, e.g. on a USB drive? It used to be that they only worked on NTFS. Duncan Murdoch > > C:\> mklink /? > Creates a symbolic link. > > MKLINK [[/D] | [/H] | [/J]] Link Target > > /D Creates a directory symbolic link. Default is a file > symbolic link. > /H Creates a hard link instead of a symbolic link. > /J Creates a Directory Junction. > Linkspecifies the new symbolic link name. > Target specifies the path (relative or absolute) that the new link > refers to. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] faqs
On 14/11/2007 8:53 PM, Gabor Grothendieck wrote: > Another possibility is to just place it at the end of the vignette. > That is where it is in the proto package: > > http://cran.r-project.org/doc/vignettes/proto/proto.pdf > > Package documentation is already quite scattered and adding > a faq() command would add just one more thing one has > to do. Here are some places one might look already for > documentation: > > package?mypackage Or just ?mypackage. Writing R Extensions recommends package?mypackage, with ?mypackage also working if that name isn't taken. However, the advice is ignored more than it is followed. > vignette(...) > library(help = mypackage) > ?mycommand > home page > WISHLIST file > NEWS file > THANKS file > svn log > > I personally would give a much higher priority to a standardized > place to find change information. Some packages provide it. > Some don't which is very frustrating since you see a new version > and have no idea what has changed. If they do document it you > often have to download the source just to get at the change information. Where do you put it? I put it in inst/ChangeLog, which ends up installed in the package root as ChangeLog. Whenever this has come up in the past, there have been several proposals, but no consensus. So, to encourage consensus, I've got a proposal: Why don't we vote on a location, with every voter agreeing to follow the majority? The only condition I'd put on it is that it should be something that gets installed, hence somewhere in inst, but I'd be happy to change the name if ChangeLog doesn't win. My vote is for inst/ChangeLog. Duncan Murdoch > > > > On Nov 14, 2007 8:22 PM, roger koenker <[EMAIL PROTECTED]> wrote: >> An extremely modest proposal: >> >> It would be nice if packages could have a FAQ and if >> >>faq(package.name) >> >> would produce this faq. And if, by default >> >>faq() >>FAQ() >> >> would produce the admirable R faq... Apologies in advance >> if there is already a mechanism like this, but help.search() >> didn't reveal anything. >> >> url:www.econ.uiuc.edu/~rogerRoger Koenker >> email [EMAIL PROTECTED] Department of Economics >> vox:217-333-4558University of Illinois >> fax:217-244-6678Champaign, IL 61820 >> >> __ >> 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] package installation order
Dirk Eddelbuettel <[EMAIL PROTECTED]> writes:
> When trying to package the by-now-gargantuan Rmetrics for Debian (which is
> still ongoing), I looked around for some Depends builders. Turns out that
> BioC has this. E.g. the following worked for:
>
> ## > install.packages("Biobase", repo="http://www.bioconductor.org";)
> ## > repos <- Biobase:::biocReposList()
> ## > install.packages("pkgDepTools", repos=repos["bioc"])
> ## > library(pkgDepTools)
> ## Loading required package: graph
> ## Loading required package: RBGL
> ## > CRANdeps <- makeDepGraph(repos["cran"], type="source")
> ## > getInstallOrder("Rmetrics", CRANdeps, needed.only=FALSE)
>
> worked for me. I meant to add some code for Graphviz visualization (or look
> for it, Seth et al probably already wrote it) but what you get from
> getInstallOrder() should suit your needs here.
makeDepGraph returns a graphNEL instance and Rgraphviz knows how to
plot those. The entire graph will likely not produce a particularly
compelling visualization. But you can subset the graph according to a
particular package's dependencies, etc.
+ seth
--
Seth Falcon | [EMAIL PROTECTED] | blog: http://userprimary.net/user/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] isOpen on closed connections
"Roger D. Peng" <[EMAIL PROTECTED]> writes:
> As far as I can tell, 'isOpen' cannot return FALSE in the case when 'rw =
> ""'.
> If the connection has already been closed by 'close' or some other function,
> then isOpen will produce an error. The problem is that when isOpen calls
> 'getConnection', the connection cannot be found and 'getConnection' produces
> an
> error. The check to see if it is open is never actually done.
I see this too with R-devel (r43376) {from Nov 6th}.
con = file("example1", "w")
isOpen(con)
[1] TRUE
showConnections()
description class mode text isopen can read can write
3 "example1" "file" "w" "text" "opened" "no" "yes"
close(con)
isOpen(con)
Error in isOpen(con) : invalid connection
## printing also fails
con
Error in summary.connection(x) : invalid connection
> This came up in some code where I'm trying to clean up connections after
> successfully opening them. The problem is that if I try to close a
> connection
> that has already been closed, I get an error (because 'getConnection' cannot
> find it). But then there's no way for me to find out if a connection has
> already been closed. Perhaps there's another approach I should be taking?
> The
> context is basically,
>
> con <- file("foo", "w")
>
> tryCatch({
> ## Do stuff that might fail
> writeLines(stuff, con)
> close(con)
>
> file.copy("foo", "bar")
> }, finally = {
> close(con)
> })
This doesn't address isOpen, but why do you have the call to close
inside the tryCatch block? Isn't the idea that finally will always be
run and so you can be reasonably sure that close gets called once?
If your real world code is more complicated, perhaps you can make use
of a work around like:
myIsOpen = function(con) tryCatch(isOpen(con), error=function(e) FALSE)
You could do similar with myClose and "close" a connection as many
times as you'd like :-)
+ seth
--
Seth Falcon | [EMAIL PROTECTED] | blog: http://userprimary.net/user/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] faqs
inst/NEWS would have the advantage of consistency with R itself which also has a NEWS file. On Nov 14, 2007 10:15 PM, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > On 14/11/2007 8:53 PM, Gabor Grothendieck wrote: > > Another possibility is to just place it at the end of the vignette. > > That is where it is in the proto package: > > > > http://cran.r-project.org/doc/vignettes/proto/proto.pdf > > > > Package documentation is already quite scattered and adding > > a faq() command would add just one more thing one has > > to do. Here are some places one might look already for > > documentation: > > > > package?mypackage > > Or just ?mypackage. Writing R Extensions recommends package?mypackage, > with ?mypackage also working if that name isn't taken. However, the > advice is ignored more than it is followed. > > > vignette(...) > > library(help = mypackage) > > ?mycommand > > home page > > WISHLIST file > > NEWS file > > THANKS file > > svn log > > > > I personally would give a much higher priority to a standardized > > place to find change information. Some packages provide it. > > Some don't which is very frustrating since you see a new version > > and have no idea what has changed. If they do document it you > > often have to download the source just to get at the change information. > > Where do you put it? I put it in inst/ChangeLog, which ends up > installed in the package root as ChangeLog. > > Whenever this has come up in the past, there have been several > proposals, but no consensus. So, to encourage consensus, I've got a > proposal: > > Why don't we vote on a location, with every voter agreeing to follow the > majority? The only condition I'd put on it is that it should be > something that gets installed, hence somewhere in inst, but I'd be happy > to change the name if ChangeLog doesn't win. > > My vote is for inst/ChangeLog. > > Duncan Murdoch > > > > > > > > > > On Nov 14, 2007 8:22 PM, roger koenker <[EMAIL PROTECTED]> wrote: > >> An extremely modest proposal: > >> > >> It would be nice if packages could have a FAQ and if > >> > >>faq(package.name) > >> > >> would produce this faq. And if, by default > >> > >>faq() > >>FAQ() > >> > >> would produce the admirable R faq... Apologies in advance > >> if there is already a mechanism like this, but help.search() > >> didn't reveal anything. > >> > >> url:www.econ.uiuc.edu/~rogerRoger Koenker > >> email [EMAIL PROTECTED] Department of Economics > >> vox:217-333-4558University of Illinois > >> fax:217-244-6678Champaign, IL 61820 > >> > >> __ > >> 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 > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] isOpen on closed connections
I think the confusion here is over close(): that closes *and destroys* a
connection, so it no longer exists.
isOpen applies to existing connections: you cannot close but not destroy
them at R level, but C code can (and does). You will see it in use in the
utils package.
On Wed, 14 Nov 2007, Seth Falcon wrote:
> "Roger D. Peng" <[EMAIL PROTECTED]> writes:
>
>> As far as I can tell, 'isOpen' cannot return FALSE in the case when 'rw =
>> ""'.
>> If the connection has already been closed by 'close' or some other function,
>> then isOpen will produce an error. The problem is that when isOpen calls
>> 'getConnection', the connection cannot be found and 'getConnection' produces
>> an
>> error. The check to see if it is open is never actually done.
>
> I see this too with R-devel (r43376) {from Nov 6th}.
>
>con = file("example1", "w")
>isOpen(con)
>
>[1] TRUE
>
>showConnections()
>
> description class mode text isopen can read can write
>3 "example1" "file" "w" "text" "opened" "no" "yes"
>
>close(con)
>isOpen(con)
>
>Error in isOpen(con) : invalid connection
>
>## printing also fails
>con
>Error in summary.connection(x) : invalid connection
>
>> This came up in some code where I'm trying to clean up connections after
>> successfully opening them. The problem is that if I try to close a
>> connection
>> that has already been closed, I get an error (because 'getConnection' cannot
>> find it). But then there's no way for me to find out if a connection has
>> already been closed. Perhaps there's another approach I should be taking?
>> The
>> context is basically,
>>
>> con <- file("foo", "w")
>>
>> tryCatch({
>> ## Do stuff that might fail
>> writeLines(stuff, con)
>> close(con)
>>
>> file.copy("foo", "bar")
>> }, finally = {
>> close(con)
>> })
>
> This doesn't address isOpen, but why do you have the call to close
> inside the tryCatch block? Isn't the idea that finally will always be
> run and so you can be reasonably sure that close gets called once?
>
> If your real world code is more complicated, perhaps you can make use
> of a work around like:
>
> myIsOpen = function(con) tryCatch(isOpen(con), error=function(e) FALSE)
>
> You could do similar with myClose and "close" a connection as many
> times as you'd like :-)
>
> + seth
>
>
--
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
