Re: [Rd] constrOptim( ): conflict between help page and code
John Nolan wrote:
There is a contradiction between what the help page says and what constrOptim
actually
does with the constraints. The issue is what happens on the boundary.
I don't know if this was a recent change, but the current help says:
"The starting value must be in the interior of the feasible region, but
the minimum may be on the boundary."
The boundary is not in the interior.
Duncan Murdoch
The help page says
The feasible region is defined by ‘ui %*% theta - ci >= 0’,
but the R code for constrOptim reads
if (any(ui %*% theta - ci <= 0))
stop("initial value not feasible")
The following example shows that when the initial point is on the boundary of
the
feasibility region, you get the above error message and execution stops.
fn <- function(x) { return(sum(x)) }
ui <- diag(rep(1,2))
ci <- matrix(0,nrow=2,ncol=1)
constrOptim( c(0,0), fn, NULL, ui, ci )
Error in optim(theta.old, fun, gradient, control = control, method = method, :
function cannot be evaluated at initial parameters
version
platform i386-pc-mingw32
arch i386
os mingw32
system i386, mingw32
status
major 2
minor 10.0
year 2009
month 10
day26
svn rev50208
language R
version.string R version 2.10.0 (2009-10-26)
In contrast, at a different place in constrOptim - the internal function R -
the boundary of the feasibility region is allowed: if (any(gi < 0))
return(NaN),
and it seems to explicitly allow boundaries at another place:
allowing gi==0 and interpreting log(gi) as -Inf.
John
...
John P. Nolan
Math/Stat Department
227 Gray Hall
American University
4400 Massachusetts Avenue, NW
Washington, DC 20016-8050
jpno...@american.edu
202.885.3140 voice
202.885.3155 fax
http://academic2.american.edu/~jpnolan
...
__
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 development process?
I agree with Hadley, and add that trying to have an example be both an example and a test may not be good for the example aspect either. Examples should make people who are ignorant of the function twig as to how the function works. Creating good examples is hard. Problems that really test the software are unlikely to serve as a good example. Good examples are unlikely to seriously test the code. (But you do want the examples to run, it is seriously bad advertising when they don't.) Pat On 16/06/2010 15:53, Hadley Wickham wrote: What about the encouragement to add unit tests, if only disguised as examples? Examples are not unit tests. Examples are a convenient way of testing some aspects of the package, but serve a rather different purpose to tests. The R community does not emphase testing nearly as much as other communities. For example, Ruby has a very strong testing culture including at least 10 different unit testing frameworks. I've found the unit tests to be a powerful tool to help improve and maintain the quality of packages to which I contribute. To this end, Sundar and I added a column "Autochecks" to the table of "Selected Repositories" in the Wikipedia article on "Software repository" (http://en.wikipedia.org/wiki/Software_repository), and we describe it briefly in the text introducing that table. Unfortunately your description highlights a inadequacy of R and poor software development procedures on the part of many R package developers (including me!). For exactly the reason you discuss, it's never a good idea for your package to depend on the most current version of another package. If you do, changes to that package might break yours. Most other package management systems allow you to specify the version of a dependency so that this doesn't happen. You can do this with R, but because it's hard to have multiple versions of the same package installed at the same time, it's not as useful. Hadley -- Patrick Burns pbu...@pburns.seanet.com http://www.burns-stat.com (home of 'Some hints for the R beginner' and 'The R Inferno') __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Package development process?
On Thu, Jun 17, 2010 at 5:22 AM, Patrick Burns wrote: > I agree with Hadley, and add that trying > to have an example be both an example and > a test may not be good for the example > aspect either. > > Examples should make people who are ignorant > of the function twig as to how the function > works. Creating good examples is hard. > > Problems that really test the software are > unlikely to serve as a good example. Good > examples are unlikely to seriously test the > code. (But you do want the examples to run, > it is seriously bad advertising when they > don't.) > > Pat Creating good examples is hard, but so is creating a research compendium following the ideas of Reproducible Research of Donoho and others at Stanford, called Literate Statistical Practice in the statistical community. The tools are there in R for this purpose (vignettes, etc.) but they seem to be rarely used for this purpose. One reason examples are hard is that they are often isolated from the research itself, and hard to understand out of context. The notion of a Research Compendium that includes this context might help. But this requires a fair amount of work, and I don't think it is currently rewarded in the publication process (Journals do not require it). The creation of a research compendium can be viewed as a form of unit testing, and the fact that R has powerful tools that support this process (Sweave) could be viewed as one of its outstanding features (relating these comments back to the topic of this thread). A list of references on Reproducible Research and LSP can be found in the package cxxPack. A template for creating a compendium can also be found there. Dominick [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Corrections for the R manual on Solaris
There are a few errors in the R manual about Solaris. 1) Firstly you may know that Sun is now owned by Oracle. 2) "(Recent Sun machines are Opterons (‘amd64’) rather than ‘x86’, but 32-bit ‘x86’ executables are the default.) " It's not true to say that recent machines are Opterons rather than x86. Many new Sun machines are based on 64-bit Intel CPUs (often called x64). The machine I'm using, a Sun Ultra 27 http://www.sun.com/desktop/workstation/ultra27/index.xml is less than 6 months old and has a quad core 3.33 GHz Intel Xeon in it. It is certainly true that some recent machine are Opterons. Note, 64-bit libraries for 64-bit systems, even those based on Intel CPUs, go in /usr/lib/amd64. Likewise many open-source software will install the 64-bit libraries in /usr/local/lib/amd64. There's no "intel64" or anything like that. 3) "Modern Solaris systems allow a large selection of Open Source software to be installed from http://www.opencsw.org (formerly http://www.blastwave.org) via pkg-get, " It should be noted that OpenCSW and Blastwave are both still in existence. There's a lot of animosity between the two camps, but both do exist. So one is not formally the other. Unfortunately, they both install software in /opt/csw, so I would be very weary of using both sites, as there is no coordination between them. Dave __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Package development process?
> The creation of a research compendium can be viewed as > a form of unit testing, and the fact that R has powerful tools > that support this process (Sweave) could be viewed as one of > its outstanding features (relating these comments back to > the topic of this thread). If anything, a research compendium would be an integration test, not a compendium. And many programming languages have something similar to sweave. Hadley -- Assistant Professor / Dobelman Family Junior Chair Department of Statistics / Rice University http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] constrOptim( ): conflict between help page and code
Nolan,
You are correct that there is inconsistency. The feasible region should be ui
%*% theta - ci > 0, so that log(ui %*% theta - ci) is defined.
There is a more serious problem in termination criterion for iterations:
if (is.finite(r) && is.finite(r.old) && abs(r - r.old)/(outer.eps +
abs(r - r.old)) < outer.eps)
break
Ideally convergence is achieved when |r - r.old| is small. But according to
the above code, the logical condition inside the if(.) will be TRUE only when
abs(r - r.old) < (outer.eps)^2 (for small outer.eps). For example, let |r -
r.old| = outer.eps. The above condition becomes: if (0.5 < outer.eps) break,
which will obviously never happen for values of outer.eps < 1/2. Now, if
outer.eps = 1.e-05 (default) and we let |r - r.old| <= 1.e-10, then the above
condition will be satisfied.
In short, the termination criterion used is too stringent. Better termination
criteria are:
if (is.finite(r) && is.finite(r.old) && abs(r - r.old) < outer.eps)
break
or
if (is.finite(r) && is.finite(r.old) && abs(r - r.old)/(1 + abs(r +
r.old)/2) < outer.eps) break
Best,
Ravi.
-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On
Behalf Of Duncan Murdoch
Sent: Thursday, June 17, 2010 4:38 AM
To: John Nolan
Cc: r-devel@r-project.org
Subject: Re: [Rd] constrOptim( ): conflict between help page and code
John Nolan wrote:
> There is a contradiction between what the help page says and what constrOptim
> actually
> does with the constraints. The issue is what happens on the boundary.
>
I don't know if this was a recent change, but the current help says:
"The starting value must be in the interior of the feasible region, but
the minimum may be on the boundary."
The boundary is not in the interior.
Duncan Murdoch
> The help page says
> The feasible region is defined by ‘ui %*% theta - ci >= 0’,
> but the R code for constrOptim reads
> if (any(ui %*% theta - ci <= 0))
> stop("initial value not feasible")
> The following example shows that when the initial point is on the boundary of
> the
> feasibility region, you get the above error message and execution stops.
>
>
>> fn <- function(x) { return(sum(x)) }
>>
>> ui <- diag(rep(1,2))
>> ci <- matrix(0,nrow=2,ncol=1)
>> constrOptim( c(0,0), fn, NULL, ui, ci )
>>
> Error in optim(theta.old, fun, gradient, control = control, method = method,
> :
> function cannot be evaluated at initial parameters
>
>> version
>>
> platform i386-pc-mingw32
> arch i386
> os mingw32
> system i386, mingw32
> status
> major 2
> minor 10.0
> year 2009
> month 10
> day26
> svn rev50208
> language R
> version.string R version 2.10.0 (2009-10-26)
>
> In contrast, at a different place in constrOptim - the internal function R -
> the boundary of the feasibility region is allowed: if (any(gi < 0))
> return(NaN),
> and it seems to explicitly allow boundaries at another place:
> allowing gi==0 and interpreting log(gi) as -Inf.
>
>
> John
>
> ...
>
> John P. Nolan
> Math/Stat Department
> 227 Gray Hall
> American University
> 4400 Massachusetts Avenue, NW
> Washington, DC 20016-8050
>
> jpno...@american.edu
> 202.885.3140 voice
> 202.885.3155 fax
> http://academic2.american.edu/~jpnolan
> ...
> __
> 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] constrOptim( ): conflict between help page and code
In `constrOptim', there is also a mistake in the reporting of function and
gradient counts. These counts, as reported, correspond to that of the vary
last "inner" iteration. However, they should be cumulatively summed up over
each outer iteration.
I have fixed this and the convergence criterion issue that I mentioned before.
Currently, constrOptim can only use the Nelder-Mead when the analytic gradient
is not specified. I have added a numerical gradient option so that it can use
BFGS or other optimization functions even when the analytic gradient is not
specified.
It would be desirable if Tom Lumley can commit these changes to constrOptim.
In the meanwhile, I can send the function with these upgrades to anyone who is
interested.
Best,
Ravi.
-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On
Behalf Of Ravi Varadhan
Sent: Thursday, June 17, 2010 9:53 AM
To: 'Duncan Murdoch'; 'John Nolan'
Cc: r-devel@r-project.org
Subject: Re: [Rd] constrOptim( ): conflict between help page and code
Nolan,
You are correct that there is inconsistency. The feasible region should be ui
%*% theta - ci > 0, so that log(ui %*% theta - ci) is defined.
There is a more serious problem in termination criterion for iterations:
if (is.finite(r) && is.finite(r.old) && abs(r - r.old)/(outer.eps +
abs(r - r.old)) < outer.eps)
break
Ideally convergence is achieved when |r - r.old| is small. But according to
the above code, the logical condition inside the if(.) will be TRUE only when
abs(r - r.old) < (outer.eps)^2 (for small outer.eps). For example, let |r -
r.old| = outer.eps. The above condition becomes: if (0.5 < outer.eps) break,
which will obviously never happen for values of outer.eps < 1/2. Now, if
outer.eps = 1.e-05 (default) and we let |r - r.old| <= 1.e-10, then the above
condition will be satisfied.
In short, the termination criterion used is too stringent. Better termination
criteria are:
if (is.finite(r) && is.finite(r.old) && abs(r - r.old) < outer.eps)
break
or
if (is.finite(r) && is.finite(r.old) && abs(r - r.old)/(1 + abs(r +
r.old)/2) < outer.eps) break
Best,
Ravi.
-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On
Behalf Of Duncan Murdoch
Sent: Thursday, June 17, 2010 4:38 AM
To: John Nolan
Cc: r-devel@r-project.org
Subject: Re: [Rd] constrOptim( ): conflict between help page and code
John Nolan wrote:
> There is a contradiction between what the help page says and what constrOptim
> actually
> does with the constraints. The issue is what happens on the boundary.
>
I don't know if this was a recent change, but the current help says:
"The starting value must be in the interior of the feasible region, but
the minimum may be on the boundary."
The boundary is not in the interior.
Duncan Murdoch
> The help page says
> The feasible region is defined by ‘ui %*% theta - ci >= 0’,
> but the R code for constrOptim reads
> if (any(ui %*% theta - ci <= 0))
> stop("initial value not feasible")
> The following example shows that when the initial point is on the boundary of
> the
> feasibility region, you get the above error message and execution stops.
>
>
>> fn <- function(x) { return(sum(x)) }
>>
>> ui <- diag(rep(1,2))
>> ci <- matrix(0,nrow=2,ncol=1)
>> constrOptim( c(0,0), fn, NULL, ui, ci )
>>
> Error in optim(theta.old, fun, gradient, control = control, method = method,
> :
> function cannot be evaluated at initial parameters
>
>> version
>>
> platform i386-pc-mingw32
> arch i386
> os mingw32
> system i386, mingw32
> status
> major 2
> minor 10.0
> year 2009
> month 10
> day26
> svn rev50208
> language R
> version.string R version 2.10.0 (2009-10-26)
>
> In contrast, at a different place in constrOptim - the internal function R -
> the boundary of the feasibility region is allowed: if (any(gi < 0))
> return(NaN),
> and it seems to explicitly allow boundaries at another place:
> allowing gi==0 and interpreting log(gi) as -Inf.
>
>
> John
>
> ...
>
> John P. Nolan
> Math/Stat Department
> 227 Gray Hall
> American University
> 4400 Massachusetts Avenue, NW
> Washington, DC 20016-8050
>
> jpno...@american.edu
> 202.885.3140 voice
> 202.885.3155 fax
> http://academic2.american.edu/~jpnolan
> ...
>
Re: [Rd] Package development process?
On Thu, Jun 17, 2010 at 9:23 AM, Hadley Wickham wrote: > > The creation of a research compendium can be viewed as > > a form of unit testing, and the fact that R has powerful tools > > that support this process (Sweave) could be viewed as one of > > its outstanding features (relating these comments back to > > the topic of this thread). > > If anything, a research compendium would be an integration test, not a > compendium. And many programming languages have something similar to > sweave. > > Yes, but I think this is where "R CMD check" shines (and also shows its limitations). Many languages include optional or advisory features, like adding documentation to source code! But R CMD check gently nudges packages developers to actually add documentation for every R function, and the documentation format is well-defined, etc. Unfortunately, it says nothing about modules written in other languages. On your comment about integration testing, I use vignettes to keep track of the mathematics of models that I build, along with quick tests of these models, somewhat like a Mathematica notebook. This can be viewed as a form of "literate unit testing." [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] constrOptim( ): conflict between help page and code
One more bug in `constrOptim' that I have reported before and have also
suggested a fix, but this has also not been corrected:
if (obj > obj.old) break
This is obviously wrong when the user is trying to maximize by specifying
control$fnscale = -1.
The correct statement is the following:
if (obj > obj.old * sign(mu)) break
Ravi.
-Original Message-
From: Ravi Varadhan [mailto:rvarad...@jhmi.edu]
Sent: Thursday, June 17, 2010 10:55 AM
To: 'Ravi Varadhan'; 'Duncan Murdoch'; 'John Nolan'
Cc: 'r-devel@r-project.org'
Subject: RE: [Rd] constrOptim( ): conflict between help page and code
In `constrOptim', there is also a mistake in the reporting of function and
gradient counts. These counts, as reported, correspond to that of the vary
last "inner" iteration. However, they should be cumulatively summed up over
each outer iteration.
I have fixed this and the convergence criterion issue that I mentioned before.
Currently, constrOptim can only use the Nelder-Mead when the analytic gradient
is not specified. I have added a numerical gradient option so that it can use
BFGS or other optimization functions even when the analytic gradient is not
specified.
It would be desirable if Tom Lumley can commit these changes to constrOptim.
In the meanwhile, I can send the function with these upgrades to anyone who is
interested.
Best,
Ravi.
-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On
Behalf Of Ravi Varadhan
Sent: Thursday, June 17, 2010 9:53 AM
To: 'Duncan Murdoch'; 'John Nolan'
Cc: r-devel@r-project.org
Subject: Re: [Rd] constrOptim( ): conflict between help page and code
Nolan,
You are correct that there is inconsistency. The feasible region should be ui
%*% theta - ci > 0, so that log(ui %*% theta - ci) is defined.
There is a more serious problem in termination criterion for iterations:
if (is.finite(r) && is.finite(r.old) && abs(r - r.old)/(outer.eps +
abs(r - r.old)) < outer.eps)
break
Ideally convergence is achieved when |r - r.old| is small. But according to
the above code, the logical condition inside the if(.) will be TRUE only when
abs(r - r.old) < (outer.eps)^2 (for small outer.eps). For example, let |r -
r.old| = outer.eps. The above condition becomes: if (0.5 < outer.eps) break,
which will obviously never happen for values of outer.eps < 1/2. Now, if
outer.eps = 1.e-05 (default) and we let |r - r.old| <= 1.e-10, then the above
condition will be satisfied.
In short, the termination criterion used is too stringent. Better termination
criteria are:
if (is.finite(r) && is.finite(r.old) && abs(r - r.old) < outer.eps)
break
or
if (is.finite(r) && is.finite(r.old) && abs(r - r.old)/(1 + abs(r +
r.old)/2) < outer.eps) break
Best,
Ravi.
-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On
Behalf Of Duncan Murdoch
Sent: Thursday, June 17, 2010 4:38 AM
To: John Nolan
Cc: r-devel@r-project.org
Subject: Re: [Rd] constrOptim( ): conflict between help page and code
John Nolan wrote:
> There is a contradiction between what the help page says and what constrOptim
> actually
> does with the constraints. The issue is what happens on the boundary.
>
I don't know if this was a recent change, but the current help says:
"The starting value must be in the interior of the feasible region, but
the minimum may be on the boundary."
The boundary is not in the interior.
Duncan Murdoch
> The help page says
> The feasible region is defined by ‘ui %*% theta - ci >= 0’,
> but the R code for constrOptim reads
> if (any(ui %*% theta - ci <= 0))
> stop("initial value not feasible")
> The following example shows that when the initial point is on the boundary of
> the
> feasibility region, you get the above error message and execution stops.
>
>
>> fn <- function(x) { return(sum(x)) }
>>
>> ui <- diag(rep(1,2))
>> ci <- matrix(0,nrow=2,ncol=1)
>> constrOptim( c(0,0), fn, NULL, ui, ci )
>>
> Error in optim(theta.old, fun, gradient, control = control, method = method,
> :
> function cannot be evaluated at initial parameters
>
>> version
>>
> platform i386-pc-mingw32
> arch i386
> os mingw32
> system i386, mingw32
> status
> major 2
> minor 10.0
> year 2009
> month 10
> day26
> svn rev50208
> language R
> version.string R version 2.10.0 (2009-10-26)
>
> In contrast, at a different place in constrOptim - the internal function R -
> the boundary of the feasi
Re: [Rd] Package development process?
On Thu, Jun 17, 2010 at 7:45 AM, Dominick Samperi wrote: > > On Thu, Jun 17, 2010 at 5:22 AM, Patrick Burns > wrote: > > > I agree with Hadley, and add that trying > > to have an example be both an example and > > a test may not be good for the example > > aspect either. > > > > Examples should make people who are ignorant > > of the function twig as to how the function > > works. Creating good examples is hard. > > > > Problems that really test the software are > > unlikely to serve as a good example. Good > > examples are unlikely to seriously test the > > code. (But you do want the examples to run, > > it is seriously bad advertising when they > > don't.) > > > > Pat > > > Creating good examples is hard, but so is creating a research > compendium following the ideas of Reproducible Research of > Donoho and others at Stanford, called Literate Statistical > Practice in the statistical community. The tools are there in > R for this purpose (vignettes, etc.) but they seem to be rarely > used for this purpose. > "Rare" is vague. Almost every software package in the Bioconductor repository has a vignette; the informal advice to contributors is that the vignette should take the reader through all the steps of a substantively interesting analysis with motivating/explanatory prose and executable code. Many analysis processes rely on effective interoperability with independently maintained packages; thus the nightly building of all vignettes in Bioconductor serves to not only to provide some evidence of package soundness but also some degree of notification of decays of interoperability. The main Bioconductor monograph, and the case studies book are both executable documents, written with Sweave. I would imagine that a number of other UseR titles were composed in this way. A recent NSF workshop addressed frameworks for creating replayable experiments in various fields: https://www.protogeni.net/trac/archive10/ > > One reason examples are hard is that they are often isolated > from the research itself, and hard to understand out of context. > The notion of a Research Compendium that includes this > context might help. > > But this requires a fair amount of work, and I don't think it is > currently rewarded in the publication process (Journals do not > require it). > > The creation of a research compendium can be viewed as > a form of unit testing, and the fact that R has powerful tools > that support this process (Sweave) could be viewed as one of > its outstanding features (relating these comments back to > the topic of this thread). > > A list of references on Reproducible Research and LSP > can be found in the package cxxPack. A template for creating > a compendium can also be found there. > > Dominick > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Package development process?
On Thu, Jun 17, 2010 at 5:01 PM, Vincenzo Carey wrote: > > "Rare" is vague. Almost every software package in the Bioconductor > repository has a vignette; the informal advice to contributors is that > the vignette should take the reader through all the steps of a > substantively interesting analysis with motivating/explanatory prose > and executable code. Many analysis processes rely on effective > interoperability with independently maintained packages; thus the > nightly building of all vignettes in Bioconductor serves to not only > to provide some evidence of package soundness but also some degree of > notification of decays of interoperability. The main Bioconductor > monograph, and the case studies book are both executable documents, > written with Sweave. I would imagine that a number of other UseR > titles were composed in this way. > Thanks for the pointers. I'm a bit confused by the relationship between CRAN and Bioconductor? I have seem some packages removed from CRAN and moved to Bioconductor, for example. I think Bioconductor focuses on genetics and related statistical problems, but there also seems to be separate processes, separate repositories, etc., and it includes packages that are not specific to the biological sciences. [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CHM help does not find help docs in package stats
Indeed, the R version is 2.9.2. But the package was built on the very same system. Besides, another package built with the same version of R but on another machine does not show this nasty behavior. Upgrading, however, could pose more problems as it solves, since even if I could upgrade locally, it would be a mess to assure that all colleagues upgrade as well. Anyways, even if the chm format is not supported any more by current versions of R, it should work with older ones, right? So, what can I do additionally to get to the bottom of this problem? Thanks + BR, Thorn -Original Message- From: Uwe Ligges [mailto:lig...@statistik.tu-dortmund.de] Sent: samedi 12 juin 2010 18:21 To: Thaler,Thorn,LAUSANNE,Applied Mathematics Cc: r-devel@r-project.org Subject: Re: [Rd] CHM help does not find help docs in package stats Which version of R is this? CHM help is R < 2.10.0. All versions thereafter do not support compiled html help anymore. Please upgrade your version of R and try one of the currently supported help formats. Best wishes, Uwe Ligges On 11.06.2010 12:06, Thaler, Thorn, LAUSANNE, Applied Mathematics wrote: > Hi all, > > currently I'm working on an R package bundling some frequently used > functions. When I load my package and type > > ?one_of_my_functions > > I get the particular help file. If I try to get help on another > function, which is part of package stats (prcomp say), I get "This > program cannot display the webpage". A help on ?mean does, however, work > as it opens a new window showing the help on mean. > > There is another peculiarity, if it happens that I requested a help file > for a function in the package stats before I used the help on one of my > functions, everything works out fine. > > Does anybody know how I can get rid of this annoying behavior? It has to > have something to do with my particular package, since everything works > as expected with another package of mine. > > I override one of the functions of stats (biplot.default), which is, > however, not exported and resides within my namespace. Could that be the > reason? > > Any help highly appreciated. Thanks + BR, > > Thorn > > __ > 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
