[Rd] nls with algorithm = "port", starting values
The documentation for nls says the following about the starting values:
start: a named list or named numeric vector of starting estimates.
Since R 2.4.0, when 'start' is missing, a very cheap guess
for 'start' is tried (if 'algorithm != "plinear"').
It may be a good idea to document that when algorithm = "port", if start
is a named list, the elements of the list must be numeric vectors of
length 1. Ie, start = list(a=1,b=2,c=3) is ok, but start = list(a=c(1,2),
b=3) is not. This is not the case when algorithm is "plinear" or the
default GN, and is because of the way that the "port" code in nls.R
transforms the starting values (the other options do something else):
nls_port_fit <- function(m, start, lower, upper, control, trace)
{
## Establish the working vectors and check and set options
p <- length(par <- as.double(start))
Example:
## exponentially decaying data
getExpmat <- function(theta, t)
{
conc <- matrix(nrow = length(t), ncol = length(theta))
for(i in 1:length(theta)) {
conc[, i] <- exp(- theta[i] * t)
}
conc
}
expsum <- as.vector(getExpmat(c(.05,.005), 1:100) %*% c(1,1))
expsumNoisy <- expsum + max(expsum) *.001 * rnorm(100)
expsum.df <-data.frame(expsumNoisy)
## estimate decay rates, amplitudes with default Gauss-Newton
summary (nls(expsumNoisy ~ getExpmat(k, 1:100) %*% sp, expsum.df, start =
list(k = c(.6,.02), sp = c(1,2)), trace=TRUE, control =
nls.control(maxiter=20,
warnOnly = TRUE)))
## won't work with port
summary (nls(expsumNoisy ~ getExpmat(k, 1:100) %*% sp, expsum.df, start =
list(k = c(.6,.02), sp = c(1,2)), algorithm = "port",
trace=TRUE, control = nls.control(maxiter=20,
warnOnly = TRUE)))
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Sweave.sh shell script on CRAN
Dear developeRs, Martin Maechler has suggested that I resend this email to R-devel instead to R-packages for further comments and potential availability for Windows. -- I have uploaded my Sweave (bash) shell script on CRAN. It is available at http://cran.r-project.org/contrib/extra/scripts/ In short this script runs Sweave on given Rnw file(s) and post process produced tex file(s) with LaTeX and friends directly from command line. It has quite a rich set of command line options to mainly ease the LaTeX compilation. Please do not hesitate to contact me in case you find errors or have suggestions and/or code contributions. I am particularly, interested in making this script work under Windows. -- I do not have any experience with use of (bash) shell scripts under Windows. Sweave.sh can be used with Cygwin, but I am not sure how to use shell script without Cygwin. I noticed that some "scripts" in R*/bin directory on our Windows machine are perl (build, check, INSTALL, ...) and shell (Rd2dvi.sh, Stangle.sh, Sweave.sh, ...) scripts. This therefore means that R ships also perl and shell interpreter or am I missing something? Thanks! -- Lep pozdrav / With regards, Gregor Gorjanc -- University of Ljubljana PhD student Biotechnical Facultywww: http://www.bfro.uni-lj.si/MR/ggorjan Zootechnical Department blog: http://ggorjan.blogspot.com Groblje 3 mail: gregor.gorjanc bfro.uni-lj.si SI-1230 Domzale fax: +386 (0)1 72 17 888 Slovenia, Europetel: +386 (0)1 72 17 861 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] how to control which version of a package library() installs?
Prof Brian Ripley wrote: > > We should try to explain this, but there is another level of complexity. > If a package has compiled code, unloading the namespace is unlikely to > unload the DLL (it would need to be done explicitly in .onUnload). > And even then, as I understand it there are OSes on which you cannot > really unload DLLs, and certainly cannot load another DLL of the same name > into the process: you get the previously loaded one. On this, I am quite sure I have managed to crash wine on linux by dyn.load() an updated version of a DLL of the same name with win32 R in wine. It is obviously a useful thing to be able to change the source, re-compile it, and load a new version into R, so that's why I did it, I think. (and it does work with native R on linux). Genuine windows may or may not crash, but I don't usually sit in front of windows for development... HTL __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sweave.sh shell script on CRAN
On 4/16/2007 7:01 AM, Gregor Gorjanc wrote: > Dear developeRs, > > Martin Maechler has suggested that I resend this email to R-devel > instead to R-packages for further comments and potential availability > for Windows. > > -- > > I have uploaded my Sweave (bash) shell script on CRAN. It is available at > > http://cran.r-project.org/contrib/extra/scripts/ > > In short this script runs Sweave on given Rnw file(s) and post process > produced tex file(s) with LaTeX and friends directly from command line. > It has quite a rich set of command line options to mainly ease the LaTeX > compilation. > > Please do not hesitate to contact me in case you find errors or have > suggestions and/or code contributions. I am particularly, interested in > making this script work under Windows. > > -- > > I do not have any experience with use of (bash) shell scripts under > Windows. Sweave.sh can be used with Cygwin, but I am not sure how to use > shell script without Cygwin. I noticed that some "scripts" in R*/bin > directory on our Windows machine are perl (build, check, INSTALL, ...) > and shell (Rd2dvi.sh, Stangle.sh, Sweave.sh, ...) scripts. This > therefore means that R ships also perl and shell interpreter or am I > missing something? We don't ship Perl or sh.exe, but we do describe how to get them in the R Admin manual. I'd be interested in talking to you about integration of my patchDVI functions into your script. They allow forward and reverse search between the .dvi file and the .Rnw file (in yap and xdvi, at least). Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sweave.sh shell script on CRAN
Duncan Murdoch wrote: >> I do not have any experience with use of (bash) shell scripts under >> Windows. Sweave.sh can be used with Cygwin, but I am not sure how to use >> shell script without Cygwin. I noticed that some "scripts" in R*/bin >> directory on our Windows machine are perl (build, check, INSTALL, ...) >> and shell (Rd2dvi.sh, Stangle.sh, Sweave.sh, ...) scripts. This >> therefore means that R ships also perl and shell interpreter or am I >> missing something? > > We don't ship Perl or sh.exe, but we do describe how to get them in the > R Admin manual. Maybe I got this totally wrong. Say someone who uses Windows finds R and installs it via setup file. Can he/she launch the folowing without having Perl and/or sh.exe? R CMD script whateverOption > I'd be interested in talking to you about integration of my patchDVI > functions into your script. They allow forward and reverse search > between the .dvi file and the .Rnw file (in yap and xdvi, at least). I am all ears. Gregor __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sweave.sh shell script on CRAN
On Windows sweave.bat is a Windows XP batchfile that will run sweave and then latex and then display the file on screen. Issuing the command sweave without args from the Windows command line gives info on how to use it. The batchfiles home page is: http://code.google.com/p/batchfiles/ The public svn for batchfiles is there and there is also a link there to CRAN where the distribution itself is located. There is some info in the README file and also if you issue the command sweave without args it gives instructions on use. To install sweave.bat you must place sweave.bat (and Rcmd.bat) both from this batchfiles distribution anywhere in your path. It does not require sh.exe and does not make use of perl but does use "Rcmd sweave" so would have no prerequisites beyond latex, Acrobot (or other viewer) and those of Rcmd. On 4/16/07, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > On 4/16/2007 7:01 AM, Gregor Gorjanc wrote: > > Dear developeRs, > > > > Martin Maechler has suggested that I resend this email to R-devel > > instead to R-packages for further comments and potential availability > > for Windows. > > > > -- > > > > I have uploaded my Sweave (bash) shell script on CRAN. It is available at > > > > http://cran.r-project.org/contrib/extra/scripts/ > > > > In short this script runs Sweave on given Rnw file(s) and post process > > produced tex file(s) with LaTeX and friends directly from command line. > > It has quite a rich set of command line options to mainly ease the LaTeX > > compilation. > > > > Please do not hesitate to contact me in case you find errors or have > > suggestions and/or code contributions. I am particularly, interested in > > making this script work under Windows. > > > > -- > > > > I do not have any experience with use of (bash) shell scripts under > > Windows. Sweave.sh can be used with Cygwin, but I am not sure how to use > > shell script without Cygwin. I noticed that some "scripts" in R*/bin > > directory on our Windows machine are perl (build, check, INSTALL, ...) > > and shell (Rd2dvi.sh, Stangle.sh, Sweave.sh, ...) scripts. This > > therefore means that R ships also perl and shell interpreter or am I > > missing something? > > We don't ship Perl or sh.exe, but we do describe how to get them in the > R Admin manual. > > I'd be interested in talking to you about integration of my patchDVI > functions into your script. They allow forward and reverse search > between the .dvi file and the .Rnw file (in yap and xdvi, at least). > > Duncan Murdoch > > __ > 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] Sweave.sh shell script on CRAN
Gabor Grothendieck wrote: > On Windows sweave.bat is a Windows XP batchfile that will run sweave > and then latex and then display the file on screen. Issuing the command > sweave without args from the Windows command line gives info on how to > use it. > Nice to see windows "equivalent". However, I must say that my script provides several ways to get to the result e.g. if you use prosper you need to go via postscript, beamer behaves differently etc. There are now the following ways of LaTeX processing: Command and path Script option Used tools - texi2dvi - PS -tp, --texi2dvi2ps texi2dvi and dvips - PS to PDF -tld, --texi2dvi2ps2pdf texi2dvi, dvips and ps2pdf - PDF -td, --texi2dvi2pdf texi2dvi with pdf option - latex - PS -lp, --latex2dvi2ps hardcoded 'latex+co' + dvips - PS to PDF -lld, --latex2dvi2ps2pdf hardcoded 'latex+co' + dvips - pdflatex - PDF -ld, --latex2pdf hardcoded 'latex+co' + dvips > To install sweave.bat you must place sweave.bat (and Rcmd.bat) both > from this batchfiles distribution anywhere in your path. It does not > require > sh.exe and does not make use of perl but does use "Rcmd sweave" > so would have no prerequisites beyond latex, Acrobot (or other viewer) > and those of Rcmd. As I stated I am not sure how Rcmd works, but Sweave in SVN is a shell script as well as Rcmd! How does it become an exe file? Gregor __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sweave.sh shell script on CRAN
On 4/16/2007 7:53 AM, Gregor Gorjanc wrote:
> Duncan Murdoch wrote:
>>> I do not have any experience with use of (bash) shell scripts under
>>> Windows. Sweave.sh can be used with Cygwin, but I am not sure how to use
>>> shell script without Cygwin. I noticed that some "scripts" in R*/bin
>>> directory on our Windows machine are perl (build, check, INSTALL, ...)
>>> and shell (Rd2dvi.sh, Stangle.sh, Sweave.sh, ...) scripts. This
>>> therefore means that R ships also perl and shell interpreter or am I
>>> missing something?
>>
>> We don't ship Perl or sh.exe, but we do describe how to get them in the
>> R Admin manual.
>
> Maybe I got this totally wrong. Say someone who uses Windows finds R and
> installs it via setup file. Can he/she launch the folowing without
> having Perl and/or sh.exe?
>
> R CMD script whateverOption
No. Installing a binary package has a pure R implementation so it
doesn't need R CMD, but most of the capabilities of R CMD are not
available with a basic R install.
There are two reasons for this. One is that the extra tools that are
needed take up a lot of space, so they would make the setup file really
huge. That's an issue of less importance these days than in the past.
Another issue that is still important is that not all the tools needed
have licenses compatible with redistribution: in particular ActiveState
Perl and the Microsoft Help Workshop. There are other Perl
implementations, but in the past Brian Ripley found that they didn't
work. I don't know if that's still true. (In fact, I don't know if the
licenses still limit redistribution.)
>> I'd be interested in talking to you about integration of my patchDVI
>> functions into your script. They allow forward and reverse search
>> between the .dvi file and the .Rnw file (in yap and xdvi, at least).
>
> I am all ears.
The package is on my web page as
http://www.stats.uwo.ca/faculty/murdoch/software/patchDVI_1.0.tar.gz
Starting in R 2.5.0 (currently in beta), if you use Sweave options including
\SweaveOpts{keep.source=TRUE,concordance=TRUE}
then it will write out an \input{} for a file containing a TeX
\special{} encoding the concordance between the lines in the .Rnw file
and the lines in the .tex file. The patchDVI package contains routines
to look through a .dvi file for these specials, and the specials
inserted by latex when you ask for forward and reverse search (the
--src option in MikTeX, not sure how it's invoked in other
implementations), and patches the .dvi so the references point to the
.Rnw file instead.
It would make more sense for the previewer to interpret the specials
directly and so not require the patch, but currently it appears nobody
has done something like this. (If you know differently, please let me
know!) I think most people don't use forward and reverse search, so
there's not a lot of pressure for this feature in the previewers.
It would probably also make sense to make the concordance format a
little more general than it currently is (it assumes that each .tex file
comes from exactly one source Rnw file, for instance; I think that's
generally true now, but not necessarily true about other preprocessors.).
In the current implementation, this means the processing goes like this:
1. Run Sweave to produce the .tex.
2. Run latex to produce the .dvi.
3. Run patchDVI to patch the .dvi.
4. Run the previewer.
Since invoking R is slow in Windows, I wrote an R function SweaveMiktex
in patchDVI that does steps 1-3 in one R session.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sweave.sh shell script on CRAN
Gabor Grothendieck wrote: ... > If by "Sweave in SVN" you are referring to sweave.bat in the batchfiles > distribution then its not a shell file; rather, its a Windows batch file. Nope. I meant Sweave.sh in R SVN. Gregor __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sweave.sh shell script on CRAN
On 4/16/2007 10:13 AM, Gabor Grothendieck wrote:
> On 4/16/07, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
>> On 4/16/2007 7:53 AM, Gregor Gorjanc wrote:
>> > Duncan Murdoch wrote:
>> >>> I do not have any experience with use of (bash) shell scripts under
>> >>> Windows. Sweave.sh can be used with Cygwin, but I am not sure how to use
>> >>> shell script without Cygwin. I noticed that some "scripts" in R*/bin
>> >>> directory on our Windows machine are perl (build, check, INSTALL, ...)
>> >>> and shell (Rd2dvi.sh, Stangle.sh, Sweave.sh, ...) scripts. This
>> >>> therefore means that R ships also perl and shell interpreter or am I
>> >>> missing something?
>> >>
>> >> We don't ship Perl or sh.exe, but we do describe how to get them in the
>> >> R Admin manual.
>> >
>> > Maybe I got this totally wrong. Say someone who uses Windows finds R and
>> > installs it via setup file. Can he/she launch the folowing without
>> > having Perl and/or sh.exe?
>> >
>> > R CMD script whateverOption
>>
>> No. Installing a binary package has a pure R implementation so it
>> doesn't need R CMD, but most of the capabilities of R CMD are not
>> available with a basic R install.
>
> Can you just clarify what the dependencies are for
>
> Rcmd sweave
>
> where Rcmd is the Rcmd command distributed with R that is run
> from the Windows command line. Does that require perl or other
> tools to run?
That needs sh.exe, not Perl. But it's just the equivalent of
echo "library('utils'); Sweave('filename')" | Rterm --no-restore --slave
at the command line or
Sweave("filename")
in a standard R session.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sweave.sh shell script on CRAN
On 4/16/07, Gregor Gorjanc <[EMAIL PROTECTED]> wrote: > Gabor Grothendieck wrote: > > On Windows sweave.bat is a Windows XP batchfile that will run sweave > > and then latex and then display the file on screen. Issuing the command > > sweave without args from the Windows command line gives info on how to > > use it. > > > > Nice to see windows "equivalent". However, I must say that my script > provides several ways to get to the result e.g. if you use prosper you > need to go via postscript, beamer behaves differently etc. > > There are now the following ways of LaTeX processing: > > Command and path Script option Used tools > - texi2dvi > - PS -tp, --texi2dvi2ps texi2dvi and dvips > - PS to PDF -tld, --texi2dvi2ps2pdf texi2dvi, dvips and ps2pdf > - PDF -td, --texi2dvi2pdf texi2dvi with pdf option > > - latex > - PS -lp, --latex2dvi2ps hardcoded 'latex+co' + dvips > - PS to PDF -lld, --latex2dvi2ps2pdf hardcoded 'latex+co' + dvips > > - pdflatex > - PDF -ld, --latex2pdf hardcoded 'latex+co' + dvips > > > To install sweave.bat you must place sweave.bat (and Rcmd.bat) both > > from this batchfiles distribution anywhere in your path. It does not > > require > > sh.exe and does not make use of perl but does use "Rcmd sweave" > > so would have no prerequisites beyond latex, Acrobot (or other viewer) > > and those of Rcmd. > > As I stated I am not sure how Rcmd works, but Sweave in SVN is a shell > script as well as Rcmd! How does it become an exe file? > > Gregor > If by "Sweave in SVN" you are referring to sweave.bat in the batchfiles distribution then its not a shell file; rather, its a Windows batch file. Windows has a batch processor built in that directly runs Windows batch files without any precompiling to an exe. As stated, you simply place sweave.bat and rcmd.bat, both files from the batchfiles distribution, anywhere in your path to run it. There is no further installation required. That was why I used Windows batch -- to eliminate dependencies, installation procedures, precompilations setting environment variable names, etc. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sweave.sh shell script on CRAN
On 4/16/07, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > On 4/16/2007 7:53 AM, Gregor Gorjanc wrote: > > Duncan Murdoch wrote: > >>> I do not have any experience with use of (bash) shell scripts under > >>> Windows. Sweave.sh can be used with Cygwin, but I am not sure how to use > >>> shell script without Cygwin. I noticed that some "scripts" in R*/bin > >>> directory on our Windows machine are perl (build, check, INSTALL, ...) > >>> and shell (Rd2dvi.sh, Stangle.sh, Sweave.sh, ...) scripts. This > >>> therefore means that R ships also perl and shell interpreter or am I > >>> missing something? > >> > >> We don't ship Perl or sh.exe, but we do describe how to get them in the > >> R Admin manual. > > > > Maybe I got this totally wrong. Say someone who uses Windows finds R and > > installs it via setup file. Can he/she launch the folowing without > > having Perl and/or sh.exe? > > > > R CMD script whateverOption > > No. Installing a binary package has a pure R implementation so it > doesn't need R CMD, but most of the capabilities of R CMD are not > available with a basic R install. Can you just clarify what the dependencies are for Rcmd sweave where Rcmd is the Rcmd command distributed with R that is run from the Windows command line. Does that require perl or other tools to run? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sweave.sh shell script on CRAN
Duncan Murdoch wrote: ... >> Maybe I got this totally wrong. Say someone who uses Windows finds R and >> installs it via setup file. Can he/she launch the folowing without >> having Perl and/or sh.exe? >> >> R CMD script whateverOption > > No. Installing a binary package has a pure R implementation so it > doesn't need R CMD, but most of the capabilities of R CMD are not > available with a basic R install. > > There are two reasons for this. One is that the extra tools that are > needed take up a lot of space, so they would make the setup file really > huge. That's an issue of less importance these days than in the past. > > Another issue that is still important is that not all the tools needed > have licenses compatible with redistribution: in particular ActiveState > Perl and the Microsoft Help Workshop. There are other Perl > implementations, but in the past Brian Ripley found that they didn't > work. I don't know if that's still true. (In fact, I don't know if the > licenses still limit redistribution.) OK. Thank you for this explanation. I can not live without unix shell and therefore never noticed that under Windows say R CMD INSTALL or other R CMD scripts do not work without sh.exe (and/or Perl). Gregor __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sweave.sh shell script on CRAN
Duncan Murdoch wrote:
>> Can you just clarify what the dependencies are for
>>
>> Rcmd sweave
>>
>> where Rcmd is the Rcmd command distributed with R that is run
>> from the Windows command line. Does that require perl or other
>> tools to run?
>
> That needs sh.exe, not Perl. But it's just the equivalent of
>
> echo "library('utils'); Sweave('filename')" | Rterm --no-restore --slave
Then sweave.bat from batchfiles depends on sh.exe as my Sweave.sh.
However, I guess that above line can also be done with MS command line.
Gregor
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] nls with algorithm = "port", starting values
I think we should fix the code to do as the documentation says: all it
needs is an unlist().
Thank you for the examples, which helped test this.
On Mon, 16 Apr 2007, Katharine Mullen wrote:
> The documentation for nls says the following about the starting values:
>
> start: a named list or named numeric vector of starting estimates.
> Since R 2.4.0, when 'start' is missing, a very cheap guess
> for 'start' is tried (if 'algorithm != "plinear"').
>
> It may be a good idea to document that when algorithm = "port", if start
> is a named list, the elements of the list must be numeric vectors of
> length 1. Ie, start = list(a=1,b=2,c=3) is ok, but start = list(a=c(1,2),
> b=3) is not. This is not the case when algorithm is "plinear" or the
> default GN, and is because of the way that the "port" code in nls.R
> transforms the starting values (the other options do something else):
>
> nls_port_fit <- function(m, start, lower, upper, control, trace)
> {
>## Establish the working vectors and check and set options
>p <- length(par <- as.double(start))
>
>
> Example:
>
> ## exponentially decaying data
> getExpmat <- function(theta, t)
> {
>conc <- matrix(nrow = length(t), ncol = length(theta))
>for(i in 1:length(theta)) {
>conc[, i] <- exp(- theta[i] * t)
>}
>conc
> }
>
> expsum <- as.vector(getExpmat(c(.05,.005), 1:100) %*% c(1,1))
> expsumNoisy <- expsum + max(expsum) *.001 * rnorm(100)
> expsum.df <-data.frame(expsumNoisy)
>
> ## estimate decay rates, amplitudes with default Gauss-Newton
> summary (nls(expsumNoisy ~ getExpmat(k, 1:100) %*% sp, expsum.df, start =
> list(k = c(.6,.02), sp = c(1,2)), trace=TRUE, control =
> nls.control(maxiter=20,
> warnOnly = TRUE)))
>
> ## won't work with port
> summary (nls(expsumNoisy ~ getExpmat(k, 1:100) %*% sp, expsum.df, start =
> list(k = c(.6,.02), sp = c(1,2)), algorithm = "port",
> trace=TRUE, control = nls.control(maxiter=20,
> warnOnly = TRUE)))
>
> __
> 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] Sweave.sh shell script on CRAN
On 4/16/07, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
> On 4/16/2007 10:13 AM, Gabor Grothendieck wrote:
> > On 4/16/07, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
> >> On 4/16/2007 7:53 AM, Gregor Gorjanc wrote:
> >> > Duncan Murdoch wrote:
> >> >>> I do not have any experience with use of (bash) shell scripts under
> >> >>> Windows. Sweave.sh can be used with Cygwin, but I am not sure how to
> >> >>> use
> >> >>> shell script without Cygwin. I noticed that some "scripts" in R*/bin
> >> >>> directory on our Windows machine are perl (build, check, INSTALL, ...)
> >> >>> and shell (Rd2dvi.sh, Stangle.sh, Sweave.sh, ...) scripts. This
> >> >>> therefore means that R ships also perl and shell interpreter or am I
> >> >>> missing something?
> >> >>
> >> >> We don't ship Perl or sh.exe, but we do describe how to get them in the
> >> >> R Admin manual.
> >> >
> >> > Maybe I got this totally wrong. Say someone who uses Windows finds R and
> >> > installs it via setup file. Can he/she launch the folowing without
> >> > having Perl and/or sh.exe?
> >> >
> >> > R CMD script whateverOption
> >>
> >> No. Installing a binary package has a pure R implementation so it
> >> doesn't need R CMD, but most of the capabilities of R CMD are not
> >> available with a basic R install.
> >
> > Can you just clarify what the dependencies are for
> >
> > Rcmd sweave
> >
> > where Rcmd is the Rcmd command distributed with R that is run
> > from the Windows command line. Does that require perl or other
> > tools to run?
>
> That needs sh.exe, not Perl. But it's just the equivalent of
>
> echo "library('utils'); Sweave('filename')" | Rterm --no-restore --slave
>
> at the command line or
>
> Sweave("filename")
>
> in a standard R session.
Thanks for the explanation. I could look into replacing Rcmd with the Rterm
pipeline in the sweave.bat script to eliminate the sh.exe dependency so
sweave.bat can be used with a basic R installation.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Documentation bug for sys.parent
In R-trunk version 41191, the 'Value' section of sys.parent.Rd explains
that sys.parent() returns an environment, which is wrong. The 'Details'
sections explains that it returns the number of the parent frame, etc.
Here's a fix:
Index: src/library/base/man/sys.parent.Rd
===
--- src/library/base/man/sys.parent.Rd (revision 41191)
+++ src/library/base/man/sys.parent.Rd (working copy)
@@ -81,8 +81,8 @@
}
\value{
\code{sys.call} returns a call, \code{sys.function} a function
- definition, and \code{sys.frame}, \code{sys.parent} and
- \code{parent.frame} return an environment.
+ definition, and \code{sys.frame} and \code{parent.frame} return an
+ environment.
For the other functions, see the Details section.
}
Best,
Jeff
--
http://biostat.mc.vanderbilt.edu/JeffreyHorner
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] args / formals on primitives
On SVN revision 41087: ?args has this example line: args(c)# -> NULL (c is a 'primitive' function) The comment seems out of date, as args(c) does in fact have a non-NULL return value: args(c) # function (..., recursive = FALSE) # NULL While at it, I was wondering, why formals(c) still returns NULL, in contrast. Regards Thomas Friedrichsmeier pgpjLrLL8eGiE.pgp Description: PGP signature __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Documentation update to R-lang.texi
Section 4.3.4 of R-lang.texi version 41191 in the paragraph that starts
"When h(3) is..." explains that x and y are unbound variables in the
function body of g in this example:
f <- function(x) {
y <- 10
g <- function(x) x + y
return(g)
}
h <- f()
h(3)
while the paragraph following the example explains that "bound variables
are those that match the formal arguments to the function." So wouldn't
x be bound?
Jeff
--
http://biostat.mc.vanderbilt.edu/JeffreyHorner
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sweave.sh shell script on CRAN
On 4/16/07, Gabor Grothendieck <[EMAIL PROTECTED]> wrote:
> On 4/16/07, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
> > On 4/16/2007 10:13 AM, Gabor Grothendieck wrote:
> > > On 4/16/07, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
> > >> On 4/16/2007 7:53 AM, Gregor Gorjanc wrote:
> > >> > Duncan Murdoch wrote:
> > >> >>> I do not have any experience with use of (bash) shell scripts under
> > >> >>> Windows. Sweave.sh can be used with Cygwin, but I am not sure how to
> > >> >>> use
> > >> >>> shell script without Cygwin. I noticed that some "scripts" in R*/bin
> > >> >>> directory on our Windows machine are perl (build, check, INSTALL,
> > >> >>> ...)
> > >> >>> and shell (Rd2dvi.sh, Stangle.sh, Sweave.sh, ...) scripts. This
> > >> >>> therefore means that R ships also perl and shell interpreter or am I
> > >> >>> missing something?
> > >> >>
> > >> >> We don't ship Perl or sh.exe, but we do describe how to get them in
> > >> >> the
> > >> >> R Admin manual.
> > >> >
> > >> > Maybe I got this totally wrong. Say someone who uses Windows finds R
> > >> > and
> > >> > installs it via setup file. Can he/she launch the folowing without
> > >> > having Perl and/or sh.exe?
> > >> >
> > >> > R CMD script whateverOption
> > >>
> > >> No. Installing a binary package has a pure R implementation so it
> > >> doesn't need R CMD, but most of the capabilities of R CMD are not
> > >> available with a basic R install.
> > >
> > > Can you just clarify what the dependencies are for
> > >
> > > Rcmd sweave
> > >
> > > where Rcmd is the Rcmd command distributed with R that is run
> > > from the Windows command line. Does that require perl or other
> > > tools to run?
> >
> > That needs sh.exe, not Perl. But it's just the equivalent of
> >
> > echo "library('utils'); Sweave('filename')" | Rterm --no-restore --slave
> >
> > at the command line or
> >
> > Sweave("filename")
> >
> > in a standard R session.
>
> Thanks for the explanation. I could look into replacing Rcmd with the Rterm
> pipeline in the sweave.bat script to eliminate the sh.exe dependency so
> sweave.bat can be used with a basic R installation.
>
Actually it turned out to be a relatively simple change so I made it.
Place these two files anywhere in your path on Windows XP:
http://batchfiles.googlecode.com/svn/trunk/sweave.bat
http://batchfiles.googlecode.com/svn/trunk/rterm.bat
and at the Windows XP console type
sweave
for further instructions. sh.exe should no longer be needed so it should
run with a basic R installation (plus latex and a PDF viewer). I will upload
this to CRAN in the next few days but in the meantime its available as
indicated.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] save() and interrupts
On Sun, 15 Apr 2007, Henrik Bengtsson wrote: > On 4/15/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote: > > On Sun, 15 Apr 2007, Henrik Bengtsson wrote: > > > > > are there any (cross-platform) specs on what the saved filed is if > > > save() is interrupted, e.g. by a user interrupt? It could be > > > non-existing, empty, partly written, or completed. > > > > My understanding is that you cannot user interrupt compiled code unless it > > is set up to check interrupts. Version 2 saves are done via the internal > > saveToConn, and I don't see any calls to R_CheckUserInterrupt there. So > > you only need to worry about user interrupts in the R code, and that has > > an on.exit action to close the connection (which should be executed even > > if you interrupt). Which suggests that the file will be > > > > non-existent > > empty > > complete > > > > and the first two depend on interrupting in the millisecond or less before > > the compiled code gets called. > > I'll put it on my todo list to investigate how to make save() more > robust against interrupts before calling the internal code. One > option is to use tryCatch(). However, that does not handle too > frequent user interrupts, e.g. if an interrupt is sent while in the > "interrupt" call, that will interrupt the function. So, tryCatch() > alone will only lower the risk for incomplete empty files. For data > written to files, one alternative is to check for files of zero size > in the on.exit() statement and remove such. > > /Henrik > > > > For other forms of interrupts, e.g. a Unix kill -9, the file state could > > be anything. > > > > Brian D. Ripley, [EMAIL PROTECTED] > > ... You could change the code to write to a temporary file (in the directory you want the result in) and when you successfully finish writing to the file you rename it to the permanent name. (On an interrupt you remove the temp file, and on 'kill -9' the only bad effect is the space used by the partially written temp file.) This has the added advantage that you don't overwrite an existing save file by the given name until you know a suitable replacement is ready. Perhaps we need a connection type that encapsulates this. Bill Dunlap Insightful Corporation bill at insightful dot com 360-428-8146 "All statements in this message represent the opinions of the author and do not necessarily reflect Insightful Corporation policy or position." __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] save() and interrupts
On Mon, 16 Apr 2007, Bill Dunlap wrote: > On Sun, 15 Apr 2007, Henrik Bengtsson wrote: > >> On 4/15/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote: >>> On Sun, 15 Apr 2007, Henrik Bengtsson wrote: >>> are there any (cross-platform) specs on what the saved filed is if save() is interrupted, e.g. by a user interrupt? It could be non-existing, empty, partly written, or completed. >>> >>> My understanding is that you cannot user interrupt compiled code unless it >>> is set up to check interrupts. Version 2 saves are done via the internal >>> saveToConn, and I don't see any calls to R_CheckUserInterrupt there. So >>> you only need to worry about user interrupts in the R code, and that has >>> an on.exit action to close the connection (which should be executed even >>> if you interrupt). Which suggests that the file will be >>> >>> non-existent >>> empty >>> complete >>> >>> and the first two depend on interrupting in the millisecond or less before >>> the compiled code gets called. >> >> I'll put it on my todo list to investigate how to make save() more >> robust against interrupts before calling the internal code. One >> option is to use tryCatch(). However, that does not handle too >> frequent user interrupts, e.g. if an interrupt is sent while in the >> "interrupt" call, that will interrupt the function. So, tryCatch() >> alone will only lower the risk for incomplete empty files. For data >> written to files, one alternative is to check for files of zero size >> in the on.exit() statement and remove such. >> >> /Henrik >>> >>> For other forms of interrupts, e.g. a Unix kill -9, the file state could >>> be anything. >>> >>> Brian D. Ripley, [EMAIL PROTECTED] >>> ... > > You could change the code to write to a temporary > file (in the directory you want the result in) and > when you successfully finish writing to the file > you rename it to the permanent name. (On an interrupt > you remove the temp file, and on 'kill -9' the only > bad effect is the space used by the partially written > temp file.) This has the added advantage that you don't > overwrite an existing save file by the given name until > you know a suitable replacement is ready. > > Perhaps we need a connection type that encapsulates this. > > > Bill Dunlap > Insightful Corporation > bill at insightful dot com > 360-428-8146 > > "All statements in this message represent the opinions of the author and do > not necessarily reflect Insightful Corporation policy or position." We do this with save.image. Since save is a little more general it is a bit less obvious what the right way to do this sort of thing is, or whether there is a single right way. I think if I was concerned about this I would write something around the current save for particular kinds of connections rather than changing save itself. The main reason for taking a different rout with save.image is that that gets called implicitly by q(). [our current ability to manage user interrupts is not ideal--hopefully we can make a bit of progress on this soon.] Best, luke -- 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] save() and interrupts
On 4/16/07, Luke Tierney <[EMAIL PROTECTED]> wrote: > On Mon, 16 Apr 2007, Bill Dunlap wrote: > > > On Sun, 15 Apr 2007, Henrik Bengtsson wrote: > > > >> On 4/15/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote: > >>> On Sun, 15 Apr 2007, Henrik Bengtsson wrote: > >>> > are there any (cross-platform) specs on what the saved filed is if > save() is interrupted, e.g. by a user interrupt? It could be > non-existing, empty, partly written, or completed. > >>> > >>> My understanding is that you cannot user interrupt compiled code unless it > >>> is set up to check interrupts. Version 2 saves are done via the internal > >>> saveToConn, and I don't see any calls to R_CheckUserInterrupt there. So > >>> you only need to worry about user interrupts in the R code, and that has > >>> an on.exit action to close the connection (which should be executed even > >>> if you interrupt). Which suggests that the file will be > >>> > >>> non-existent > >>> empty > >>> complete > >>> > >>> and the first two depend on interrupting in the millisecond or less before > >>> the compiled code gets called. > >> > >> I'll put it on my todo list to investigate how to make save() more > >> robust against interrupts before calling the internal code. One > >> option is to use tryCatch(). However, that does not handle too > >> frequent user interrupts, e.g. if an interrupt is sent while in the > >> "interrupt" call, that will interrupt the function. So, tryCatch() > >> alone will only lower the risk for incomplete empty files. For data > >> written to files, one alternative is to check for files of zero size > >> in the on.exit() statement and remove such. > >> > >> /Henrik > >>> > >>> For other forms of interrupts, e.g. a Unix kill -9, the file state could > >>> be anything. > >>> > >>> Brian D. Ripley, [EMAIL PROTECTED] > >>> ... > > > > You could change the code to write to a temporary > > file (in the directory you want the result in) and > > when you successfully finish writing to the file > > you rename it to the permanent name. (On an interrupt > > you remove the temp file, and on 'kill -9' the only > > bad effect is the space used by the partially written > > temp file.) This has the added advantage that you don't > > overwrite an existing save file by the given name until > > you know a suitable replacement is ready. > > > > Perhaps we need a connection type that encapsulates this. > > > > > > Bill Dunlap > > Insightful Corporation > > bill at insightful dot com > > 360-428-8146 > > > > "All statements in this message represent the opinions of the author and do > > not necessarily reflect Insightful Corporation policy or position." > > We do this with save.image. Since save is a little more general it is > a bit less obvious what the right way to do this sort of thing is, or > whether there is a single right way. I think if I was concerned about > this I would write something around the current save for particular > kinds of connections rather than changing save itself. The main > reason for taking a different rout with save.image is that that gets > called implicitly by q(). > > [our current ability to manage user interrupts is not ideal--hopefully > we can make a bit of progress on this soon.] I was thinking about this last night: It would be useful to have a feature/construct to evaluate an R expression atomically where user interrupts will *not have an affect until afterwards*, cf. calls to native code. This would solve the problem of getting interrupts while in a tryCatch(..., interrupt=..., finally=...). Of course this requires caution by the programmer, but it is also unlikely to be used by someone who do not know what the risks are. I do not know the different signals available, but one could consider such atomic calls to be protected against different levels of signals. In addition, one could have an optional threshold of the number of interrupt signals it takes to (even) interrupt an atomic evaluation. /Henrik > > Best, > > luke > > -- > 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
