[Rd] Assumption of Gaussian innovations in function stats::arima
Hi, if I read the help to function stats::arima carefully enough, I have not found any mentioning of the assumption that the innovations e[t] (notation from the help file) be Gaussian. I think this assumption should be included. In particular, the returned information on the log likelihood would be wrong otherwise. Best regards, Peter Ruckdeschel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Storage of byte code-compiled functions in sysdata.rda
Hi r-devels,
we are seeing a new problem with our packages RobAStRDA (just new on CRAN,
thanks
to Uwe and Kurt!) and RobExtremes (to be submitted).
It must be something recent with the way you internally treat/store byte-code
compiled
functions, as we have no problems with R-3.1.3, but do see an "Error in fct(x)
: byte code
version mismatch" with R-devel SVNrev r70532.
Background:
Starting from several x-y grids, in the sysdata.rda file of RobAStRDA, we store
the results
of calls to approxfun/splinefun to these grids from within a session with pkg
RobAStRDA
require()d. From pkg RobExtremes we then call these interpolating functions by
means of
a call (essentially) as:
getFromNamespace(".RMXE", ns = "RobAStRDA")[["GEVFamily"]][["fun.N"]][[1]](1.3)
upon which we get the announced "Error in fct(x) : byte code version mismatch"
while the same
code does work for R-3.1.3.
The list element "fun.N" in the above call already accounts for a different
behaviour for
pre R-3.0.0 (would have given "fun.O") and post R-3.0.0 ("fun.N") results of
approxfun/
splinefun, but the interpolating functions in branch "fun.N" have been produced
in
R-devel SVNrev r70532, so we would have expected our code
getFromNamespace(.) above to
work in R-devel as well.
Could you give us any hints how to
(a) store the interpolating functions resulting from approxfun/splinefun in pkg
RobAStRDA
correctly in recent R-versions and
(b) call these functions in pkg RobExtremes ?
We already did import stats::approxfun and stats::splinefun into the NAMESPACEs
of pkgs
RobAStRDA and RobExtremes.
Thanks for your help already,
Peter
---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Storage of byte code-compiled functions in sysdata.rda
Thanks, Luke, for having a look to it.
Sure, I can give you some reproducible example -- even in two degrees of
completeness ;-): see below.
Thanks again, Peter
%---
(I) first example
%---
Just to reproduce the error, on r-devel, try:
install.packages("RobAStRDA")
require(RobAStRDA)
getFromNamespace(".RMXE", ns = "RobAStRDA")[["GEVFamily"]][["fun.N"]][[1]](1.3)
%---
(II) an example also giving the context
%---
For the "complete" story, not only the R-code needs to be given, but also the
preparation steps to produce the packages on the right R version;
so please follow steps (1)--(6) below; I am not 100% sure whether this already
gives
you all information needed for this, but if not so please let me know.
(1) create a minimal R-package "InterpolTry"
with byte-compilation on in the DESCRIPTION file
and with stats::approxfun imported in the NAMESPACE file
(2) in an R session on R-devel do
require(InterpolTry)
x <- 1:100
y <- 1:100
fun <- approxfun(x,y)
## revise the next line accordingly to your local settings
SrcRPathInterpolTry <-
RdaFile <- file.path(SrcRPathInterpolTry, "sysdata.rda")
save(fun, file = RdaFile)
tools::resaveRdaFiles(RdaFile)
(3) re-build package InterpolTry and re-install it
(4) create a minimal R package "UseInterpolTry", again
with byte-compilation on in the DESCRIPTION file
and with stats::approxfun and package "InterpolTry"
imported in the NAMESPACE file
(5) in the R folder of R package "UseInterpolTry" write a function
useInterpolFct() which goes like this
useInterpolFct <- function(x){
fun <- getFromNamespace("fun", ns = "InterpolTry")
fun(x)
}
export this function in the namespace and create an .Rd file to it
(6) (re-)build package "UseInterpolTry" and (re-)install it and try
require(UseInterpolTry)
useInterpolFct(5)
Steps (1)--(6) work with R-3.1.3, but no longer with R-devel.
Am 01.05.2016 um 14:12 schrieb Tierney, Luke:
> Can you provide a complete reproducible example?
>
> Sent from my iPhone
>
>> On May 1, 2016, at 6:51 AM, Peter Ruckdeschel
>> wrote:
>>
>> Hi r-devels,
>>
>> we are seeing a new problem with our packages RobAStRDA (just new on CRAN,
>> thanks
>> to Uwe and Kurt!) and RobExtremes (to be submitted).
>>
>> It must be something recent with the way you internally treat/store
>> byte-code compiled
>> functions, as we have no problems with R-3.1.3, but do see an "Error in
>> fct(x) : byte code
>> version mismatch" with R-devel SVNrev r70532.
>>
>> Background:
>> Starting from several x-y grids, in the sysdata.rda file of RobAStRDA, we
>> store the results
>> of calls to approxfun/splinefun to these grids from within a session with
>> pkg RobAStRDA
>> require()d. From pkg RobExtremes we then call these interpolating functions
>> by means of
>> a call (essentially) as:
>>
>> getFromNamespace(".RMXE", ns =
>> "RobAStRDA")[["GEVFamily"]][["fun.N"]][[1]](1.3)
>>
>> upon which we get the announced "Error in fct(x) : byte code version
>> mismatch" while the same
>> code does work for R-3.1.3.
>>
>> The list element "fun.N" in the above call already accounts for a different
>> behaviour for
>> pre R-3.0.0 (would have given "fun.O") and post R-3.0.0 ("fun.N") results of
>> approxfun/
>> splinefun, but the interpolating functions in branch "fun.N" have been
>> produced in
>> R-devel SVNrev r70532, so we would have expected our code
>> getFromNamespace(.) above to
>> work in R-devel as well.
>>
>> Could you give us any hints how to
>>
>> (a) store the interpolating functions resulting from approxfun/splinefun in
>> pkg RobAStRDA
>>correctly in recent R-versions and
>> (b) call these functions in pkg RobExtremes ?
>>
>> We already did import stats::approxfun and stats::splinefun into the
>> NAMESPACEs of pkgs
>> RobAStRDA and RobExtremes.
>>
>> Thanks for your help already,
>> Peter
>>
>>
>> ---
>> Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
>> https://www.avast.com/antivirus
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Storage of byte code-compiled functions in sysdata.rda
Dear Luke,
thanks for taking a look at our problem and for checking it out, in particular
for
sending us the tool function getbc.
This really sounds like we have somehow messed up our chain with different
versions
of the byte-code compiler. We will try and fix this and will let you know if we
succeed.
Thanks again, Peter
Am 05.05.2016 um 22:07 schrieb luke-tier...@uiowa.edu:
> I can't reproduce the more complex version. But the package on CRAN
> fails in the same way on 3.2.3 and 3.3.0.
>
> The problem is that your sysdata.rda includes a function that is
> generating this error. If you do
>
> f <- getFromNamespace(".RMXE", ns ="RobAStRDA")[["GEVFamily"]][["fun.N"]][[1]]
> g <- get("fct", environment(f))
>
> and look at the byte code for g with compiler::disassemble or the
> utility I'll paste in below you get
>
>> getbc(g)
> list(8L, BCMISMATCH.OP)
>
> The only way you can get a file like this is to byte compile and save
> in a version of R with a newer byte code version (the 8L) and then
> load and resave in an older version of R. If you load and run this
> code in an older (or newer) version of R it will revert to the
> standard interpeter using eval but will issue a warning once per
> session. If you try to run it in an R with byte code version 8L you
> get this error.
>
> I can make a small change to that this becomes a once-per-session
> warning, but even then you won't actually be running compiled code.
>
> So I think your task is to figure out how you are ended up with a
> sysdata.rda file created in this incompatible way. Something to look
> for might be whether a call from within your R-devel somehow manages
> to run an R process with an older R version.
>
> Let me know what you find out.
>
> luke
>
> Here is the little utility, adapted from compiler::disassemble:
>
> getbc <- function (code)
> {
> .CodeSym <- as.name(".Code")
> disasm.const <- function(x) if (typeof(x) == "list" && length(x) >
> 0 && identical(x[[1]], .CodeSym))
> disasm(x)
> else x
> disasm <- function(code) {
> code[[2]] <- compiler:::bcDecode(code[[2]])
> code[[3]] <- lapply(code[[3]], disasm.const)
> code
> }
> if (typeof(code) == "closure") {
> code <- .Internal(bodyCode(code))
> if (typeof(code) != "bytecode")
> stop("function is not compiled")
> }
> invisible(dput(disasm(.Internal(disassemble(code)))[[2]]))
> }
>
> On Sun, 1 May 2016, Peter Ruckdeschel wrote:
>
>> Thanks, Luke, for having a look to it.
>>
>> Sure, I can give you some reproducible example -- even in two degrees of
>> completeness ;-): see below.
>>
>> Thanks again, Peter
>>
>> %---
>> (I) first example
>> %---
>> Just to reproduce the error, on r-devel, try:
>>
>> install.packages("RobAStRDA")
>> require(RobAStRDA)
>> getFromNamespace(".RMXE", ns =
>> "RobAStRDA")[["GEVFamily"]][["fun.N"]][[1]](1.3)
>>
>> %---
>> (II) an example also giving the context
>> %---
>> For the "complete" story, not only the R-code needs to be given, but also the
>> preparation steps to produce the packages on the right R version;
>>
>> so please follow steps (1)--(6) below; I am not 100% sure whether this
>> already gives
>> you all information needed for this, but if not so please let me know.
>>
>> (1) create a minimal R-package "InterpolTry"
>> with byte-compilation on in the DESCRIPTION file
>> and with stats::approxfun imported in the NAMESPACE file
>>
>> (2) in an R session on R-devel do
>>
>> require(InterpolTry)
>> x <- 1:100
>> y <- 1:100
>> fun <- approxfun(x,y)
>> ## revise the next line accordingly to your local settings
>> SrcRPathInterpolTry <-
>> RdaFile <- file.path(SrcRPathInterpolTry, "sysdata.rda")
>> save(fun, file = RdaFile)
>> tools::resaveRdaFiles(RdaFile)
>>
>> (3) re-build package InterpolTry and re-install it
>>
>> (4) create a minimal R package "UseInterpolTry", again
>> with byte-compilation on in the DESCRIPTION file
>> and with stats::approxfun and package "InterpolTry"
>> imported in the NAMESPACE file
>>
>> (5) in the R
[Rd] text(1:10, col=NA) is not transparent
Maybe I am missing something, but according to the help page to par (section "Color Specification"), which is referred to in the help to text argument col: ‘"transparent"’ or (integer) ‘NA’ is _transparent_, useful for filled areas (such as the background!), and just invisible for things like lines or text. but: col0 <- as.integer(NA) is.integer(col0) ### is this coercing to "integer" necessary? plot(1:10) text(1:10, col=col0) ### text is plotted ##whereas plot(1:10) text(1:10, col="transparent") ### text is not plotted # Of course, this is not terribly urgent, as a color value of 0 also plot(1:10) text(1:10, col=0) ### text is not plotted Best, Peter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] text(1:10, col=NA) is printed in color 1 instead of color 0 (was "is not transparent")
Am 20.02.2012 15:22, schrieb Kasper Daniel Hansen: > Peter, > > not all devices support transparency. My guess is that you are > plotting to a device which does not, but it is hard to know from your > email. > > Kasper > In the meantime Kasper and I had some mail exchange offline. @Kasper: thanks again for your explanations and hopefully it is oK for you if I put this clarifying online It seems my original subject was a bit misleading, as I am not really interested in achieving transparency (which I know is system-dependent) but rather in the behavior, that text(, col = NA) should not do anything --- or, more useful, if you have vectorized input and col is vectorized, too, the NA-coordinates are not printed (as is what I read from the help page to par() ). The non-printing behavior is achievable already with 0 color values, and with named color "transparent", but not for NA-values. This effect seems to be device independent, at least I have checked it for the windows, pdf, and jpeg devices under Windows and in the default graphics device under Linux. Any suggestions welcome, Peter > On Mon, Feb 20, 2012 at 6:09 AM, Peter Ruckdeschel > wrote: >> Maybe I am missing something, but according to the help page >> to par (section "Color Specification"), which is referred to in the >> help to text argument col: >> >> ‘"transparent"’ or (integer) ‘NA’ is _transparent_, >> useful for filled areas (such as the background!), and just >> invisible for things like lines or text. >> >> but: >> >> col0 <- as.integer(NA) >> is.integer(col0) >> ### is this coercing to "integer" necessary? >> plot(1:10) >> text(1:10, col=col0) >> ### text is plotted >> >> ##whereas >> plot(1:10) >> text(1:10, col="transparent") >> ### text is not plotted >> >> # Of course, this is not terribly urgent, as a color value of 0 also >> plot(1:10) >> text(1:10, col=0) >> ### text is not plotted >> >> Best, Peter >> >> __ >> 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] R-forge, package dependencies
Am 15.01.2013 21:37, schrieb Paul Gilbert: > I'm surprised this works on Windows and Mac, since RMonetDB does not > seem to be on CRAN. I thought it was still a requirement that > dependencies need to be on CRAN (which makes development difficult for > related packages like this). Sorry for my somewhat belated addition: AFAICS, the mentioned issue does also bite Windows builds, at least this holds in case of our distr family of packages, see e.g. https://r-forge.r-project.org/R/?group_id=89&log=build_win64&pkg=SweaveListingUtils&flavor=patched but, e.g., also for Thierry Onkelinx's pkg "AFLP" https://r-forge.r-project.org/R/?group_id=1027&log=build_win64&pkg=AFLP&flavor=patched > A related long standing request is that R-forge checking look for > required newer versions on R-forge rather than just on CRAN. Does anyone > know if that works on Windows and/or Mac? I cannot answer this, but also considering R-forge hosted versions would not necessarily fix the present problem: at least for pkg "SweaveListingUtils", the dependencies listed in its DESCRIPTION file would be happy with the version of pkg "startupmsg" available on CRAN (and as well with the one already available currently for download on R-forge); still, R-forge complains about not finding pkg "startupmsg". In this case this seems to be unrelated to the checking environment not finding external libraries because the path is mentioned in some non-found environment variable (as in Martin's case mentioned in this thread); I still can use R CMD check --as-cran on all my pkgs on my machine (R-3.0.0-devel 61755 and R-2.15.2-patched r61745) without problems, on Linux as well as on Windows; rather, it seems that R-forge's check process does not search the library of pkgs to which pkgs already built on R-forge have been installed to (on R-forge). And therefore I exceptionally x-post this back to site-b...@r-forge.r-project.org ... At any rate, good look to the problem hunters at R-forge, I hope their great service will be available again soon. Best regards, Peter > > Paul > > On 13-01-15 03:09 PM, Uwe Ligges wrote: >> >> >> On 15.01.2013 20:47, Thomas Lumley wrote: >>> I have a project on R-forge (sqlsurvey.r-forge.r-project.org) with two >>> packages, RMonetDB and sqlsurvey. >>> >>> At the moment, sqlsurvey is listed as failing to build. The error is on >>> the Linux package check, which says that RMonetDB is not available: >>> >>> >>> * checking package dependencies ... ERROR >>> Package required but not available: ‘RMonetDB’ >>> >>> RMonetDB has built successfully: r-forge lists its status as 'current', >>> with Linux, Windows, and Mac packages available for download. The >>> package >>> check for sqlsurvey on Windows and Mac finds RMonetDB without any >>> problems, >>> it's just on Linux that it appears to be unavailable. >>> >>> Any suggestions for how to fix this? I've tried uploading a new >>> version of >>> RMonetDB, but the situation didn't change: it built successfully, but >>> the >>> Linux check of sqlsurvey still couldn't find it. >> >> >> I think you have to ask Stefan to check the details. >> >> Best, >> Uwe >> >> >>> -thomas >>> >>> >>> >>> >>> __ >>> 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
[Rd] Problem building (binary) packages for Windows
Hi, I am having a problem building binary packages for Windows recently. Normally, I use the "Murdoch-Sutherland" tool set, http://www.murdoch-sutherland.com/Rtools/ just build source packages by R CMD build and install these with R CMD INSTALL But now, for someone without having this tool set installed, under Win XP, with R-2.10dev (details below), I tried building a binary version with R CMD build --binary which used to work for me until recently (unfortunately I cannot specify "recently" here...) Trying to install the created .zip file with utils:::menuInstallLocal() I get an error message " package 'distr' successfully unpacked and MD5 sums checked Error in unpackPkg(pkgs[i], pkgnames[i], lib) : malformed bundle DESCRIPTION file, no Contains field " Now AFAICS I have not tried to build a bundle ... Searching the help archives, I found a posting by Uwe Ligges, http://article.gmane.org/gmane.comp.lang.r.general/64574/ saying that R CMD INSTALL --build was preferable to R CMD build --binary --- in which respect? Would this avoid the error message? So far I have not come across this error message, and packages I built with R CMD build --binary installed correctly with utils:::menuInstallLocal() Actually, the corresponding zip-file containes a second DESCRIPTION file in the top folder, like a bundle, which I think is the culpit, and after deleting this installation worked out fine. Could you please check what caused this second DESCRIPTION file to be generated? Any suggestions welcome, Best, Peter -- platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status Under development (unstable) major 2 minor 10.0 year 2009 month 04 day26 svn rev48404 language R version.string R version 2.10.0 Under development (unstable) (2009-04-26 r48404) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem building (binary) packages for Windows / resolved
Hi Dunchan, thanks for your quick answer. >> Searching the help archives, I found a posting by Uwe Ligges, >>http://article.gmane.org/gmane.comp.lang.r.general/64574/ >> saying that >>R CMD INSTALL --build >> was preferable to >>R CMD build --binary >> --- in which respect? Would this avoid the error message? > > The main benefit is that links between help pages will be more likely > to be set correctly. Thank you for clarifying this; in fact R CMD INSTALL --build produced the same problem for me (see below). [snip] >> Actually, the corresponding zip-file containes >> a second DESCRIPTION file in the top folder, like a >> bundle, which I think is the culpit, and after >> deleting this installation worked out fine. [snip] > You can't have two files with the same name in the same folder in > Windows. Yes, but this is not what happened: The zip file produced by either R CMD build --binaryor R CMD INSTALL --build had the following folder structure (below the top folder, "+" indicating subfolder) + ++chtml ++demo . ++R ++R-ex The two DESCRIPTION files were in different folders: the first one in the top folder (at the wrong place), the second one in the folder (at the right place). Both DESCRIPTION files were identical. > I use Rcmd INSTALL --build most of the time and have never seen your > error. so did I > I just tried Rcmd build --binary and the file installed okay. > Can you give a recipe to reproduce the error? In fact --- as Brian Ripley pointed out in another reply --- this was a transient effect of R-2.10.0dev between April 26 (my "old" devel version) and today. It appeared for both R CMD build --binary mypkg and R CMD INSTALL --build mypkg The problem did not happen for an older devel version --- R version 2.9.0 Under development (unstable) (2009-02-18 r47956) So apologies for stirring you up with something that had been fixed in the mean-time already. Best, Peter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem building (binary) packages for Windows
Prof Brian Ripley schrieb: > That version of R-devel is not current, so please update it. > I think it might have been in an interval where we tried out > verious fixes for building bundles and some of them broke > other things. Yes, I really should have updated; in fact the error re-disappeared again using the most recent version. --- But the fix must have happened within the last two weeks In fact, before posting, I had a look at http://developer.r-project.org/blosxom.cgi/R-devel but did not find anything that was pointing to the direction that the problem had been solved in the period April 26 (release date of my "old" R-devel version) and today. Nor had I found anything pointing to either R CMD build nor to bundles changed in the interval Feb 09 -- April 26, but the error-causing changes must have happened within this period --- So my fault not having updated gratefully ackowledged, it would also be nice to be somewhat more detailed in filling the NEWS file then... > In general if you use R-devel or R-patched you need to update before > reporting any difficulties. 'Under development' needs to be taken > seriously. > > On Fri, 15 May 2009, Peter Ruckdeschel wrote: > >> Hi, >> >> I am having a problem building binary packages for >> Windows recently. >> >> Normally, I use the "Murdoch-Sutherland" tool set, >> http://www.murdoch-sutherland.com/Rtools/ >> just build source packages by >> R CMD build >> and install these with >> R CMD INSTALL >> >> But now, for someone without having this tool set installed, >> under Win XP, with R-2.10dev (details below), I tried >> building a binary version with >> R CMD build --binary >> which used to work for me until recently (unfortunately I >> cannot specify "recently" here...) >> >> Trying to install the created .zip file with >> utils:::menuInstallLocal() >> >> I get an error message >> " >> package 'distr' successfully unpacked and MD5 sums checked >> Error in unpackPkg(pkgs[i], pkgnames[i], lib) : >> malformed bundle DESCRIPTION file, no Contains field >> " >> >> Now AFAICS I have not tried to build a bundle ... >> >> Searching the help archives, I found a posting by Uwe Ligges, >> http://article.gmane.org/gmane.comp.lang.r.general/64574/ >> saying that >> R CMD INSTALL --build >> was preferable to >> R CMD build --binary >> --- in which respect? Would this avoid the error message? > > That's rather old as well: now the second calls the first on Windows. > What may matter is whether you specify -l on R CMD INSTALL --build > (R CMD build --binary does), as installing into the main library does a > better job of resolving HTML cross links. > > So the advice is to use R CMD INSTALL --build *and* install into the > main library (or the library where you install all your add-on packages). > Thank you for clarifying this and once again apologies for stirring you up with something that had been fixed in the mean-time already. Best, Peter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem building (binary) packages for Windows
Dear Brian, Martin, and Uwe, thanks for your explanations; I have already replied to you in another mail; so I would only like to add some points here. On Sat, 16 May 2009, Martin Maechler wrote: > On Sat, 16 May 2009, Martin Maechler wrote: > >>> "UweL" == Uwe Ligges >>> on Fri, 15 May 2009 20:48:03 +0200 writes: >> >> [.] >> >>>> Thank you for clarifying this and once again apologies for >> stirring you >>>> up with something that had been fixed in the mean-time already. >> >>UweL> For R-devel, it is in the svn logs. Since it may change >> again, NEWS is >>UweL> not always edited while things are tested. >> >> well, and if a new feature is introduced, it gets a NEWS entry >> (hopefully), but if the new feature contains bugs, these will be >> fixed of course with*OUT* another NEWS entry. >> >> Indeed, the NEWS apply to (eventually) released versions of R, >> so fixing transient bugs is *never* documented in NEWS. >> >> ... leading us back to what Brian already said: >> >> 'Under development' needs to be taken seriously. > > This was a Windows-only issue, so the final version was reported in the > May 1 entry in src/gnuwin32/CHANGES, not NEWS: > > o Rcmd INSTALL --build in 2.9.0 did not make _bundles_ in the > format install.packages() expected. Touché: I have not been aware of this; and at first glance I would not have seen the connection to the double DESCRIPTION file either; sorry for this. > [When I looked that was missing from the RSS feed for R-devel, so perhaps > another message is to look at the NEWS/CHANGES files directly.] Point taken; see also my other reply to all of you. > As far as I can see from the svn logs, the first attempt at a fix was > on April 25 > and that was changed to the more successful current solution on April > 27 (well over two > weeks ago, _pace_ claims earlier in the thread). Obviously, my fault was not to look into the CHANGES and the svn log files. Actually, looking through the svn logs, I have now spotted the changes in r48400 to have caused the double DESCRIPTION file I was complaining about in my initial posting (in a non-bundle package, btw). This effect must have survived until r48404, the revision that I was using when posting the initial question. So once again: Sorry for taking your time with this unnecessary posting --- hopefully I have learnt my lesson. Best, Peter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] was: Problem building (binary) packages for Windows
Dear Martin, Uwe and Brian thanks for your comments --- point taken: On Sat, 16 May 2009, Martin Maechler wrote: >> "UweL" == Uwe Ligges >> on Fri, 15 May 2009 20:48:03 +0200 writes: >> > > [.] > > >> Thank you for clarifying this and once again apologies for stirring you > >> up with something that had been fixed in the mean-time already. > > UweL> For R-devel, it is in the svn logs. Since it may change again, NEWS > is > UweL> not always edited while things are tested. > > well, and if a new feature is introduced, it gets a NEWS entry > (hopefully), but if the new feature contains bugs, these will be > fixed of course with*OUT* another NEWS entry. > > Indeed, the NEWS apply to (eventually) released versions of R, > so fixing transient bugs is *never* documented in NEWS. > Convinced. And to make this clear: I did not mean at all to criticize any development undertaken in R-devel --- you are all doing a great job in enhancing R, and you deserve all due acknowledgement for this. My point was rather that instead of keeping one's own checkout repository of the R project's svn archives, it would help somehow to make changes visible / accesible more easily --- of course without bothering R core developers to actively maintain this, but rather do this in an automatic way. Embarrasingly enough, now that you have explained to me the different purposes of NEWS and svn logs, I realized that there already is http://developer.r-project.org/R.svnlog.2008 (the name of which might get updated to /R.svnlog.2009, though) Still, one might improve upon this without to much effort, I think. Possible starting points could be (1) webSVN + trac access to the R subversion repository (2) using some r-forge type architecture for R core as well, --- in particular for the source code management provided there (3) setting up an RSS feed for the svn logs not unlike http://developer.r-project.org/blosxom.cgi/R-devel As one more step ahead one could think of (4) merging corresponding RSS feeds for CHANGES, NEWS, and the svn logs in order to see all changes on one spot. Do you think setting up any of these items would be hard to establish? Maybe this is already done; but I have not been aware of this. > ... leading us back to what Brian already said: > >> 'Under development' needs to be taken seriously. > if asked, I would have agreed before, and surely now do even more so... Thanks again, best Peter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Awkward escaping with five backslashes within \code{ } in new parse_Rd
Hi R-devels,
I noticed that you are working quite actively on the new Rd-parser
and have made it the default renderer in R-2.10.0dev. So I would
like to come back on an issue I have already raised on this list
last November
("Two minor escaping issues using \preformatted{} in Rd format")
My setting has slightly changed as \preformatted, AFAICS is not
supported within \describe environments, so I have switched to
\code{} ...
The issue is again the correct typesetting of
\%
within a \code{}-tag.
This sequence occurs within a string (hence valid R code) in the
documentation to my CRAN package SweaveListingUtils.
So far the new parser cannot swallow such sequences
of 5 backslashes followed by a percent sign correctly, but rather
still throws an error;
as the former parser, it can digest it if I leave a space between the
fourth and fifth backslash, but then also prints this space out what is
not what I want.
Now admittedly this is not an urgent question, but if you are
working on the parser anyway, you might perhaps try to make my
sequence digestible, too.
Best regards,
Peter
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Awkward escaping with five backslashes within \code{ } in new parse_Rd
Dear R-devels,
dear Duncan,
just to close this thread...
> Peter Ruckdeschel wrote:
>> Hi R-devels,
>>
>> I noticed that you are working quite actively on the new Rd-parser
>> and have made it the default renderer in R-2.10.0dev. So I would
>> like to come back on an issue I have already raised on this list
>> last November
>>
>> ("Two minor escaping issues using \preformatted{} in Rd format")
>>
>> My setting has slightly changed as \preformatted, AFAICS is not
>> supported within \describe environments, so I have switched to
>> \code{} ...
>>
>> The issue is again the correct typesetting of
>>
>>
>> \%
>>
>> within a \code{}-tag.
>>
>> This sequence occurs within a string (hence valid R code) in the
>> documentation to my CRAN package SweaveListingUtils.
>>
>
> That's not valid R code within a string, because \% is not a valid escape.
>
This was indeed the issue.
Omitting the fifth backslash respectively solved it.
> I think this is a case where you are not going to be able to find
> something that is compatible with both the old and new systems. If you
> want to know how to get particular output in the new system, I'd be
> happy to help: just tell me exactly what you want.
>> So far the new parser cannot swallow such sequences
>> of 5 backslashes followed by a percent sign correctly, but rather
>> still throws an error;
>>
>> as the former parser, it can digest it if I leave a space between the
>> fourth and fifth backslash, but then also prints this space out what is
>> not what I want.
>>
>> Now admittedly this is not an urgent question, but if you are
>> working on the parser anyway, you might perhaps try to make my
>> sequence digestible, too.
>
> I need more information about what you want the output to look like, in
> text, for example.
In an offline mail, I had sent links to the corresponding .Rd files
directly to Duncan, who then checked that the solution given
produced parsed code as desired.
> Because the Rd format is so ornate, I need more than
> just the particular string: please send me the surrounding text, what
> your intentions are, and a large payment in unmarked bills. Or at least
> the first two.
I think I now owe some bills to Duncan ;-)
[thanks to him once again!]
Best, Peter
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] some (minor) Rd issue: line breaking in \S4method within \usage{}
Hi,
this is perhaps not so much an issue, but as you are currently
working on the Rd parser anyway...
When you want to document specific S4 methods for an S4 generic
by \S4method{} within a \usage{} environment, and the second
(signature_list) argument is "long", be it because you use multiple
dispatch, be it because you use long class-names, (or both), one
would probably like to be able to insert line breaks within the
signature list [or at least insert line breaks at suitable places
in the corresponding generated pdf file].
AFAICS this is not possible so far, at least I get errors in
R CMD check, whenever I try something like
\S4method{}{,
}(,)
i.e. if I insert a line break in the Rd file after any item of the
signature_list argument to \S4method.
Using line breaks in the the third (argument_list) argument is not a
problem, though.
So my little RFE would be to ask you to allow some optional line
breaking mechanism for the second argument of \S4method, too,
if this is not too hard to achieve.
Best regards
Peter
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] [not extremely urgent:] modifiying messages on overriding implicit S4 generics + intended maskings
Hi r-devels,
I am coming with an RFE which is probably not extremely
urgent, dealing with (optionally) modifiying messages
on overriding implicit S4 generics + intended maskings
according to some (optional) pkg-individual files.
Details are shown below.
Any comments welcome,
Best, Peter
=
An aside right away:
For functions with many arguments, would it
be a bad idea to propose to make the implicit
S4 generic dispatch on less arguments (say the
first 2-3)?
=
DETAILS:
%
Overriding default S4 generic
%
In our distr-family of packages, we are about
to write S4 methods for qqplot for several
(mostly distribution-type) signatures.
In order to avoid to have to dispatch on too many
arguments, we would like to use the following generic
setGeneric("qqplot", function(x, y, ...) standardGeneric("qqplot"))
while we would register the original qqplot function from
package stats as
setMethod("qqplot", signature(x="ANY",y="ANY"), function(x, y,
plot.it = TRUE, xlab = deparse(substitute(x)),
ylab = deparse(substitute(y)), ...){
mc <- match.call(call = sys.call(sys.parent(1)))
if(missing(xlab)) mc$xlab <- xlab
if(missing(ylab)) mc$ylab <- ylab
mcl <- as.list(mc)[-1]
return(invisible(
do.call(stats::qqplot, args=mcl)))
})
which should behave exactly the same as the original
stats function when called as usual.
Now doing so, on installing and building our package,
the following message is displayed:
Creating a generic for "qqplot" in package "distr"
(the supplied definition differs from and overrides
the implicit generic in package "stats": Formal
arguments differ: (x, y, ...), (x, y, plot.it,
xlab, ylab, ...))
I would not bother too much about this message
(which /is/ a useful information for the package
developer anyway!), but it might irritate some users
to see this.
%
intended maskings
%
For similar reasons, in our packages we intentionally
mask some (few!) functions from packages stats and base.
In each case, we try to retain their original behaviour
when called as usual (and, AFAICS, they do so), and
also document this masking in corresponding files
MASKING in the inst/ folders.
Again, this masking gets automatically noticed as
a message on attaching the packages
(which again /is/ a useful information, anyway!).
%
proposed solution
%
So, for avoiding/modifying these automatic messages
on building/installing/attaching a package, could we
have optional parsable ASCII files, say
INT_MASKING, INT_OVERR_IMPL_GENERICS
(INT for /int/entional)
or, equally well, something shorter:-) in the inst
folder of a package, which are looked up and then
a correspondingly marked section would be
displayed instead of the original message?
A suggestion for the format of these files could
be:
Two blocks, each braced by some lines beginning
with "###":
+ the first one with a list of intentionally
masked objects / overridden implicit generics,
+ the second one with a corresponding optional
message to be displayed on build/install/attach
instead of the original one (this second block
could be left empty).
The format for the list in the first block could
be: one object a line, in form ::.
In addition lines beginning with ";" would be
ignored (used as comment lines).
Example:
### begin object list
stats::qqplot
stats::df
### end object list
### begin displayed message
We intentionally mask stats functions qqplot and df,
because we have particular methods for them for
distribution-type arguments
### end displayed message
Now, each object mentioned in the first block, would no
longer be displayed within the default message on
build/install/attach (while masked objects / overridden implicit
generics remaining unmatched still do get displayed this
way).
In addition, unless the section in the corresponding
second block is empty, this section would be displayed
after the (again possibly empty) default message,
perhaps prepended by a title like "Intentional Masking"
respectively "Intentionally overridden implicit
generics".
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Recent TeX changes and R/package manuals
Dear Prof Ripley
thanks (once again) for your alert
[snip]
> As far as I can tell, the following CRAN package manuals have been
> affected:
>
> distrMod, RCurl, RGtk2, SparseM, VIM, bit, ggplot2, operators,
> relations, spam, tensorA
>
> (and only distrMod fatally).
>
> Given the current pace of change (ca 100 updates/week on 'only' 2000 TL
> packages), more things may pop out of the woodwork.
>
>
> For the curious and cognescenti:
>
> (i) hyperref is having problems with markup in \section titles, which
> 'methods' and 'distrMod' had. I've added a warning to the R-exts manual.
[snip]
A priliminary check gave that we had some instances of markup by
\code{} within \section{}. We have changed this
for '' now, but still are checking whether there are
additional things we have not seen so far.
Not an extremely urgent [xmas] wish:
Given that TeX is not the only renderer of Rd, and markup in
titles would be handy sometimes --- if I recall correctly,
in LaTeX there is Heiko Oberdiek's package 'hypbmsec' to resolve
such markup problems within titles; so if Rd-\section command
could take this up, we could still have markup in section titles;
Otoh, given that we were the only ones having fatal problems
with markup, this is probably not so important...
Anyway, thanks for stirring us up.
Peter (maintainer of 'distrMod')
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] questions as to building R from source under Windows
Hi R-devels, yesterday, on a new computer, in order to check my installation of "The Windows Toolset", I tried building R from source under Windows (in fact under Windows 7) --- and in the end succeeded. Some minor issues though (which I think should not be Windows 7 issues) which might be of more general interest: (1) TMPDIR on a different drive: --- not sure whether this was my fault or you could do anything about it: On my system, I have a separate drive for temp (i.e. E:), and had this set in a corresponding TMPDIR environment variable. During the build process of R, I had difficulties with this, which were only resolved when I created a tmp folder on the same drive (i.e. C:) and set environment variable TMPDIR to this new folder. Is this a known issue /can you reproduce this? If this is a more general issue, you might want to mention this in R-admin / or the documentation to Rtools. (2) TCL: Although I set the path to TCL in MkRules, line 26 to C:\Program Files\R\Tcl , in stepmake rinstaller I ran into problems, because the build process was assuming (hard-coded, it seems) the Tcl files to reside in ../../../Tcl (from gnuwin32 folder, which is not the above set path). Did I miss something? Everything worked fine after I had copied the /Tcl folder to ../../../Tcl ... (3) JPEG Meanwhile the most recent version of jpeg sources is v8, which is what I downloaded; I succeeded in building R with this version after a little manual change in bitmap/Makefile . -> Could you change line 10 in bitmap/Makefile so that it would branch not only according to whether version was v7 or not but rather according to whether version was larger or equal to v7 or not / or set up a v8 alternative? (4) Did not work for me: build R on D: --- a Vista / Windows 7 issue? In the end I succeeded with my build on drive C: (NTFS formatted) giving the current user full access privileges to the installation folders; before, in order to circumvent these privilege issues, I tried building R on a different drive (D:) which in my case is formatted as FAT32; somehow I got stuck with this, though; (my Rtools are on C:). Is this a known issue /can you reproduce this? Best, Peter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] questions as to building R from source under Windows
Hi Uwe, thanks for your quick reply. [... and sorry for not setting you to the CC explicitely, but I am mailing to this list through gmane ...] >> yesterday, on a new computer, in order to check my installation >> of "The Windows Toolset", I tried building R from source under >> Windows (in fact under Windows 7) --- and in the end succeeded. >> >> Some minor issues though (which I think should not be Windows 7 >> issues) which might be of more general interest: >> >> (1) TMPDIR on a different drive: >> --- not sure whether this was my fault or you could do anything >> about it: On my system, I have a separate drive for temp (i.e. E:), >> and had this set in a corresponding TMPDIR environment variable. >> During the build process of R, I had difficulties with this, >> which were only resolved when I created a tmp folder on the same >> drive (i.e. C:) and set environment variable TMPDIR to this new >> folder. Is this a known issue /can you reproduce this? >> If this is a more general issue, you might want to mention this >> in R-admin / or the documentation to Rtools. > > If your setup is correct according to the manuals, it may be a > problem in one of the cygwin tools. A more detailed description > to analyse it would be appreciated. > Yes, I guess, it was a cygwin problem; it claimed it could not access /tmp at one instance; so I concluded that environment variable TMPDIR was not set and hence set it to E:\ in the console and re-ran make all but got the same error message; when I changed this environment variable to C:\\tmp however it ran through well. Unfortunately I did not write the output / messages to files, so cannot be much more precise at this point (I may also have missed something...); I will try and do so in the next days. >> (2) TCL: >> Although I set the path to TCL in MkRules, line 26 to >> C:\Program Files\R\Tcl , in stepmake rinstaller >> I ran into problems, because the build process was assuming >> (hard-coded, it seems) the Tcl files to reside in >> ../../../Tcl (from gnuwin32 folder, which is not the above >> set path). Did I miss something? Everything worked fine >> after I had copied the /Tcl folder to ../../../Tcl ... > > > Citing the "R Installation and Administration" manual: > The Tcl/Tk support files are in a zip file at http://www.stats.ox.ac.uk/pub/Rtools/: > unzip this in R HOME, and it will add directory tree ‘R_HOME/Tcl’. > Yes, but I thought, as there was an entry in MkRules, that you could have a common Tcl folder for several, possibly different R builds /R HOME's... --- Would it be too hard to change the corresponding step in make rinstallerto use the reference given in MkRules instead of ../../../Tcl? > >> (3) JPEG >> Meanwhile the most recent version of jpeg sources is v8, >> which is what I downloaded; I succeeded in building R with >> this version after a little manual change in bitmap/Makefile . >> -> Could you change line 10 in bitmap/Makefile so that it >> would branch not only according to whether version was v7 or >> not but rather according to whether version was larger or equal >> to v7 or not / or set up a v8 alternative? > Well tested patches for the Makefile, MkRules and documentation (including manuals) are welcome. For documentation for the new jpeg version, see http://www.ijg.org/ The modification I used in bitmap/Makefile.jpeg was in fact an alternative where I simply replaced jpeg-7 by jpeg-8, but certainly a more sophisticated one (with something like ">=7") would be preferrable: ifeq ($(strip $(JPEGDIR)),jpeg-8) LIBSOURCES= jaricom.c jcapimin.c jcapistd.c jcarith.c jccoefct.c jccolor.c \ jcdctmgr.c jchuff.c jcinit.c jcmainct.c jcmarker.c jcmaster.c \ jcomapi.c jcparam.c jcprepct.c jcsample.c jctrans.c jdapimin.c \ jdapistd.c jdarith.c jdatadst.c jdatasrc.c jdcoefct.c jdcolor.c \ jddctmgr.c jdhuff.c jdinput.c jdmainct.c jdmarker.c jdmaster.c \ jdmerge.c jdpostct.c jdsample.c jdtrans.c jerror.c jfdctflt.c \ jfdctfst.c jfdctint.c jidctflt.c jidctfst.c jidctint.c jquant1.c \ jquant2.c jutils.c jmemmgr.c >> (4) Did not work for me: build R on D: >> --- a Vista / Windows 7 issue? >> In the end I succeeded with my build on drive C: (NTFS formatted) >> giving the current user full access privileges to the installation >> folders; before, in order to circumvent these privilege issues, >> I tried building R on a different drive (D:) which in my case is >> formatted as FAT32; somehow I got stuck with this, though; >> (my Rtools are on C:). Is this a known issue /can you reproduce this? > > I build R and packages on d:/ without any problems. I do not think > that the drive letter is the issues here. It may be some new MS > security policy on FAT drives - or whatever. I have not used FAT > formatted drives for serious work for at least a decade now. > Then I guess it is a FAT32 issue --- so let us drop this... Best, Peter
Re: [Rd] questions as to building R from source under Windows
once again me --- just some more precise information... [snip] >>> (1) TMPDIR on a different drive: >>> --- not sure whether this was my fault or you could do anything >>> about it: On my system, I have a separate drive for temp (i.e. E:), >>> and had this set in a corresponding TMPDIR environment variable. >>> During the build process of R, I had difficulties with this, >>> which were only resolved when I created a tmp folder on the same >>> drive (i.e. C:) and set environment variable TMPDIR to this new >>> folder. Is this a known issue /can you reproduce this? >>> If this is a more general issue, you might want to mention this >>> in R-admin / or the documentation to Rtools. >> >> If your setup is correct according to the manuals, it may be a >> problem in one of the cygwin tools. A more detailed description >> to analyse it would be appreciated. >> > Yes, I guess, it was a cygwin problem; it claimed it could not access > /tmp at one instance; so I concluded that environment variable TMPDIR > was not set and hence set it to E:\ in the console and re-ran "make all" > but got the same error message; when I changed this environment variable > to C:\\tmp however it ran through well. Argh: A closer look gave that the reason for this must have been that I had not set it to E:\ but rather to E:\tmp which in return did not exist, so no wonder for the error --- blame on me! With E:\ it now worked fine. It is noteworthy, though, to repeat Win-FAQ 2.24: For a successful build under Windows 7 (probably just as under Vista), you have to a) be logged in as a user contained in the local Administrators group and b) explicitely give full control to this user for the installation folder and all its subfolders; having these privileges for group "Administrator" does not suffice Best, Peter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] questions as to building R from source under Windows
Yet another clarification: [snip] >> (4) Did not work for me: build R on D: >> --- a Vista / Windows 7 issue? >> In the end I succeeded with my build on drive C: (NTFS formatted) >> giving the current user full access privileges to the installation >> folders; before, in order to circumvent these privilege issues, >> I tried building R on a different drive (D:) which in my case is >> formatted as FAT32; somehow I got stuck with this, though; >> (my Rtools are on C:). Is this a known issue /can you reproduce this? > > I build R and packages on d:/ without any problems. I do not think that > the drive letter is the issues here. It may be some new MS security > policy on FAT drives - or whatever. I have not used FAT formatted drives > for serious work for at least a decade now. At the end of the day, after having set the "right" TMPDIR environment variable and copied the Tcl folder as indicated in R-admin.html, it was /not/ a FAT32 issue: I managed to build it now on D:\ (although I agree with Uwe that this is probably not what you want to do if NTFS works...) best, Peter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] questions as to building R from source under Windows / small corrections for R-admin sec. 3.1.7
> Yet another clarification: > > [snip] > >>> (4) Did not work for me: build R on D: >>> --- a Vista / Windows 7 issue? >>> In the end I succeeded with my build on drive C: (NTFS formatted) >>> giving the current user full access privileges to the installation >>> folders; before, in order to circumvent these privilege issues, >>> I tried building R on a different drive (D:) which in my case is >>> formatted as FAT32; somehow I got stuck with this, though; >>> (my Rtools are on C:). Is this a known issue /can you reproduce this? >> >> I build R and packages on d:/ without any problems. I do not think that >> the drive letter is the issues here. It may be some new MS security >> policy on FAT drives - or whatever. I have not used FAT formatted drives >> for serious work for at least a decade now. > > At the end of the day, after having set the "right" TMPDIR environment > variable and copied the Tcl folder as indicated in R-admin.html, > it was /not/ a FAT32 issue: I managed to build it now on D:\ > (although I agree with Uwe that this is probably not what you want to > do if NTFS works...) > together with this --- in the end --- still a little correction for R-admin, section 3.1.7: If you really pursue stepwise as indicated after "This works by building all the parts in the sequence", it must be make rpackages (not rpackage) and you will need to insert a make -C ../../po -f Makefile.win before make rinstaller Best, Peter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] references to (1) R source code in svn repo within .Rd file and (2) to C source code in comments in R code using .Internal() /.Primitive()
Hi R-devels,
recently I wanted to quickly look up a C implementation
in R-Core code in the official subversion repository;
more specifically the code was called from R by means of the .Internal()
interface.
And: yes, I did read Uwe Ligges' article in R News,
R Help Desk: Accessing the sources. R News, 6(4):43-45, October 2006
In the end I succeeded, using grep and the like to search the sources in
R_HOME/src, but I found it rather painful ...
(in particular, if R function foo() is not implemented in file foo.R
and/or the corresponding C code is not in file ../src/foo.c )
So here my "little" two wishes:
(1) references to R code in the .Rd file
As all the R source code is accessible through
https://svn.r-project.org/R
anyway, why not link to it in .Rd files?
What about a new optional markup command \URLtoSource with
one argument (the URL); e.g. inserting to file
R_HOME/src/library/base/man/sample.Rd
the following line:
\URLtoSource{https://svn.r-project.org/R/%
branches/R-2-xx-branch/src/library/base/sample.R}
(OK, yet another markup command to be rendered by the
new Rd parser...)
Advantage: Following this link in a browser would then
also display comments in R source, without the caveats
mentioned in Uwe's article. Also no need to download and unpack
all the source tar-ball.
Disadvantage: Presumably more traffic on svn.r-project.org ...
I think (1) should be feasible automatically
(at least to a large extent).
(2) references to C code interfaced to through .Internal() /
.Primitive() as comments in R code
Could you think of an automatic way of inserting references
into the R source containing the call to .Internal() /
.Primitive() ---
some (standardized) comment with a link referring to the
respective C source file, or, even better, to the corresponding
C function(s), possibly again an URL to the svn repository ?
Example: code to sample.R
# File src/library/base/R/sample.R
# Part of the R package, http://www.R-project.org
#
--- [snip] ---
# http://www.r-project.org/Licenses/
sample <- function(x, size, replace=FALSE, prob=NULL)
{
if(length(x) == 1L && is.numeric(x) && x >= 1) {
if(missing(size)) size <- x
.Internal(sample(x, size, replace, prob))
}
else {
if(missing(size)) size <- length(x)
x[.Internal(sample(length(x), size, replace, prob))]
#
###new proposed comment:
#
### C code interfaced to is implemented in
### R_HOME/src/main/random.c
###
### or: even "nicer"
###
### corresponding C code may be inspected in
### https://svn.r-project.org/R/branches/%
### R-2-xx-branch/src/main/random.c
###
###
###
### as functions ProbSampleReplace(), ProbSampleNoReplace(),
### SampleReplace(), SampleNoReplace(), .
###
#
###end.new comment
#
}
}
--- snip ---
(The actual list of C functions would not be urgent at all;
finding the "right" source file already would mean
the big step)
As indicated in Uwe's article, one start to automatize this,
I guess, would be to build up a table with columns
R function name : R-source file : C-source file
from the entries in R_HOME/src/main/names.c
These two enhancements would help outsiders very much to spot the
corresponding code (and not the least to learn "from the Giants").
--- just a "wish for enhancement" though, certainly not of
top priority.
Any comments are welcome,
Best, Peter
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] : Operator overloading for custom classes
> > I need some help to get some of the object orientation, specifically the > methods that overload the basic arithmetic operations, from sample C++ > code to R. I don't have experience with such advanced language features > inside of R. So I was wondering if some of you could help me out in this > regard. > > I have written a simple demonstration of a forward mode automatic > differentiator in C++ and it is currently hosted on github: > http://github.com/quantumelixir/ad-demo/blob/master/simple.cpp. It uses > simple operator overloading techniques to modify the meaning of the > basic arithmetic operations (+, -, *, /) for the "derivative" type Dual > number class that I have defined. Could you show me how this could be > equivalently done in R? I want to know how to define custom classes and > define the meaning of arithmetic for them. > > I had checked for operator overloading in R but could only find the > equivalence of a + b and '+'(a, b) in the R language definition. Could > you show how I could extend the simple object oriented-ness in the C++ > code neatly to R? > > Thanks a bunch! > Chillu > > [[alternative HTML version deleted]] > First of all you should read about S4 classes, in particular the books of John Chambers should be helpful ;-) (others on this list might point you to further sources). The key is to define S4 classes for your operands [i.e; if I have understood correctly you would implement your Dual number class as S4 class]. Then you would define new methods by setMethod(). Not sure whether this gives you the indications you look for, but we have overloaded arithmetic operators to act on distribution classes in package distr (cf CRAN, developped under r-forge). You might want to look at the code in NormalDistribution.R resp. ContDistribution.R HTH Peter Ruckdeschel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Exchange of information between functions aside from argument/return-value interface
Hi R-devels, I would like to ask for your advice on the preferred way to exchange information between functions aside from the regular argument/return-value interface. I am well aware that, S being a functional language, this is to be avoided where possible. There are exceptions, though: Let myF() and myH() be functions provided by me, and notmyG() be a function provided by someone else. The calling hierarchie is myF() calls notmyG() which calls --- possibly with other functions being called in between --- myH(). notmyG() takes as argument a function with return value of type numeric --- typically a function for optimizing, integrating or zero-finding --- and is a function which I do not want to modify (and subsequently maintain the modification). As myH() is expensive as to evaluation time and, as a side effect, also provides important side information, I would like to pass this information back to myF(). (Also see example below). Using information from myF() in myH() by lexical scoping is straight forward, whereas to pass information from myH() to myF() directly, the solution I found so far is to use assign() with a corresponding envir=./pos=.-argument. (Q1) Is there a better way to do so? While it is not too difficult to find out the correct value for the envir/pos argument when using "pure" R-functions for notmyG(), the situation is a little more complicated as soon as notmyG() calls myH() through intermediate calls to .Internal() as in case of optim(), uniroot(). Is there any way to (Q2a) find out a corresponding correct value for argument envir/pos in assign ---on run-time---, i.e. how many layers of calls are between myF() and myH()? --- my first guess was to use sys.frame() but I am not convinced... (Q2b) to make myH() when called from within a call to .Internal() perform assignments in the environment of myF() ? Or should we proceed in a completely different way? Thank you already for your advice, Peter -- --- Example: To given clipping height b, myH() calculates an "optimal" influence curve which involves determining certain Lagrange multipliers in a fixed-point type algorithm. To determine b according to a certain criterium, moreover, myH() evaluates a function H0 in b, the zero of which will be the "optimal" b. So to use notmyG()=uniroot() as zero-finder the return value of myH() should be H0(b), while myF() should also get to know about the Lagrange multipliers determined in myH(). __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Exchange of information between functions aside from argument/return-value interface
Thank you, Luke, for your promptous response. [snipped away my original message; to be found on https://stat.ethz.ch/pipermail/r-devel/2007-April/045216.html] > Sounds like lexical scoping should work for this also -- use <<- to > assign to the variable in the containing scope. > > Best, > > luke yes, in my application, this really solves the problem. Thank you. But I am not quite sure for the general situation: Recall that we have the sequence of calls myF() calls notmyG() which --with possibly more functions involved in between-- directly or indirectly calls myH(). Now, if I do not know exactly which variables are defined in the intermediate notmyG() or in some of the functions called "in between", I would have thought that using VariableInMyF <<- something within myH() bears the danger that I am overwriting a variable of name VariableInMyF in notmyG() and "in-between's" instead of in myF(). Or did I get something wrong? Thanks for your help Peter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Exchange of information between functions aside from argument/return-value interface
Thank you, Luke, once again. >> [snipped away my original message; to be found on >> https://stat.ethz.ch/pipermail/r-devel/2007-April/045219.html] >> Or did I get something wrong? > > I think you did. You seem to be thinking in terms of dynamic scope, > which looks for variables in the caller and then the caller's caller. > > Lexical scope addresses exactly this problem. In lexical scope > variable references are resolved on the basis of how function > definitions are nested in the written code (hence the term lexical). > If you define myH inside myF then free variables in myH are looked up > first in myF and then in the context where myF is defined. How myH is > called does not matter. Nested functions in Pascal work the same way > if that helps. OK got it. I should have known this. I am pretty much embarrassed to have bothered you. Thanks again for your help Peter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] setIs-relation does not entail automatic coercion in S4 method dispatch --- should it?
Hi R-devels,
I am a bit puzzled about when/if "setIs-conditional" coercion is performed
in S4 method dispatch.
Setup: Myclass1 setIs()-conditionally is inheriting from Myclass2.
My first guess would have been:
If the corresponding test clause in setIs() is TRUE and there is
no Myclass1-method foo() but a Myclass2-method foo(), a call to
foo() with a corresponding Myclass1 instance as argument
automatically coerce this instance to Myclass2 using the coerce
function in setIs(). It does not; (consider the example below).
I am pretty sure that there are good reasons for this behaviour, but could you
give me arguments why this automatic coercion should not be a good idea?
###
## Begin of example
###
setClass("Myclass1",representation(a="numeric"))
setClass("Myclass2",representation(b="numeric"))
### conditional inheritance by setIs
setIs("Myclass1", "Myclass2", test = function(obj) [EMAIL PROTECTED]>0,
coerce = function(obj) {cat("setIs coercion used\n")## does not seem to
be used for
new("Myclass2", [EMAIL PROTECTED]) }, ##
automatic coercion
replace = function(obj, value) {cat("setIs replacement used\n") ## does
not seem to be used...
new("Myclass2", [EMAIL PROTECTED])
})
### accessor to slot b
if(!isGeneric("b")) setGeneric("b", function(object) standardGeneric("b"))
setMethod("b","Myclass2", function(object) [EMAIL PROTECTED])
### a method for Myclass2
if(!isGeneric("foo")) setGeneric("foo", function(object) standardGeneric("foo"))
setMethod("foo","Myclass2",function(object)cat("Myclass2-fct:",b(object),"\n"))
###
selectMethod("foo","Myclass2") ### does find foo-method for class Myclass2 as
expected
selectMethod("foo","Myclass1") ### does find foo-method for class Myclass2 as
expected
## an instance of Myclass1
MyC1 <- new("Myclass1",a=2)
MyC1.0 <- new("Myclass1",a=-2)
### implicit coercion using setIs coerce function does not work as I would have
expected:
foo(MyC1) ### does not coerce MyC1 to Myclass2 although possible
foo(MyC1.0) ### as expected: does not coerce as not possible
### explicit coercion:
foo(as(MyC1,"Myclass2")) ### works as expected: uses foo-method for class
Myclass2
foo(as(MyC1.0,"Myclass2")) ### works as expected: error as not coercable
### way out?
setMethod("b","Myclass1", function(object)
if ([EMAIL PROTECTED]>0)
[EMAIL PROTECTED]
else
stop("not coercable to class Myclass2")
)
foo(MyC1) ### works as expected: uses foo-method for class Myclass2
foo(MyC1.0) ### works as expected: error as not coercable
###
## End of example
###
Any suggestion appreciated
thanks already
Peter
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] minor flaw in integrate()
Hi,
I noticed a minor flaw in integrate() from package stats:
Taking up arguments lower and upper from integrate(),
if (lower == Inf) && (upper == Inf)
or
if (lower == -Inf) && (upper == -Inf)
integrate() calculates the value for (lower==-Inf) && (upper==Inf).
Rather, it should return 0.
Quick fix:
### old code ###
### [snip]
else {
if (is.na(lower) || is.na(upper))
stop("a limit is missing")
if (is.finite(lower)) {
inf <- 1
bound <- lower
}
else if (is.finite(upper)) {
inf <- -1
bound <- upper
}
else {
inf <- 2
bound <- 0
}
wk <- .External("call_dqagi", ff, rho = environment(),
as.double(bound), as.integer(inf), as.double(abs.tol),
as.double(rel.tol), limit = limit, PACKAGE = "base")
}
### [snip]
### new code to replace the old one ###
### [snip]
else {
if (is.na(lower) || is.na(upper))
stop("a limit is missing")
if (lower == upper){
wk <- list("value" = 0, "abs.error" = 0,
"subdivisions" = subdivisions,
"ierr" = 0 )
} else {
if (is.finite(lower)) {
inf <- 1
bound <- lower
}
else if (is.finite(upper)) {
inf <- -1
bound <- upper
}
else {
inf <- 2
bound <- 0
}
wk <- .External("call_dqagi", ff, rho = environment(),
as.double(bound), as.integer(inf),
as.double(abs.tol), as.double(rel.tol),
limit = limit, PACKAGE = "base")
}
}
### [snip]
Best, Peter
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] inaccuracy in qbinom with partial argument matching
Hi, I found the following strange effect with qbinom & partial argument matching p0 <- pbinom(0, size = 3, prob = 0.25) qbinom(p0, size = 3, prob = 0.25) ## 0 o.k. qbinom(p0-0.05, size = 3, prob = 0.25) ## 0 o.k. ## positional matching: qbinom(p0, 3,0.25) ## 0 o.k. ## partial argument matching: qbinom(p0 , s = 3,p= 0.25) ## 1 ??? qbinom(p0-0.05, s = 3,p= 0.25) ## 1 ??? qbinom(p0-0.06, s = 3,p= 0.25) ## 0 o.K. Unfortunately I have no I idea how to fix this. I guess however that this will happen for other cases as well, but I have not pursued this further. Best, Peter platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status major 2 minor 5.0 year 2007 month 04 day23 svn rev41293 language R version.string R version 2.5.0 (2007-04-23) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] inaccuracy in qbinom with partial argument matching
Petr Savicky wrote: > Brian Ripley wrote: >> I wrote: >> > ## partial argument matching: >> > qbinom(p0 , s = 3,p= 0.25) ## 1 ??? >> > qbinom(p0-0.05, s = 3,p= 0.25) ## 1 ??? >> > qbinom(p0-0.06, s = 3,p= 0.25) ## 0 o.K. >> > >> > Unfortunately I have no I idea how to fix this. >> >> You use a call that specifies your intentions accurately. This is not >> 'partial argument matching': 'p' is an exact match to the first argument >> of >> >> > args(qbinom) >> function (p, size, prob, lower.tail = TRUE, log.p = FALSE) >> >> and that is how argument matching in R is documented to work. >> >> The 'inaccuracy' is in the diagnosis: please see the FAQ. > > Let me add an explanation, why > qbinom(p0 , s = 3,p= 0.25) > does not produce an error message about missing "prob" argument: > Since "size" and "p" arguments are given, p0 is used for > the third argument and not for the first. > > Although the behavior is logical, it may not be immediately clear. > I do not see this case explicitly in FAQ or R-intro.pdf 10.3. To close this thread: First thanks to Brian and Petr for their explanation ---and to Petr for defending me. But I think, Brian was right, it was my fault not to see that qbinom's first argument 'p' was matched against my abbreviated 'prob' argument 0.25, which is ---I think--- the reason for Brian's "please see the FAQ"... Although not itself an FAQ nor in the R-intro manual, argument matching is completely & clearly described in http://cran.r-project.org/doc/manuals/R-lang.html#Argument-matching In fact my code is a badly chosen example: I am working on automatically generated q-, (and r,d,p)- functions, so left continuity of q<>-fct.'s is an issue. Unfortunately numbers p0 and .25 are so close together that they gave results only differing by 1 when interchanged, so I was led to the conclusion that it was a left-continuity-issue of qbinom with partial matched arguments which it was obviously not ---sorry for bothering you. As a conclusion which may be worth noting for other occasions as well: Be careful with partial argument matching ! Best, Peter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] minor flaw in integrate()
Thanks Martin and Duncan for your comments, Martin Maechler wrote: >>>>>> "DM" == Duncan Murdoch <[EMAIL PROTECTED]> >>>>>> on Mon, 02 Jul 2007 21:56:23 -0400 writes: > > DM> On 28/06/2007 5:05 PM, Peter Ruckdeschel wrote: > >> Hi, > >> > >> I noticed a minor flaw in integrate() from package stats: > >> > >> Taking up arguments lower and upper from integrate(), > >> > >> if (lower == Inf) && (upper == Inf) > >> > >> or > >> > >> if (lower == -Inf) && (upper == -Inf) > >> > >> integrate() calculates the value for (lower==-Inf) && (upper==Inf). > >> > >> Rather, it should return 0. > > DM> Wouldn't it be better to return NA or NaN, for the same reason > Inf/Inf > DM> doesn't return 1? > > DM> Duncan Murdoch > > Yes indeed, I think it should return NaN. not quite convinced --- or more precisely: [ Let's assume lower = upper = Inf here, case lower = upper = -Inf is analogue ] I'd say it depends on whether the (Lebesgue-) integral integral(f, lower = , upper = Inf) is well defined. Then, by dominated convergence, the integral should default to 0. But I admit that then a test is.finite(integrate(f, lower = , upper = Inf)$value) would be adequate, too, which makes evaluation a little more expensive :-( If, otoh integrate(f, lower = , upper = Inf) throws an error, I agree, there should be a NaN ... Best, Peter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] BLAS / LAPACK version information from within R-session?
Hi, for diagnostic purposes, I would like to get information about the BLAS / LAPACK linked against R from within an R-session. An obvious application could be safety-checks for packages like Matrix and quantreg at load / attach - time. Also you could be more precise on the "framework" in which R is running for comparable benchmark timings on different systems. Perhaps this information may even be included into the output of R.Version() :-) ? So my question: Is this possible/reasonable at all? My impression is that it is not trivial, as you may ---at least on Win32--- even replace the standard Rblas.dll by some of the "better" Rblas.dll 's available on http://cran.at.r-project.org/bin/windows/contrib/ATLAS/ without telling R in any way before launching R. In the (Win32) case I imagine you could read out the StringFileInfo of the Rblas.dll being used --- which, for the time being, however, does not yet contain information on the BLAS version. But a (mid term) solution could be: (1) For building Rblas.dll from source, extend src/gnuwin/dllversion.rc from the standard R tar-ball to a new ressource file, say, src/gnuwin/blasdllversion.rc including version information on BLAS/LAPACK which is then used for building Rblas.dll. (2) Successively replace files from http://cran.at.r-project.org/bin/windows/contrib/ATLAS/ by ones built against blasdllversion.rc Unfortunately, I have no idea whether/how you could use information similar to StringFileInfo in other OS's ... Any suggestions appreciated. Best, Peter Ruckdeschel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Sweave.sty problems under WinXP (English locale) with default settings
Hi R-devels,
I encounter the following problem when I want to build a vignette
in the package building process under Windows
platform i386-pc-mingw32
arch i386
os mingw32
system i386, mingw32
status
major 2
minor 7.0
year 2008
month 04
day22
svn rev45424
language R
version.string R version 2.7.0 (2008-04-22)
TeX-Distribution: MikTeX 2.7
My R home directory is the default one:
C:\Program Files\R\R-2.7.0,
so R.home() from package tools makes out of it
"C:\\PROGRA~1\\R\\R-27~1.0"
which does not contain spaces, but instead the special
character ~ .
So function texi2dvi() from package tools makes texi2dvi
include the directive
\usepackage{C:\PROGRA~1\R\R-27~1.0\share\texmf\Sweave}
into the corresponding .tex file for the vignette, and, consequently,
MikTeX throws an error (due to the ~'s).
According to
http://developer.r-project.org/blosxom.cgi/R-devel
this is due to a change on Apr 15.
If I am right, the use of short filenames (without spaces)
as to be found in %R_HOME% for
MikTeX (and tetex) would no longer have been necessary:
http://wiki.lyx.org/LaTeX/FilesWithSpecialChars
So an easy way out would be to revert the changes made in
R-2.7.0 and instead use a quoted version of the full path
constructed by normalizePath().
In the mean time, of course one might simply alert people
to have Sweave.sty on their tex filename database / search path
and to include \usepackage{Sweave} in their .Rnw files.
Best,
Peter
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] relative path to source files in vignette
Hi,
this may be slightly off-topic, but as you are the experts:
we have written a small vignette, in which we want to refer to
.R, .Rd source files by means of relative paths.
More specifically, we want to use TeX package "listings" to include
source code,
[which btw in the mean time works pretty well together with "fancyvrb"
so can be used
with Sweave without problems...]
To avoid redundancy we would like to use
\lstinputlisting[firstline=,lastline=]{}
and to do so we somehow need path information.
This is /not/ a "listings" issue, as we might also have used
\input{}, only is \lstinputlisting a bit more
flexible...
Using relative paths, i.e. as the vignette resides in subfolder "inst/doc"
something like
../../..//R/or ../../..//man/
does the job for both R CMD build and R CMD check ,
--- in standard configurations.
However, as you may change the location of the check folder with
the -o option of R CMD check, (and possibly other things, we have
not yet thought of ...), our solution is not quite satisfactory,
so we have been wondering whether there is a (platform-independent)
way to access the package source folder (under check) from within
TeX.
--- or if you prefer to solve it from R-side:
We would appreciate an Sweave-chunk to do the following:
+have three arguments firstline, lastline, filename
[where filename is relative to the package source folder]
+read out the information about the path to the package
source folder [from the env-variable?]
+with this information read in the part of the source file
between and
and places this content ---without wrapping it to
\begin{Schunk} ... \end{Schunk}--- into the .tex file
---preferrably already into a \begin{listing}\end{listing}
environment...
Any suggestions how to resolve this?
Thank you already,
Peter
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] relative path to source files in vignette
Gabor Grothendieck schrieb: > See ?system.file with the package= argument. > Thank you Gabor, but this refers to the /installed/ package, while we are needing path information about the not-yet-built source code of the package during R CMD check / build. Peter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] relative path to source files in vignette
Thanks again Gabor, for your quick reply,
> Try placing a copy of the files in the inst directory and then
> accessing them via system.files("myfile.R", package = "mypackage")
>
you mean I should do this in an S-chunk in the .Rnw file?
I.e., running Sweave on it would then produce the copy into my Sweave file
I need?
This could indeed be an opition, but as noted in my reply to Robert, my
guess
is that in the library where you install your packages to and which is
found with
system.file(), you will no longer find the R source files but rather
some .rdb
or .rdx file. At least this is what I found --- or is there some magic trick
to get back the source files from this?
> or place them in the same directory as the Sweave file
> and then access them without a directory path at all:
> readLines("myfile.R")
>
If I put the sources statically into the same directory as the Sweave file
(i.e. in [...]/myRsources/myPkg/inst/doc),
of course everything works fine;
The issue is that I want to "dynamically" include parts of the source
R code itself (without unnecessary static copying the source R code
due to consistency traps, when changing the R code but not
the copy) from the R directory of the package into the Sweave
file by something like
\input{[Path]/myRfile.R}
so that once I change the R code, I do not have to change
the .Rnw file.
[I do not include the whole .R file but only certain lines of it, of course]
As already said, in a standard configuration something like
\input{../../../myPkg/R/myRfile.R}
% goes from [...]/myRSources/myPkg/inst/src to [...]/myRSources/myPkg/R
% in R CMD build
% resp. from [...]/myRSources/myPkg.Rcheck/inst/src to
[...]/myRSources/myPkg/R
% in R CMD check
does the job.
Now if I am in [...]/myRSources and say something like
R CMD build myPkg ### still works
R CMD check myPkg -o /yetAnotherPath/myCheck
## does not work as /yetAnotherPath/myPkg/R need not be [...]/myPkg/R
So what I was looking for was something like defining an environment
variable
$myRSources (in a platform-independent way)
which may be accessed (in a platform-independent way) from
the TeX command \input{...} --- perhaps with something like
\input{$myRSources/myPkg/R/myRfile.R}
but I cannot figure out how to do this...
Thank you once again
Peter
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Version information for S4 classes --- elementary version management
Hi,
we are about to update some class definitions in our distrXXX family
of packages, so I would be eager to know whether there are plans
in R Core to implement some version management tools for
S4 classes as described in section 7.4 in JMC's "Green Book".
In his recent book (continuing the color scheme, is it to be called
the "Yellow Book"? :-), this topic has not been taken up again, so
we are not sure whether there still is the goal to go into this direction...
We have already implemented some "individual" sort of (class) version
management in our packages, but as this issue does not only concern
our packages, some standardized proceding would be desirable.
AFAICS, in R 2.8.0, by default when save()ing/load()ing single S4
objects, the corresponding class definitions are not saved/restored
along, while they are saved() and again restored on load() by default
when producing an image by save.image(), although an existing
class definition will not be overwritten.
So when load()ing an (old) S4 object, by default there will be no
information about the class definition at save() time available.
Of course, conceptually, such information would best be stored
in the respective classRepresentation object; however, as this one
does not get save()d automatically along with an object, we might
think of alternatives. It might at least be a compromise to store the
some version information as a special slot to every object of
any S4 class.
For S4 classes defined in packages (which should make for
the vast majority of them), default information could be obtained
from the package version tag in the DESCRIPTION file.
The rationale behind this is that an updated class definition would
at least be traceable to one particular package version, while
on the other hand the package version string is not a "large" object.
Based on this package version information, (elementary)
version management could then be provided by means of
generic functions
getClassVersion() [as described in the Green Book, 7.4]
conv2NewVersion() ## by default issuing an error ("Not yet defined")
isOldVersion() ## true or false; by default NA
Defining particular methods for his classes, a package maintainer
could then issue specific warnings or --- at its best --- even
provide coercing methods.
What do you think about this?
Best, Peter
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] relative path to source files in vignette [a solution somehow]
Gabor Grothendieck schrieb:
> On Fri, Oct 10, 2008 at 7:06 PM, Peter Ruckdeschel
> <[EMAIL PROTECTED]> wrote:
>
[snip]
>> This could indeed be an option, but as noted in my reply to Robert, my
>> guess is that in the library where you install your packages to and which is
>> found with system.file(), you will no longer find the R source files but
>> rather
>> some .rdb or .rdx file. At least this is what I found --- or is there some
>> magic trick to get back the source files from this?
>>
>
> Yes, that is what occurs. That's why it was suggested to copy it.
>
>
>
Not sure whether this is helpful to anyone else out there, but
here is my solution:
I could not find a satisfactory automatic solution
%
(which should find the source folder[s] to my package[s]
automatically and correspondingly, in R should fill string
variables),
%
so I placed a README file into the inst/doc folder where
I explain that to build / check / install my package[s] including
the building of the vignette, one either has to call R CMD from
the parent folder of the source folder to my package (distr)
or one has to define path(s) in a file myPATH.
In the preamble of my .Rnw file, I put
%--
% --- begin of code from newDistribution.Rnw in pkg distr --- %
%
<>=
if(file.exists("myPATH")){
cat("\\def\\distrPATH{",readLines("myPATH")[1],"}\n",sep="")
cat("\\def\\distrExPATH{",readLines("myPATH")[2],"}\n",sep="")
}else{
cat("\\def\\distrPATH{../../../distr}\n",sep="")
cat("\\def\\distrExPATH{../../../distrEx}\n",sep="")
}
@
%%%
% define \lstinputlistingWithPath to be able to work with
% path information (parameter #2)
% so syntax for \lstinputlistingWithPath
%
%\lstinputlistingWithPath[key=value-list]{}{}
%
% which then calls \lstinputlisting[key=value-list]{/}
%(but where may be a macro which is expanded)
%%%
%
\makeatletter
[EMAIL PROTECTED]
[EMAIL PROTECTED]@lstinputlistingWithPath[]}}
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]/#3}
}
\makeatother
%
% --- end of code from newDistribution.Rnw in pkg distr --- %
%--
and in the .Rnw file I use
\lstinputlistingWithPath[firstline=, lastline = ]%
{\distrPATH}{R/.R}
resp.
\lstinputlistingWithPath{\distrPATH}%
{man/.Rd}
to include some man-file.
>
> Perhaps you should just preprocess your Sweave files prior to the build.
> The brew package could be used, for example.
>
I should have a look to it.
Thank you once again,
Peter
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] puzzled by cat() behaviour when argument '...' is a vector (and argument 'sep' contains "\n")
Hi r-devels,
I am a bit puzzled by the behaviour of cat() --- any help is appreciated...
At least AFAICS, cat() for vector-valued '...' argument behaves in
contradiction to what I understand from the note in the help to cat()
which reads
"
Despite its name and earlier documentation, 'sep' is a vector of
terminators rather than separators, being output after every
vector element (including the last). Entries are recycled as
needed.
"
reproducible example code:
>cat(rep("x",3), sep = ".")
x.x.x
## no "." appended!
Things get even worse if "\n" features in the 'sep' vector:
>cat(rep("x",3),sep = c(".","\n","."))
x.x
x
>
## last separator "." gets swallowed; an non-intended line feed is
inserted
code causing this behaviour
# "\n"
I have looked a bit into the source code
(lines 468-630 in builtin.c in src/main)
and found out, as variable pwidth is set to 1 in line 504, i.e.;
if (strstr(CHAR(STRING_ELT(sepr, i)), "\n")) nlsep = 1; /* ASCII */
the code in lines 622-23, i.e.;
if ((pwidth != INT_MAX) || nlsep)
Rprintf("\n");
is responsible for the newline. Is this really intended?
# separators, not terminators
Another look shows that, contrary to what is said in the help file,
an element of vector 'sep' is /not/ printed out after each element
of the vector passed as argument '...' to cat(), "including the last"
--- confer the for-loop over the elements of '...' in lines 596-617
and the print-out of the separator
cat_printsep(sepr, ntot);
in line 600. Once again: Is this intended?
A patch fixing my problem would be easy, though might crash
other much more important code; would you have any
proposals?
Best,
Peter
---
Version:
platform = i386-pc-mingw32
arch = i386
os = mingw32
system = i386, mingw32
status = Under development (unstable)
major = 2
minor = 9.0
year = 2008
month = 10
day = 01
svn rev = 46589
language = R
version.string = R version 2.9.0 Under development (unstable)
(2008-10-01 r46589)
Windows XP (build 2600) Service Pack 3
Locale:
LC_COLLATE=German_Germany.1252;LC_CTYPE=German_Germany.1252;LC_MONETARY=German_Germany.1252;LC_NUMERIC=C;LC_TIME=German_Germany.1252
Search Path:
.GlobalEnv, package:stats, package:graphics, package:grDevices,
package:utils, package:datasets, package:methods, Autoloads, package:base
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Two minor escaping issues using \preformatted{....} in Rd format
Hi r-devels,
I have two minor problems with special characters in Rd files when
used within a \preformatted{} markup command:
--
1. issue: backslash + single brace
--
I would like to write "\\\}" to produce \} on output (documenting
the need to escape the brace once again before TeX-ing it);
this fails if there is no space between the second and third
backslash, but works if there is a space, but this produces
\ } then
--
2. issue: backslash + percent sign
--
I would like to write "\%" to give a string argument \\% on
output; this is needed for documenting how to register special
operators to TeX package 'listings'.
Again this fails, while " \%" works.
In neither case 1 or 2 the standard TeX trick to produce a
linebreak in the source without producing a space on output
helps, i.e.
\\%
\}
resp.
%
\%
both produce valid code [the resp. first % is read as a comment
sign] but also insert a non-intended space in the output.
Any idea how to circumvent this?
Best, Peter
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Wishlist: optional svn-revision number tag in package DESCRIPTION file
Hi,
just a little wish :
Could we have one (or maybe more) standardized optional tag(s)
for package DESCRIPTION files to cover svn revision info?
This would be very useful for bug reporting...
I know that any developer is already free to append corresponding lines
to DESCRIPTION files to do something of this sort --- e.g. lines like
LastChangedDate: {$LastChangedDate: 2009-03-31 $}
LastChangedRevision: {$LastChangedRevision: 447 $}
and correspondingly setting the svn keyword properties "LastChangedDate"
and "LastChangedRevision" would clearly do (even without Makefile /
configure ...)
But as package development under svn (especially under r-forge)
is just so frequent, it would be nice to have a recommended
format that could be read out in a standardized form, say
by a function like packageDescription from package 'utils':-)
I would vote for optional extra tags "LastChangedDate"
and "LastChangedRevision".
I have attached a commented and correspondingly
modified version of packageDescription() --- if you find it
helpful feel free to integrate it to package 'utils'.
Best,
Peter
# File src/library/utils/R/indices.R
# Part of the R package, http://www.R-project.org
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# A copy of the GNU General Public License is available at
# http://www.r-project.org/Licenses/
packageDescription <- function(pkg, lib.loc=NULL, fields=NULL, drop=TRUE,
encoding = "")
{
retval <- list()
if(!is.null(fields)){
fields <- as.character(fields)
retval[fields] <- NA
}
pkgpath <- ""
## If the NULL default for lib.loc is used, the loaded packages are
## searched before the libraries.
if(is.null(lib.loc)) {
if(pkg == "base")
pkgpath <- file.path(.Library, "base")
else if((envname <- paste("package:", pkg, sep = ""))
%in% search()) {
pkgpath <- attr(as.environment(envname), "path")
## could be NULL if a perverse user has been naming environmnents
## to look like packages.
if(is.null(pkgpath)) pkgpath <- ""
}
}
if(pkgpath == "") {
libs <- if(is.null(lib.loc)) .libPaths() else lib.loc
for(lib in libs)
if(file.access(file.path(lib, pkg), 5) == 0L) {
pkgpath <- file.path(lib, pkg)
break
}
}
if(pkgpath == "") {
## This is slow and does a lot of checking we do here,
## but is needed for versioned installs
pkgpath <- system.file(package = pkg, lib.loc = lib.loc)
if(pkgpath == "") {
warning(gettextf("no package '%s' was found", pkg), domain = NA)
return(NA)
}
}
## New in 2.7.0: look for installed metadata first.
if(file.exists(file <- file.path(pkgpath, "Meta", "package.rds"))) {
desc <- .readRDS(file)$DESCRIPTION
if(length(desc) < 1)
stop(gettextf("metadata of package '%s' is corrupt", pkg),
domain = NA)
desc <- as.list(desc)
} else if(file.exists(file <- file.path(pkgpath,"DESCRIPTION"))) {
dcf <- read.dcf(file=file)
if(NROW(dcf) < 1L)
stop(gettextf("DESCRIPTION file of package '%s' is corrupt", pkg),
domain = NA)
desc <- as.list(dcf[1,])
} else file <- ""
if(file != "") {
## read the Encoding field if any
enc <- desc[["Encoding"]]
if(!is.null(enc) && !is.na(encoding)) {
## Determine encoding and re-encode if necessary and possible.
if((encoding != "" || Sys.getlocale("LC_CTYPE") != "C")
&& capabilities("iconv")) {
## might have an invalid encoding ...
newdesc <- try(lapply(desc, iconv, from=enc, to=encoding))
if(!inherits(newdesc, "try-error")) desc <- newdesc
else
warning("'DESCRIPTION' file has 'Encoding' field and
re-encoding is not possible", call. = FALSE)
} else
Re: [Rd] Wishlist: optional svn-revision number tag in package DESCRIPTION file
Thanks Gabor, Duncan, and Dirk,
for your replies.
Gabor Grothendieck wrote:
> We need to make sure we understand the implications
> for packages developed under the other major version
> control systems like git, bzr and hg.
Ok for this --- of course it would even be "greater" to have
a universal replacement scheme for general version control
systems in R for DESCRIPTION files, but actually for the moment
I would already be content with some R tools (possibly a collection
of them) for each version control system individually.
> On 31 March 2009 at 12:58, Duncan Murdoch wrote:
> | On 3/31/2009 10:41 AM, Peter Ruckdeschel wrote:
> | > Could we have one (or maybe more) standardized optional tag(s)
> | > for package DESCRIPTION files to cover svn revision info?
> | > This would be very useful for bug reporting...
>
> Indeed. I am doing something similar with local packages at work.
>
> | > I know that any developer is already free to append corresponding lines
> | > to DESCRIPTION files to do something of this sort --- e.g. lines like
> | >
> | > LastChangedDate: {$LastChangedDate: 2009-03-31 $}
> | > LastChangedRevision: {$LastChangedRevision: 447 $}
> |
> | That will give you the last change to the DESCRIPTION file, not the last
> | change to the package, so it could be misleading. Last time I looked,
> | there wasn't a way in svn to auto update a file that wasn't involved in
> | a changeset.
Ouch. I stand corrected; and I have to say: this even is an FAQ
in the SVN documentation... So using svn properties will not work indeed.
Still, my wish for a better integration of version control
information into R persists...
So if I understand correctly, under linux / cygwin (Mac I don't know)
you would use some scripting to read out the output of svnversion;
let me add that under Windows + Tortoise SVN you would have
SubWCRev (http://tortoisesvn.tigris.org/faq.html#subwcrev) to help you.
> (You could put something into your build script to call
> | svnversion, but I don't know anything simpler.)
>
> Yes, I have been using configure for that (which can be really any type of
> executable script rather than something from autoconf). One can then either
> update a placeholder in DESCRIPTION.in to substitute the revision number
> and/or create a package-local function reporting svn revision, build time,
> etc.
>
> It may make sense to think about a more general scheme. A common problem is
> of course once again portability and the set of required tools.
If we are talking about R functions for reporting version control
information --- what about the following scheme:
-have some version control system individual functions (one for svn, one
for git and so on)
-have some S4 control class for each of these version control systems
-have an S4 generic VCinfo() which dispatches according to an argument
VCsystem of this control class
This would give some additional flexibility to integrate infra-structure
for new version control systems ---even by other programmers--- without
interfering with the generic.
For the scripting approach --- what about some extra options for
R CMD build
for instance --withSVN or --withTortoiseSVN ?
Thanks again for your comments --- and apologies for my wrong idea
using svn properties.
Best, Peter
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] setIs and method dispatch in S4 classes
Dear all,
I have a question regarding setIs and method dispatch in S4 classes:
Consider the following example:
#
## A02 "contains" A01 by setIs:
setClass("A01", representation(a="numeric",b="numeric"))
setClass("A02", representation(a="numeric",d="numeric"))
setIs("A02","A01",coerce=function(obj){new("A01", [EMAIL PROTECTED], [EMAIL
PROTECTED])},
replace=function(obj,value){new("A01", [EMAIL PROTECTED], [EMAIL
PROTECTED])})
#only a "+" method for A01
setMethod("+", signature=c("A01","A01"), function(e1,e2)[EMAIL PROTECTED]@b})
x1=new("A02", a=1, d=2)
x2=new("A02", a=1, d=3)
x1+x2 ## 5 as expected
## now: B00 mother class to B01 and B02, and again B02 "contains" B01 by
setIs:
setClass("B00", representation(a="numeric"))
setClass("B01", representation(a="numeric",b="numeric"), contains= "B00")
setClass("B02", representation(a="numeric",d="numeric"), contains= "B00")
setIs("B02","B01",coerce=function(obj){new("B01", [EMAIL PROTECTED], [EMAIL
PROTECTED])},
replace=function(obj,value){new("B01", [EMAIL PROTECTED], [EMAIL
PROTECTED])})
# now two "+" methods for B00 and B01
setMethod("+", signature=c("B00","B00"), function(e1,e2)[EMAIL PROTECTED]@a})
setMethod("+", signature=c("B01","B01"), function(e1,e2)[EMAIL PROTECTED]@b})
x1=new("B02", a=1, d=2)
x2=new("B02", a=1, d=3)
x1+x2 ## 2 --- why?
#
(tested on 2.3.0 alpha (2006-04-05 r37653))
I would have guessed that this again would give 5, as B02 is deeper
in the class hierarchy than B00 and the calls to setIs specifies an
unconditional
is-relation.
What is the principle then behind this dispatching mechanism?
Is there a possibility to force usage of the B01 method /without/
explicitely coercing x1,x2 to B01, i.e. interfere in the dispatching
precedence, telling R somehow (by particular arguments for setIs ?)
to always use the is-relation defined by setIs first before mounting
the hierarchy tree?
Thank you for your attention
Peter
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] setIs and method dispatch in S4 classes
Hi Seth ,
thank you for your reply.
Seth Falcon <[EMAIL PROTECTED]> writes:
>Peter Ruckdeschel <[EMAIL PROTECTED]> writes:
>
>
>> ## now: B00 mother class to B01 and B02, and again B02 "contains" B01 by
>> setIs:
>> setClass("B00", representation(a="numeric"))
>> setClass("B01", representation(a="numeric",b="numeric"), contains= "B00")
>> setClass("B02", representation(a="numeric",d="numeric"), contains= "B00")
>> setIs("B02","B01",coerce=function(obj){new("B01", [EMAIL PROTECTED], [EMAIL
>> PROTECTED])},
>>replace=function(obj,value){new("B01", [EMAIL PROTECTED], [EMAIL
>> PROTECTED])})
>>
>> # now two "+" methods for B00 and B01
>> setMethod("+", signature=c("B00","B00"), function(e1,e2)[EMAIL PROTECTED]@a})
>> setMethod("+", signature=c("B01","B01"), function(e1,e2)[EMAIL PROTECTED]@b})
>>
>> x1=new("B02", a=1, d=2)
>> x2=new("B02", a=1, d=3)
>>
>> x1+x2 ## 2 --- why?
>>
>>
>
>My impression from reading over the man page for setIs, is that it
>isn't intended to be used to override the existing inheritance
>hierarchy. It also mentions that the return value is the extension
>info as a list, so that could also be useful in understanding what
>setIs is doing. Here's the output for your example:
>
>Slots:
>
>Name:a d
>Class: numeric numeric
>
>Extends:
>Class "B00", directly
>Class "B01", directly, with explicit coerce
>
>Use the contains arg of setClass to define the superclasses. With the
>contains arg, the order determines the precedence for method lookup.
>But I suspect you know that already.
>
>
Yes, I have been aware of this, thank you.
>> Is there a possibility to force usage of the B01 method /without/
>> explicitely coercing x1,x2 to B01, i.e. interfere in the dispatching
>> precedence, telling R somehow (by particular arguments for setIs ?)
>> to always use the is-relation defined by setIs first before mounting
>> the hierarchy tree?
>>
>>
> Perhaps explaining a bit more about what you are trying to accomplish
> will allow someone to provide a more helpful suggestion than mine :-)
In the "real" context, B00 stands for a class "AbscontDistribution",
which implements absolutely continuous (a.c.) distributions. B01 is
class "Gammad" which implements Gamma distributions, and B02 is
class "Exp" which implements exponential distributions. The method
still is "+", but interpreted as convolution.
For a.c. distributions, the default method is an FFT-based numerical
convolution algorithm, while for Gamma distributions (with the same
scale parameter), analytic, hence much more accurate convolution
formulas are used. For "Exp", I would tell R that it also 'is' a "Gammad"
distribution by a call to setIs and use the "Gammad"-method.
Of course, I could also declare explicitly "+" methods for signatures
c("Exp", "Exp"), c("Exp", "Gammad"), and c("Gammad", "Exp") in
which I would then use as(.) to coerce "Exp" to "Gammad"
(and again the same procedure for further Gamma-methods).
But, this would create an extra (3 or possibly much more) methods
to dispatch, and I doubt whether this really is the preferred
solution.
> If you know the inheritance structure you want before run-time, then
> I'm not seeing why you wouldn't just use the contains arg
I do not want to use the "+" method for "B00" for accuracy reasons
(see above).
The reason why I do not want to implement "B01" ("Gammad")
as mother class of "B02" is that
(a) the slot structure is not identical --- in the real context Gamma
and Exp use different parametrizations ---
+ rate for "Exp" (cf ?rexp) and
+ shape for "Gammad" (cf rgamma)
(b) also class "Weibull" could be used as mother class to "Exp",
and I do not want to decide whether the Weibull or the
Gamma is the (more) "legitimate" mother to Exp ;-)
I know: 'contains' could be a vector of classes ---
c("Gammad", "Weibull") --- but then which would be
the correct slot structure for "Exp" the one of "Gammad"
or the one of "Weibull" ?
My context is a bad example, "Gammad", "Weibull"
do have the same slots, but more generally this /is/ an issue...
--- So my guess was to rather implement two 'is'-relations
( "Exp" 'is' "Gammad" and "Exp" 'is' "Weibull")
declared by 'setIs' , and then on run time let the
dispatching mechanism decide whether to use
a Gamma or a Weibull method.
But maybe there is a better solution ?
Any suggestions are welcome.
> And if you want to force certain behavior at run-time, then I don't
> see what's wrong with an explicit coercion using as(foo, "bar").
If you have two objects E1, E2 of class "Exp" (with the same rate)
you (or the user for whom we provide these classes) rather want to
call "+" by E1 + E2 than
by as(E1, "Gammad") + as(E2,"Gammad")
...
Anyway, thank you for your help
Peter
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] setIs and method dispatch in S4 classes
Hi Seth and John,
Thank you for your helpful responses,
>John Chambers <[EMAIL PROTECTED]> writes:
>>From your description of the application, it sounds like you would be
>>better off just forcing "+" to behave as you want. Using inheritance is
>>a much more powerful mechanism & can introduce results you don't want,
>>as it seems to have in this case.
>>
>>An important point about using inheritance is that the subclass is a
>>asserted to be substitutable for the superclass for ALL purposes. This
>>applies whether using "contains=" or setIs().
I am not sure whether I got the meaning of "substitutable for the
superclass for ALL purposes" :
In the application I sketched, any Exp(rate = lambda) distribution
really /is/ a Gammad(shape = 1, scale = 1/lambda) distribution;
so my understanding is that "Exp" is substitutable for "Gammad"
for ALL purposes.
"Gammad" was not designed to be the motherclass to "Exp" right
from the beginning because the same 'is'-relation also applies to
"Weibull": any Exp(rate = lambda) distribution /is/ a
Weibull(shape = 1, scale = 1/lambda) distribution.
Does "substitutable for the superclass for ALL purposes"
mean 'without ambiguity' (as might enter through Weibull/Gammad)?
>>When the focus is on a particular function, it's usually better to
>>implement methods for that function, maybe along with setAs()
>>methods--not setIs().
You mean I should not leave the coercion decision up to the dispatching
mechanism?
>>It seems likely that such a solution would be cleaner in design, not to
>>mention that it would likely work. (see also suggestion below)
Yes, your indication does work; thank you!
>>Peter Ruckdeschel <[EMAIL PROTECTED]> writes:
>>>Of course, I could also declare explicitly "+" methods for signatures
>>>c("Exp", "Exp"), c("Exp", "Gammad"), and c("Gammad", "Exp") in
>>>which I would then use as(.) to coerce "Exp" to "Gammad"
>>> (and again the same procedure for further Gamma-methods).
>>>
>>>But, this would create an extra (3 or possibly much more) methods
>>>to dispatch, and I doubt whether this really is the preferred
>>>solution.
>>>
>> Why not?
It simply did not seem to me elegant to have three calls to
setMethod() doing more or less the same thing.
I thought that, as elegant as R solutions from the R core are
most times, there should be some mechanism to avoid this
threefold code---and in fact you indicated how to---
thank you!
>> And you can avoid some of the extra methods by defining a
>> virtual class that is the union of the classes for which you
>> want the new methods.
>>
>> Something like (untested code!)
>>
>> setClassUnion("analyticConvolution", c("Exp", "Gammad"))
>> setMethod("+", c("analyticConvolution", "analyticConvolution"),
>> )
Seth Falcon <[EMAIL PROTECTED]> writes:
> Why class union here and not an abstract superclass?
Am I right: the class generated by setClassUnion() does not
enter the inheritance tree / mechanism?
setClassUnion()---at least in my case---solves the problem;
thank you again.
[snip]
Peter
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] yet another problem with S4 dispatch (with setClassUnion)
Dear John and Seth, dear R-devels,
once again the question of method dispatch in S4 -- this time with
setClassUnion(); taking up your advice in
https://stat.ethz.ch/pipermail/r-devel/2006-April/037200.html
https://stat.ethz.ch/pipermail/r-devel/2006-April/037201.html
I have been too quick in stating that
>setClassUnion()---at least in my case---solves the problem;
>
The problem arises if I have a direct superclass "competing"
with the new class generated by setClassUnion();
consider the following code:
## C00 mother class to C01 and C02
setClass("C00", representation(a="numeric"), prototype =c(a=0))
setClass("C01", representation(a="numeric",b="numeric"), contains= "C00")
setClass("C02", representation(a="numeric",d="numeric"), contains= "C00")
#with setClassUnion:
setClassUnion("C01OrC02", c("C01","C02"))
# "+" methods for C00 and C01OrC02
#that this is a function to be dispatched on two arguments is
#not important for this example
setMethod("+", signature=c("C00","C00"), function(e1,e2)[EMAIL PROTECTED]@a})
setMethod("+", signature=c("C01OrC02","C01OrC02"),
function(e1,e2){if(is(e1,"C01")) e10 <- e1
# else: explicit coercion from C02 to C01
else e10 <- new("C01", [EMAIL PROTECTED], [EMAIL
PROTECTED])
if(is(e2,"C01")) e20 <- e2
# else: explicit coercion from C02 to C01
else e20 <- new("C01", [EMAIL PROTECTED], [EMAIL
PROTECTED])
[EMAIL PROTECTED]@b})
x1=new("C02", a=1, d=2)
x2=new("C02", a=1, d=3)
x1+x2 ## 2, i.e. uses C00-method
# but I would like to force usage of C01OrC02-method
Here the two classes C00 and C01OrC02 are direct superclasses to
C02, which exactly reflects my application of distribution classes,
confer https://stat.ethz.ch/pipermail/r-devel/2006-April/037190.html
How does the dispatching mechanism decide between
these two and is there a way to change precedence?
Of course, I could implement a "+" method for C02 directly
in this case, but suppose I have much more methods for
C01 and I want to use /all/ of them for C02, and cannot
organize things so that we have the inheritance chain
C00 -> C01 -> C02. What is the preferred way of doing
this?
Thank you already for your attention,
Peter
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] yet another problem with S4 dispatch (with setClassUnion)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dear John,
sorry for having bothered you with these problems.
> As I think Seth told you before, if you want to control the order
> of inheritance at the same level, you need to use the intended order
> in the contains= argument to setClass.
Apologies, but I did not catch this from Seth's mail; in fact Seth wrote
>> With the contains arg, the order determines the precedence for method
lookup.
sorry for coming up again with the same question.
> In your example (retaining the class union, although it's not required,
the superclass
> could just be an ordinary virtual class),
>
> setClassUnion("C01OrC02")
> ## C00 mother class to C01 and C02
> setClass("C00", representation(a="numeric"), prototype =c(a=0))
> setClass("C01", representation(a="numeric",b="numeric"),
> contains= c("C01OrC02", "C00"))
> setClass("C02", representation(a="numeric",d="numeric"),
> contains= c("C01OrC02", "C00"))
>
> seems to give what you want
Yes, it does. Thank you very much. Problem solved!
... and I have learned something
Besides the importance of order in the 'contains'-arg,
beforehand, I had also somehow misunderstood the
purpose of setClassUnion():
I had thought setClassUnion() was to circumvene the
modification of classes (not "owned" by me);
thus it was not obvious to me to write a class defined
by setClassUnion() into the 'contains'-argument.
BTW:
Is there a way to solve my problem without
modifying the 'contains'-arguments ---
e.g. if I do not "own" classes C01, C00, C02?
(This is not the case for my application, but
might be of general interest) .
> To answer one of your other questions, the point about inheritance
asserting
> substitutability is that you now need to be sure that
> EVERY method for C01OrC02 is preferred to a method for C00 for
> the new subclasses.
Ok. This would be the case in my application.
> As a general design point, having these competing superclasses is likely to
> confuse the user, if not the implementer.
> If you could, it would make a clearer picture to have, e.g., C01orC02 be a
> subclass of C00.
> Then the inheritance is obvious--C01or... is a parent, while C00 is a
grandparent.
> The special contains= then doesn't need to be repeated for every
subclass Cx.
Good point; I fixed this in our package.
Probably it is also a good idea then not to export this artificial
(but no longer VIRTUAL) intermediate class in the NAMESPACE file.
Thank you once again, you helped us a lot.
Peter
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (MingW32)
Comment: GnuPT 2.6.2.1 by EQUIPMENTE.DE
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEPbFex+/gN8KI3u0RAgE8AJ9/M6Q7F8ldGDLVjRCCXW6PdidJRwCfW2zd
rFlFbzuL4jbrav//lmrO2rE=
=iIbA
-END PGP SIGNATURE-
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] contribution offer: df() for non-centrality != 0
Hi R-devels, I noticed that for the scheduled R 2.3.0, there is still no function df() for non-centrality != 0. Easter is quickly approaching, so as my little gift, I would like to offer you some code to fill this gap: After excluding some "unusual" cases, it amounts to differentiating the corresponding function pnf() --- which in turn leads to the function dnbeta() already available in the stats package for some time. You may find this code in http://www.uni-bayreuth.de/departments/math/org/mathe7/R-devel/dnf.tar.gz This archive includes the C-Filednf.c as well as some adapted versions Fdist_new.Rd and distn_new.R; in the latter two files I indicated all modifications w.r.t. Fdist.Rdanddistn.R by a corresponding %%-tag. You may modify these files as you like in order to conform your design principles --- and hopefully we will soon have df() for ncp, too... Best, Peter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Wishlist: 'quietly' argument for .onAttach() / .First.lib()
Hi R-devels, in "Writing R extensions" as well as in the help to .onAttach(), you mention that one could use this function to issue a start-up message/banner for the package. My little wish for Easter: a 'quietly'-type argument for .onAttach() / .First.lib() which is passed through by functions require() and library() respectively, and by means of which one could optionally suppress this start-up message/banner . Is this hard to do? Thank you already Peter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] contribution offer: df() for non-centrality != 0
Hi Martin, Martin Maechler wrote: > but note that this is clearly too late for 2.3.0 : > If you look at the release schedule at >http://developer.R-project.org/ > you see that April 10 was "Feature Freeze". > Yes, don't worry, I have been aware of this; I did not mean to submit the code for 2.3.0, but just used this version as a reference to be "up-to-date". > If it looks good -- and it does after a quick glimpse -- > it should be possible to be integrated for 2.3.1 though This would be fine ! Thank you Peter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: 'quietly' argument for .onAttach() / .First.lib()
Andy Liaw wrote: > From: Prof Brian Ripley > >/ > />/ On Thu, 13 Apr 2006, Peter Ruckdeschel wrote: > />/ > />/ > Hi R-devels, > />/ > > />/ > in "Writing R extensions" as well as in the help > />/ > to .onAttach(), you mention that one could > />/ > use this function to issue a start-up message/banner > />/ > for the package. > />/ > > />/ > My little wish for Easter: > />/ > > />/ > a 'quietly'-type argument for .onAttach() / .First.lib() which is > />/ > passed through by functions > />/ > require() and library() respectively, > />/ > and by means of which one could optionally > />/ > suppress this start-up message/banner . > />/ > > />/ > Is this hard to do? > />/ > />/ I believe so (and think we have been here before). / sorry, but I did not find anything on it --- probably I searched for the wrong keywords. > /> The //documented call //sequence is > />/ > />/ .onLoad(libname, pkgname) > />/ .onAttach(libname, pkgname) > />/ > />/ the same as .First.lib. There is no way to add an argument > />/ here, as many //existing packages do not support it. > / Couldn't a reasonable default value (probably FALSE ) catch this? > /> Beyond that, how would / /you pass the > />/ argument in? Namespaces and packages are often > />/ loaded/attached implicitly //as a result of loading other packages. > / oK this is an issue --- no idea for this. > >/ I did think you could make use of an option to decide whether > />/ to the print //the message or not, > / This is probably the cleanest solution. > /> but I have always assumed that those who > />/ did want a //banner probably did not want it suppressed. > / > That certainly is the case with randomForest, speaking for myself > here. The banner I put in contains the version number of the > package and a reminder to see what's been changed/fixed. I have > not seen a compelling reason why suppressing such information is > necessary (as opposed to "desirable"). I believe reporting > version number upon startup is a Good Thing, as all too often > people ask questions or report problems about packages without > mentioning the version of the packages they used. I see this as > a way of reminding the users. > I completely agree as to package version information and pointers to NEWS / more information on the package. My wish is motivated by something else --- call it /"scalable start-up message"/ In a discussion with Martin Maechler, he proposed to alert/warn the user in some prominent place about the interpretation of arithmetics operating on distributions in our package "distr". I have been thinking about this "prominent place" for some time and found that an .onAttach() message might be the right place. A user, however, who is already used to this interpretation, will soon find this (extended) start-up message annoying and will want to suppress it. I could do this with a "hand-made" option but thought this might be of more general interest. Thank you for your attention, Peter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: 'quietly' argument for .onAttach() / .First.lib()
Summing up the discussions in this thread, I have built a package 'startupmsg' available (in a first version) for the moment at http://www.uni-bayreuth.de/departments/math/org/mathe7/R-devel/startupmsg_0.1.tar.gz (see documentation within) In particular, I took up suggestions from Seth Falcon's mail as to the condition system in R as well as a suggestion by Brian Ripley in some earlier reply in this thread to use options() to control start-up messages. Any comments/suggestions are welcome. If you find 'startupmsg' useful, you might decide to integrate (parts of) it to the 'utils' package (or some yet to be built package "packageutils" ) later on --- for the moment, I would simply submit it to CRAN in the next days. Best, Peter Seth Falcon <[EMAIL PROTECTED]> writes: >Paul Roebuck writes: >>Prof Brian Ripley <[EMAIL PROTECTED]> writes: >>> Similarly for Bill Dunlap's proposal: suppressMessages would squelch all >>> messages from the call, not just the one from your package's startup code. >>> Now, at present there may not be any, but that could well change as >>> message() gets more widely used. >> >> I found Bill's suggestion a bit scary myself; suppressing messages >> when dealing with loading packages seems a bit like disabling the >> compiler's warning messages - a bad idea. But it was a novel >> approach. > >What's the use case where this would be scary? suppressMessages >doesn't supress warnings or errors, just messages. If the info to be >communicated to the user is important enough that it would be "scary" >to not see it, then shouldn't it sent as a a warning or an error? > >> Given what you said above, do you favor the suggestion to use >> message() instead of cat() for the purpose of .onAttach() startup >> messages? I've seen message() before in the manpages but never saw >> any documentation on how or when it might be considered appropriate >> to use. [...] >> On Thu, 13 Apr 2006, Prof Brian Ripley wrote: >>> I did think you could make use of an option to decide whether to >>> the print the message or not, [snip] [...] >> Why would one want to represent a simple non-error message as a >> condition in the first place? > >Because it allows another developer to have control over those >messages. That's the beauty of the condition system in R. > >Right now, developers can choose to allow or suppress messages sent >via message(). With a small change, developers could have a lot more >control. The message code could define a restart that would allow a >developer-specified function to handle the message. This could be >useful, for example, to log all messages to a file. [snip] >For anyone still with me: > >* If there was much concern about squelching "important" messages by > accident, then one could define a new subclass of simpleMessage, say > startupMessage or blatherMessage, and then suppress just those. > >* This use case of handling messages could also be addressed with a > logging system like Python's logging module. Basically, it would > allow users to install log handlers, set priorities, etc. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Wishlist for promptPackage / index
Hi R-devels,
would it be possible to enhance either promptPackage()
or the default indexing mechanism for packages
so that -- if it exists -- (the contents of) file
-package.Rd is sorted first in
* the .dvi / .pdf documentation file
* the .chm documentation file
* the package 00index.html documentation file
?
So far I found the following "hand-made" solution for me:
(1) rename the -package.Rd file to, say,
0-package.Rd
(2) change the \name -field to
\name{(-package)}
(note the parentheses in order to sort this file before
any operators like "+", "-" etc..)
This is probably not quite the way it should be, but
at least it works under my standard-settings.
A more refined strategy would probably also take
into account something like a Collate field in
the DESCRIPTION field.
What is the opinion of R-Core to this question?
Thank you already
Peter
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist for promptPackage / index
On 4/19/2006 1:49 AM, Duncan Murdoch wrote: >On 4/18/2006 7:02 PM, Peter Ruckdeschel wrote: >> would it be possible to enhance either promptPackage() >> or the default indexing mechanism for packages >> so that -- if it exists -- (the contents of) file >> -package.Rd is sorted first in >> >> * the .dvi / .pdf documentation file >> * the .chm documentation file >> * the package 00index.html documentation file >They already sort first in the last of those. I don't think it is >really possible in the index of a .chm file; they are alphabetical >sorting only, as far as I know. (The package topic does sort first in >the main contents page, which is the same as the 00index.html file.) Yes, you are right: the first two cases are already settled in a completely satisfying way [even with "+","-"-type methods!]. Sorry to have stirred you up --- I should have tried first. >It probably makes sense in a .dvi/.pdf, I tried out with an example now: at least for this case my request still applies ... >but as far as I recall, at the time I thought those were produced >by the shell script for Rd2dvi, and it just seemed like too much trouble >to change the collation order there. >In fact, now I look closer I see they are produced by the Perl >script tools/pkg2tex.pl so it shouldn't be hard to port the changes I >made to Rdlists.pm over. I'll take a look. would be very nice; thank you very much Peter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: 'quietly' argument for .onAttach() / .First.lib()
Dear Seth, thank you very much for your helpful comments: >I had a quick look and for what it's worth, a few comments... > >* Seems a bit more code than I would expect. Arguable, yes... > I think you have some use cases that I don't have ;-). hopefully I'm not the only one to have these cases :-) > In terms of general use, I would suggest making a stab at a > simplified version. I have tried to do something in that direction: * files startUpMessage.R / StartupUtilities.Rd now gather the code addressing a more general audience; (?"startupmsg") * files illustration.R / myStartupUtilities.Rd [ with mySMHandler, mystartupMessage, buildStartupMessage ] (?"mySMHandler") may be thought of an illustration of the concept (and hence should not enter general packages, I suppose) the revised code is available again under http://www.uni-bayreuth.de/departments/math/org/mathe7/R-devel/startupmsg_0.2.tar.gz > For example, what's the difference between startupMessage and > startupVersionMessage; are both needed? I guessed so: the idea is to have more than one type of StartupMessage, and suppressing should be done according to the type; I have rethought this now: instead of two (or more) subclasses of StartupMessage, I now have endowed class StartupMessage with an extra slot type, which currently is supposed to take one of the tree values + "version": version and title information from the DESCRIPTION file + "notabene": "nota bene"s on the package to be given at this prominent place + "information": (starting) pointers for more information on the package: -howto call the package help file, -howto inspect the NEWS file, -additional manuals/vignettes -URLs (but the code already supports arbitrarily many type values) > And linestarter? I agree: this should better be dealt with in a more general/flexible way by allowing + the developper using 'startupMessages' to use his own SMHandler (for /S/tartup/M/essage/Handler/) as illustrated in 'mystartupMessages' + the user of a package with 'startupMessages' to specify a suitable custom restart (see examples in ?"startupmsg") --- is achieved using your code example >* Consider adding a customizable restart. As it stands, startupmsg > doesn't give a user more control than message(). Now it does; I admit, I should have integrated your proposed elegant code right from the beginning. > That is, you can either muffle the messages or not. If I want to write > them to a file or prefix them with funny characters, doing so by grabbing > hold of the message before it is emitted via the restart seems like a > nice approach (although one could argue for a more general system > logging system that probably would not need the fancy condition > system use). Thank you again Peter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] optimize() and extrema at the interval bounds
Dear r-devels, by construction, optimize() only evaluates the objective function *inside* the bounds of argument 'interval'. It does not seem to be an 'extremely' rare case that extrema are attained *at* the bounds of argument 'interval' :-) It is fairly easy to write a wrapper to optimize() enforcing an evaluation of the objective function at these bounds, too, but wouldn't it be a good idea to a add an extra argument 'evalbounds' of optimize() defaulting to FALSE (behavior of optimize() as it is now), but which if TRUE does evaluate the objective at the bounds? I do not know how costly two extra evaluations are in general as to computation time at evaluation of optimize(), nor how many conflicts of unmatched arguments an extra argument to optimize() would cause; so consider this just as a proposal. Thank you for your attention, Peter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] confused by inheritance...
Hi r-devels,
I am stuck in some S4 inheritance problem:
setClass("A",representation(a="numeric"))
setClass("A1",representation(b="numeric"),contains="A")
setClass("A2",representation(c="numeric"),contains="A1")
if(!isGeneric("foo")){
setGeneric("foo", function(x,y,z, ...) standardGeneric("foo"))
}
setMethod("foo",signature(x = "A", y = "missing", z = "missing"),
function(x)[EMAIL PROTECTED] )
setMethod("foo",signature(x = "A1", y = "missing", z = "missing"),
function(x)[EMAIL PROTECTED] )
setMethod("foo",signature(x = "A2", y = "missing", z = "missing"),
function(x)[EMAIL PROTECTED] )
setMethod("foo",signature(x = "A1", y = "numeric", z = "missing"),
function(x,y)c([EMAIL PROTECTED],y) )
x2 <- new("A2", a=1, b=2, c=3)
foo(x2) ## gives 3 as it should
foo(x2,y=2) ## casts to "A1" and gives (2,2) as it should
foo(x2) ## now gives 2 as if x2 were permanently cast to "A1"
## However:
x2 ## of class "A2" as it should
getMethod("foo",signature(x = "A2", y = "missing", z = "missing"))
## function(x)[EMAIL PROTECTED]
### What has happened in the dispatching mechanism between
## in the line foo(x2,y=2) ?
I would appreciate any help.
Thanks for listening
Peter
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] confused by inheritance...
> This may be related to the problems with "greedy" search for inherited
> methods discussed previously on this list (or may not, it's a bit
> different).
Thank you very much for your explanation --- at least this is not a silly
fault from our side!
> In any case, the likely fix will be a substantial cleaning up of generic
> functions hoped for in the next release.
>
> Meanwhile, "Keep it simple" is the best advice (and a good idea
> anyway). If you remove the irrelevant z= part of the signatures, the
> anomalous result goes away.
Well, as you might have guessed, the z= part is only irrelevant in
the code sniplet I have posted to r-devel as an example...
In our application, 'foo' is an expectation function E() which may be called
as follows:
E(x) ## returns the expectation of a r.v. X distributed
## according to distribution x
E(x,fun) ## returns the expectation of a r.v. fun(X) where X is distributed
## according to distribution x
E(x,cond) ## returns the expectation of a r.v. X given condition 'cond' is
## in force and where X is distributed according to distribution x
E(x,fun,cond) ## returns the expectation of a r.v. fun(X) given condition
'cond' is
## in force and where X is distributed according to distribution x
Would you have any suggestion how to organize this in a simpler way than
with signatures
"Distribution", "missing", "missing"
"Distribution", "function", "missing"
"Distribution", "missing", "numeric"
"Distribution", "function", "numeric"
respectively?
> By the way, the getMethod() in your example tells us nothing,
> since it does not use inheritance. See its documentation.
Yes, but since 'target' and 'defined' are identical---
Signatures:
xy z
target "A2" "missing" "missing"
defined "A2" "missing" "missing"
---I would have guessed that the dispatching mechanism would
use this method.
> If you use selectMethod() you see the same result as the method dispatch.
...but this would have made me think that somehow
(perhaps by an unintended call to removeMethod())
during the dispatching mechanism, the registration of my
("A2","missing","missing")-method would have been deleted.
This is not the case, and could be excluded after
having a look at getMethod() --- so at least for me,
getMethod() did provide some information ...
This idea of a registration being deleted may sound silly to you,
but it was my first guess after the following code (in the setup
of my posted example):
foo(x2) ## gives 3 as it should
foo(x2,y=2) ## casts to "A1" and gives (2,2) as it should
foo(x2) ## now gives 2 as if x2 were permanently cast to "A1"
setMethod("foo",signature(x = "A2", y = "missing", z = "missing"),
function(x)[EMAIL PROTECTED] )
foo(x2) ## again gives 3 as it should
Thanks again
Peter
---
> Peter Ruckdeschel wrote:
>
>>Hi r-devels,
>>
>>I am stuck in some S4 inheritance problem:
>>
>>setClass("A",representation(a="numeric"))
>>setClass("A1",representation(b="numeric"),contains="A")
>>setClass("A2",representation(c="numeric"),contains="A1")
>>
>>if(!isGeneric("foo")){
>>setGeneric("foo", function(x,y,z, ...) standardGeneric("foo"))
>>}
>>
>>setMethod("foo",signature(x = "A", y = "missing", z = "missing"),
>>function(x)[EMAIL PROTECTED] )
>>setMethod("foo",signature(x = "A1", y = "missing", z = "missing"),
>>function(x)[EMAIL PROTECTED] )
>>setMethod("foo",signature(x = "A2", y = "missing", z = "missing"),
>>function(x)[EMAIL PROTECTED] )
>>setMethod("foo",signature(x = "A1", y = "numeric", z = "missing"),
>>function(x,y)c([EMAIL PROTECTED],y) )
>>
>>
>>x2 <- new("A2", a=1, b=2, c=3)
>>
>>foo(x2) ## gives 3 as it should
>>foo(x2,y=2) ## casts to "A1" and gives (2,2) as it should
>>foo(x2) ## now gives 2 as if x2 were permanently cast to "A1"
>>## However:
>>x2 ## of class "A2" as it should
>>getMethod("foo",signature(x = "A2", y = "missing", z = "missing"))
>>## function(x)[EMAIL PROTECTED]
>>
>>### What has happened in the dispatching mechanism between
>>## in the line foo(x2,y=2) ?
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] New feature for download.packages(): optional resolution of package dependencies
Hi r-devels, may I ask for an enhancement for download.packages() to optionally resolve package dependencies similarly to the respective functionality in install.packages() ? This would be a major help in compiling a large number of packages (e.g. by means of download.view() from pkg ctv) for later offline installations. Last November, I addressed Duncan Murdoch offline in this issue, and Duncan then seconded me---so the idea might not be this silly. He was pointing me to available.packages() which already provides a dependency list, which though would have to be parsed. AFAICS in the svn, as of rev54842, he has not found the time for looking deeper into this so far. Surely, like most of you, he has had more urgent issues to work on, but maybe someone (else) of you has an idea for an easy but still sustainable solution. Any suggestions appreciated. Cheers, Peter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] directives to explicitely exclude objects from import into namespaces
Hi, recently R CMD check --as-cran has noticed some more issues with package namespace imports with the recommended remedy to use importFrom() and friends. In my case, there was only a conflict restricted to some few imports, while I would prefer to still import all the non-conflicting objects, methods, and classes of the respective package namespace. So would it be possible to have some new directives along the lines import() ## importing the whole namespace of in a first step notimportFrom(, , ,) ## exclude , , ... again from the previous namespace import ## and, similarly, notimportMethodsFrom(, , ,) notimportClassesFrom(, , ,) in the NAMESPACE file? Otherwise the list of object, methods, classes to be explicitely imported (in my case) got very long (and hence hard to maintain) -- much longer than the list of items to be excluded from an import. Or have I overseen some obvious, easier way to achieve this? Best regards, Peter -- Dr. habil. Peter Ruckdeschel, Abteilung Finanzmathematik, F3.17 Fraunhofer ITWM, Fraunhofer Platz 1, 67663 Kaiserslautern Telefon: +49 631/31600-4699 Fax: +49 631/31600-5699 E-Mail : peter.ruckdesc...@itwm.fraunhofer.de http://www.itwm.fraunhofer.de/abteilungen/finanzmathematik/mitarbeiterinnen/mitarbeiter/dr-peter-ruckdeschel.html __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: Matrix package: Matrix products (%*%, crossprod, tcrossprod) involving "nsparseMatrix" aka sparse pattern matrices
ended on the
> current behavior ("T + T |--> T"). ... although that is currently
> only used for *sparse* pattern matrices, not for dense ones.
>
> Further, it may still seem surprising that matrix multiplication does
> not behave numerically for a pair of such matrices, and by the
> principle of "least surprise" we should provide the boolean arithmetic
> matrix products in another way than by the standard %*%,
> crossprod() and tcrossprod() functions.
> So one possibility could be to change the standard functions to behave
> numerically,
> and e.g., use %&% (replace the numeric "*" by a logical "&") and
> crossprod(A,B, boolean=TRUE), tcrossprod(A,B, boolean=TRUE)
> for the three boolean arithmetic version of matrix multiplications.
>
> What do you think about this? I'm particularly interested to hear
> from authors and users of packages such as 'arules' which IIRC
> explicitly work with sparse pattern matrices.
>
> Thank you for your thoughts and creative ideas,
> Martin Maechler, ETH Zurich
--
Dr. habil. Peter Ruckdeschel, Abteilung Finanzmathematik, F3.17
Fraunhofer ITWM, Fraunhofer Platz 1, 67663 Kaiserslautern
Telefon: +49 631/31600-4699 Fax: +49 631/31600-5699
E-Mail : peter.ruckdesc...@itwm.fraunhofer.de
http://www.itwm.fraunhofer.de/abteilungen/finanzmathematik/mitarbeiterinnen/mitarbeiter/dr-peter-ruckdeschel.html
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] large sysdata.rda file --- strategies?
Hi, to speed up computations in our RobASt family of packages, we use interpolation on a grid of precomputed values which we save together with the interpolating functions (results of splinefun essentially) in sysdata.rda in the R folder of our pkg. After adding grids for some more models, this file has grown considerably, even after application of tools::resaveRdaFiles. At the moment we are at about 2MB (compressed) and 8.8 MB (uncompressed) and hence R CMD check --as-cran issues a NOTE. We want to comply with cran policies, http://cran.r-project.org/web/packages/policies.html in particular with > Where a large amount of data is required (even after compression), > consideration should be given to a separate data-only package which > can be updated only rarely (since older versions of packages are > archived in perpetuity). Q1: Are packages only consisting of a sysdata.rda file thinkable for submission on CRAN ? Are such pkgs the way to go for w.r.t. to the cited policy? If this is the case, how would one document such a package, in particular if we do not export any objects in the NAMESPACE file? In addition, with a sysdata.rda-only pkg, R CMD check issues a warning "Found directory 'R' with no source files" Of course a workaround is adding a comment-only file comment.R to the R folder. Q2: Is there a lazy load / lazy data mechanism available for sysdata.rda ? If so how would one enforce it? Any suggestions appreciated, Best, Peter -- Dr. habil. Peter Ruckdeschel, Abteilung Finanzmathematik, F3.17 Fraunhofer ITWM, Fraunhofer Platz 1, 67663 Kaiserslautern Telefon: +49 631/31600-4699 Fax: +49 631/31600-5699 E-Mail : peter.ruckdesc...@itwm.fraunhofer.de http://www.itwm.fraunhofer.de/abteilungen/finanzmathematik/mitarbeiterinnen/mitarbeiter/dr-peter-ruckdeschel.html __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] large sysdata.rda file --- strategies?
Dear Uwe, > > On 07.02.2013 15:41, Dr. Peter Ruckdeschel wrote: >> Hi, >> >> to speed up computations in our RobASt family of packages, we use >> interpolation on a grid of precomputed values which we save together >> with the interpolating functions (results of splinefun essentially) >> in sysdata.rda in the R folder of our pkg. >> >> After adding grids for some more models, this file has grown >> considerably, even after application of tools::resaveRdaFiles. >> At the moment we are at about 2MB (compressed) and 8.8 MB >> (uncompressed) and hence R CMD check --as-cran issues a NOTE. >> >> We want to comply with cran policies, >>http://cran.r-project.org/web/packages/policies.html >> in particular with >>> Where a large amount of data is required (even after compression), >>> consideration should be given to a separate data-only package which >>> can be updated only rarely (since older versions of packages are >>> archived in perpetuity). >> >> Q1: Are packages only consisting of a sysdata.rda file thinkable for >> submission on CRAN ? Are such pkgs the way to go for w.r.t. to the >> cited policy? > > Yes, given this package needs less updates than the main package, one > should consider such a data only package that needs rare updates and > does not flood the space with archived versions. > Fine. We are going to do this then (albeit possibly not yet with the next release). BTW: Of course the code to generate the grids would be accessible in the main package to be compliant with open source ideas. >> If this is the case, how would one document such a package, in >> particular >> if we do not export any objects in the NAMESPACE file? >> In addition, with a sysdata.rda-only pkg, R CMD check issues a warning >> "Found directory 'R' with no source files" Of course a workaround is >> adding a comment-only file comment.R to the R folder. > > If the checks will be changed not to warn in such a case, this can > only happen for R >= 3.0.0, so your workaround to tell the checks you > really intended such a package with R folder not containing any code > sounds plausible for now. > > >> Q2: Is there a lazy load / lazy data mechanism available for >> sysdata.rda ? If so how would one enforce it? > > It is lazy loaded. From WRE: > "if the ‘R’ subdirectory contains a file ‘sysdata.rda’ [...] this will > be lazy-loaded into the namespace/package environment" > Ah must have missed this. Many thanks for your comments. Best, Peter > > Best, > Uwe > > > >> Any suggestions appreciated, >> >> Best, Peter >> -- Dr. habil. Peter Ruckdeschel, Abteilung Finanzmathematik, F3.17 Fraunhofer ITWM, Fraunhofer Platz 1, 67663 Kaiserslautern Telefon: +49 631/31600-4699 Fax: +49 631/31600-5699 E-Mail : peter.ruckdesc...@itwm.fraunhofer.de http://www.itwm.fraunhofer.de/abteilungen/finanzmathematik/mitarbeiterinnen/mitarbeiter/dr-peter-ruckdeschel.html __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] cryptic message of R CMD check
Hi R-devels,
recently, we have seen a new warning by "R CMD check"
appearing for the devel-version of our package distrEx available on
r-forge, e.g. as
*|install.packages("/distrEx/",repos="http://r-forge.r-project.org";)|*
Here is the warning:
%-
[...snip ...]
* checking for unstated dependencies in R code ... WARNING
.get_S4_methods_list(): *did* reduce list, dropping
See the information on DESCRIPTION files in the chapter 'Creating R
packages' of the 'Writing R Extensions' manual.
[...snip ...]
%---
We get the same warning under Linux and Windows (if this helps).
Unfortunately, we cannot give you very detailed information about
our R running --- it is R-2.8.0dev but somehow R.Version() failed
to give svn-details ---
>R.Version()$version.string
[1] "R version 2.8.0 Under development (unstable) (2006-00-00 r0)"
but we built this R based on the then devel-version on July 29.
Could you give us a clue in this
Thank you already
Peter
--
Dr. Peter Ruckdeschel, Abteilung Finanzmathematik, F3.17
Fraunhofer ITWM, Fraunhofer Platz 1, 67663 Kaiserslautern
Telefon: +49 631/31600-4699
Fax: +49 631/31600-5699
E-Mail : [EMAIL PROTECTED]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD check warning "no visible binding for global variable" and hasArg()
Hi R-devels, latetely I reported having problems with understanding warnings issued by a devel version of R CMD check, which Brian Ripley in his reply https://stat.ethz.ch/pipermail/r-devel/2008-August/050493.html correctly attributed to my using an outdated version (July 29) --- you really have to be quick with updating these days! Having switched to a more recent version, R CMD check indeed no longer issued these warnings and instead helped me to detect some missing bindings for global variables --- thank you Kurt for this! In some occasions the warning "no visible binding for global variable XY" seems overly fuzzy to me, however: R CMD check also issues this warning, if, by means of function hasArg() from package 'methods', I want to test the presence of a certain argument 'x' in a function call when 'x' is not a formal argument but "..." is. Clearly, then 'x' in general will have no binding. I am not sure whether this is of general interest, but I think it should not be too difficult to check whether this "missing binding" occurs within a call to hasArg() [and then not to issue the warning]. Thanks for listening, best regards, Peter -- Dr. Peter Ruckdeschel, Abteilung Finanzmathematik, F3.17 Fraunhofer ITWM, Fraunhofer Platz 1, 67663 Kaiserslautern Telefon: +49 631/31600-4699 Fax: +49 631/31600-5699 E-Mail : [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Warning: missing text for item ... in \describe?
Hi Brian and Berwin,
thanks for finding the reason for all this trouble.
> 1) Having run tests on CRAN and BioC overnight, the results are
> quite depressing. There are 112 packages on CRAN and a score
> on BioC with incorrectly rendered help pages because of spaces
> after \item{foo}.
> In two cases (fields and MANOR) the text skipped is invalid, so it
> is not simply a case of ignoring the whitespace.
As you already have found out the "depressing" number of 112, could you
please alert the maintainers of these packages --- I would not be surprised
if I were among them ...
> 2) On the original subject line, I found a different reason. E.g. I
> get the
> message on distrMod, which has (sqrt-methods.Rd, also
> solve-methods.Rd)
>
> \section{Methods}{\describe{
> \item{sqrt}{\code{signature(x = "PosSemDefSymmMatrix")}: produces a
> symmetric, p.s.d. matrix \eqn{y} such that \eqn{x = y^2}}
> }}
You indicate that the problem could easily be solved by inserting
punctuation.
I would have no problems with this as a binding restriction, and
probably the same
goes for other maintainers.
So could you perhaps add a corresponding recommendation
to the "Writing R extensions" manual?
I have just uploaded a quick patch for the sqrt() and solve() ".Rd"
files of distrMod
inserting a "." at the closing brace of \eqn{} in both cases.
Should be on CRAN soon...
Best,
Peter
--
Dr. Peter Ruckdeschel, Abteilung Finanzmathematik, F3.17
Fraunhofer ITWM, Fraunhofer Platz 1, 67663 Kaiserslautern
Telefon: +49 631/31600-4699
Fax: +49 631/31600-5699
E-Mail : [EMAIL PROTECTED]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] UTF-8 encoding issue with R CMD check with install-args="--latex"
Hi,
this is to report some minor UTF-8 encoding issue with R CMD check with option
--install-args="--latex"
(and possibly more install-args).
More specifically, in my Windows system (see the cloud link below for details
on my system), but also
on the Linux machine of my collaborator Matthias Kohl (CC), the following
command throws errors:
R CMD check --install-args="--latex" _.tar.gz
I.e., at this command, when checking the pdf version of the manual, pdflatex
throws an error of type
===
* checking PDF version of manual ... WARNING
LaTeX errors when creating PDF version.
This typically indicates Rd problems.
LaTeX errors found:
! Undefined control sequence.
l.37 \inputencoding
{utf8}
The control sequence at the end of the top line
of your error message was never \def'ed. If you have
===
This is certainly not an urgent issue.
Option --install-args="--latex" can be removed without harm for me, it somehow
survived in my set
of (Windows) batch files I use to build, check, and install my R packages on
Windows, which,
admittedly, makes me a rare species in the R ecosystem.
Still, it would be nice to understand why this happens, so any hints would be
warmly welcome.
Some more details on my testing configuration and my first insights into this
error can be found
here: https://cloudstorage.uni-oldenburg.de/s/kStWp5PNiwJEqfz
Best, Peter Ruckdeschel
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] UTF-8 encoding issue with R CMD check with install-args="--latex"
Thanks Ivan and Kurt, for nailing this down, best regards, Peter
Am 17.01.2025 um 09:01 schrieb Kurt Hornik:
Ivan Krylov via R-devel writes:
Thanks. Will try to fix ...
Best
-k
В Thu, 16 Jan 2025 18:09:25 +0100
Peter Ruckdeschel via R-devel пишет:
this is to report some minor UTF-8 encoding issue with R CMD check
with option --install-args="--latex" (and possibly more install-args).
Thank you for a very detailed report!
This doesn't happen on R-4.2.2 or 4.3.1, but it does happen on R-devel.
Comparing the calls from R CMD check to R CMD Rd2pdf, I see no
difference in the environment variables or any significant difference
in the command lines. The command being run ends up being equivalent to
R CMD Rd2pdf .Rcheck/
...and the source of the difference is the presence (or absence) of the
.Rcheck//latex directory. If I temporarily move it
away during an R CMD check --install-args=--latex run, the command
succeeds.
Indeed, tools:::.pkg2tex says
## First check for a latex dir (from R CMD INSTALL --latex).
## Second guess is this is a >= 2.10.0 package with stored .rds
## files.
## If it does not exist, guess this is a source package.
latexdir <- file.path(pkgdir, "latex")
The individual *.tex files in the latex/ subdirectory of the installed
package all do start with an "\inputencoding{utf8}" line.
When the latex/ subdirectory doesn't exist, the !dir.exists(latexdir)
branch is taken, where Rd2latex(...) is called with writeEncoding =
FALSE, thus avoiding the problem.
--
Best regards,
Ivan
__
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
