[Rd] Writing R-extensions
G'day all,
After reading through "Writing R Extensions", Version 2.1.1
(2005-06-20), I thought the the following points might need
clarifications or corrections. (I checked that these comments also
hold for "Writing R Extensions", Version 2.2.0.)
1) When I ran "package.skeleton" recently, I noticed that the
DESCRIPTION file and an entry `type'. This surprised me a bit
since I did not remember reading about it in the description of the
DESCRIPTION file. I realised that package types are described in
the last section of Chapter 1 of "Writing R Extensions", but would
it be possible to add at the end of Section 1.1.1 (The
`DESCRIPTION' file) something like:
The optional @samp{Type} field specifies the type of the package:
@pxref{Package types}.
2) The description of the `inst' subdirectory states:
Subdirectories of @file{inst} should not interfere with those
used by R (currently, @file{R}, @file{data}, @file{demo},
@file{exec}, @file{libs}, @file{man}, @file{help},
@file{html}, @file{latex}, @file{R-ex}, and @file{Meta}).
And I wonder whether this list is incomplete. Should not, with the
introduction of localisation, at least @file{po} be listed too?
3) The final sentence in the section on `Registering S3 methods' is:
Any methods for a generic defined in a package that does not
use a name space should be exported, and the package defining
and exporting the method should be attached to the search path
if the methods are to be found.
I wonder whether this should actually be:
Any methods for a generic defined in a package that does not
use a name space should be exported, and the package defining
and exporting the generic should be attached to the search path
^^^
if the methods are to be found.
Or is the implication of that sentence that if I have a package
with a name space which defines a method for a generic defined in
another package that does not use a name space, then this method
is only found if my package is attached to the search path and
mere loading of the namespace is not sufficient?
4) This could be nit-picking (or just the fact that English is not my
native language), but the section on `Load hooks' states
Packages with name spaces do not use the @code{.First.lib}
function. Since loading and attaching are distinct operations
when a name space is used, separate hooks are provided for each.
These hook functions are called @code{.onLoad} and
@code{.onAttach}.
I interpreted this as "o.k., loading and attaching are distinct
operations, if I load a package .onLoad (and only .onLoad) is run,
if I attach a package then .onAttach (and only .onAttach) is run".
But the manual continues a bit further down with
Packages are not likely to need @code{.onAttach} (except perhaps
for a start-up banner); code to set options and load shared
objects should be placed in a @code{.onLoad} function, or use
made of the @code{useDynLib} directive described next.
This seems to imply to me that the .onLoad is executed also if I
attach a package. So should may understanding rather be "attaching
a package implies loading it and, hence, if I attach a package,
then .onLoad and .onAttach are both run (with .onLoad presumably
run first?)"?
Cheers,
Berwin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] robustness of install.packages/update.packages (was Re: bug in L-BFGS-B? (PR#8099))
G'day Brian, I am splitting my reply to your e-mail into two since there are two separate spinoffs. > "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]> writes: BDR> Check your versions of MASS. The Windows one appears to be BDR> an outdated version, and does different things. Thanks, yes, this is the problem. On my linux box, I compile things from source and had the latest version of MASS (7.2-19) installed under R 2.1.1 and R 2.2.0. Since I hardly ever work under Windows, I rely for my Windows box on the precompiled versions provided from CRAN and do not compile R or packages from source. (Though I have it set up so that I can compile my own packages.) Actually, I only installed R 2.1.1 on that machine (which has an AMD processor) yesterday and it was using MASS version 7.2-16. Running `update.packages' today, updated MASS to version 7.2-18. And, lo and behold, there are no more warning messages, even more, running the example in `fitdistr' now returns: > set.seed(123) > x <- rgamma(100, shape = 5, rate = 0.1) > fitdistr(x, "gamma") shape rate 6.45947303 0.13593172 (0.89052006) (0.01948648) > ## now do this directly with more control. > fitdistr(x, dgamma, list(shape = 1, rate = 0.1), lower = 0.01) shape rate 6.48714685 0.13651706 (0.89442924) (0.01956916) So it was perhaps lucky that I did not run update.packages yesterday, since I would have expected that (like PR#1717) my bug report would be filed under not-reproducible. :-) But this made me curious, and I fired my laptop (which has an Intel chip) up under Windows (usually it runs under Linux) and installed R 2.1.1 on it. On that Windows machine, I get the same answers as those reported yesterday under both MASS 7.2-16 and 7.2-18. Thus, I am a bit baffled. Well, I just went back to the AMD box and re-run the code, now it gives me again the "nonsense" answer in the second case. There is definitely something wrong in the L-BFGS-B routine, which will be hard to find. Regarding the changed subject line: After installing R 2.1.1 on my laptop, I executed an R source file which, essentially, only contains an install.packages command with the list of contributed packages that I like to have installed. One of this packages is DAAG and it seems that overnight the file DAAG_0.58.zip disappeared from http://mirror.aarnet.edu.au/pub/CRAN/bin/windows/contrib/2.1/ so the install.packages command terminated with an error message that the source file could not be downloaded. Would it be possible to robustify the install.packages command such that it continues with installing all the other packages requested instead of terminating? After redirecting R 2.1.1 on my laptop to use http://cran.au.r-project.org/ for the CRAN repository, the install.packages() command ran without problems. I issued the command `library(MASS)' and tried out the example from fitdistr on that machine (same strange result for second command and warning messages were issued). So I said update.packages() and that command failed when it wanted to update the MASS package. So I detach()'ed MASS and re-ran update.packages() and again it failed. So I exited R 2.1.1 and restarted it again (probably I should have unloaded the namespace of MASS??) and then the update.packages command worked. However, update.packages() wanted to update quite a few packages besides MASS (the other packages in the VR bundle, nlme, lattice &c). Once it failed on MASS, it terminated with an error and did not update any of the other packages. Would it be possible to robustify update.packages behaviour such that it would continue in such situations with updating the remaining packages? Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Coding standards (was Re: bug in L-BFGS-B? (PR#8099))
G'day Brian,
> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]> writes:
BDR> As for the problem, yes it probably is a bug in L-BFGS-B.
BDR> Fancy debugging the code?
I was afraid that somebody would ask this. ;-)
I looked a bit at the code and it seems to be non-trivial. Moreover,
it seems to be code translated from FORTRAN to C via f2c and I am not
a fan of such kind of code. I know that "Writing R Extensions" lists
in Appendix B ("R coding standards") f2c as a tool that `can "safely
be assumed" for R extensions'. However, f2c, despite its `-A' option,
does not produce ANSI C compliant code but rather C code that provokes
undefined behaviour.
The problem is, that the code produced by f2c is decrementing pointers
to simulate 1-based vectors and the C FAQ is pretty unambigious about
the fact that this provokes undefined behaviour, see
http://www.eskimo.com/~scs/C-faq/q6.17.html
As far as I understand, this translated code mostly stems from the
time when some platforms did not have ready access to a fortran
compiler and, hence, f2c was used (extensively?). But now, with g77
this does not seem to be an issue anymore. So I wonder whether there
are any plans of returning to the original fortran code? Or are there
plans to clean up these f2c'd code snippet to make them ANSI C
compliant?
I noticed such f2c'd code already in the splines.c file when I studied
how splinefun was implemented (which lead to bug report #8030). In
that case, I am fairly familiar with the algorithms used in splines.c
since I programmed them myself on other occassions and I probably
could rewrite the algorithms in proper ANSI C (it would still take
some time). But it would be nice to know what the official stance of
the R Core Team is.
When I spoke with one member of the R Core Team about this on a
conference in 2004, the answer was, IIRC, "yes, we know that this code
invokes undefined behaviour, but there are bigger problems to fix
first and this pointer manipulation seems to work on all platforms
these days." Another member of the R Core Team whom I recently asked:
I guess all platforms on which R is running at the moment do not
have a problem with this trick, but are there any plans to
change such kind of code to "valid" C? Would patches that do
that be accepted?
answered:
Hmm, I think we'd tend to disagree here. But in any case that
would be a wide issue. Can you address this question to R-core,
please? (or I forward?)
Cheers,
Berwin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] robustness of install.packages/update.packages (was Re: bug in L-BFGS-B? (PR#8099))
G'day Brian, > "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]> writes: BDR> We've never encountered this lying mirror problem. Indeed, that mirror is a worry, I guess that is the reason why it is not on the official mirror list. We had the problem with install.packages/update.packages under linux too: source packages that supposedly should have been on the mirror were not and the commands just terminated with an error message instead of installing all those packages that could be found. Unfortunately, the way we are charged for internet traffic, it is much cheaper for us to use mirror.aarnet.edu.au than any other mirror. I remember that last year around this time (give or take a some months) when a new R version was released (2.0.0?) it took actually quite some time before the sources appeared on the mirror, the directory structure was mirrored, but not the files. That was when I decided to (temporarily) change mirrors. BDR> Perhaps you (or another user of the unreliable mirror) could BDR> contribute suitable fixes. I will look into this when I find some time. Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] robustness of install.packages/update.packages (was Re: bug in L-BFGS-B? (PR#8099))
G'day Brian, > "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]> writes: >>> However, update.packages() wanted to update quite a few >>> packages besides MASS (the other packages in the VR bundle, >>> nlme, lattice &c). Once it failed on MASS, it terminated with >>> an error and did not update any of the other packages. Would >>> it be possible to robustify update.packages behaviour such >>> that it would continue in such situations with updating the >>> remaining packages? >> Not a good idea. Better to follow the FAQ. At that point the >> dependencies have been worked out and will not be re-computed >> if a package installation fails. BDR> I checked, and I am unable to reproduce this. I get O.k., I tried to reproduce the behaviour. So I installed the binary distribution of R 2.1.1 in another directory on my laptop once more (and then deleted the copy that I actually wanted to keep; shouldn't do such things at this time of the day). So below I attach what is, I believe a faithful reproduction of what I tried to do yesterday. Except that I did not run the file that installs all the contributed packages that I like to have installed. But it seems that now VR_7.2-17.zip has vanished from mirror.aarnet.edu.au and you can see how on the first occassion the download stops with an error. I believe that in this case it could have continued to download the other files. Once I changed the mirror, the other behaviour that I mentioned becomes apparent. But I take your point that because of package dependencies it might actually be not wise to continue with updating further packages once the update of a package has failed. But then, shouldn't in that case (by the same argument) all the updates that have been done already be undone again? Cheers, Berwin ++ Transcript of R session R : Copyright 2005, The R Foundation for Statistical Computing Version 2.1.1 (2005-06-20), ISBN 3-900051-07-0 R is free software and comes with ABSOLUTELY NO WARRANTY. You are welcome to redistribute it under certain conditions. Type 'license()' or 'licence()' for distribution details. Natural language support but running in an English locale R is a collaborative project with many contributors. Type 'contributors()' for more information and 'citation()' on how to cite R or R packages in publications. Type 'demo()' for some demos, 'help()' for on-line help, or 'help.start()' for a HTML browser interface to help. Type 'q()' to quit R. > library(MASS) > update.packages() boot : Version 1.2-22 installed in C:/PROGRA~1/R/rw2011/library Version 1.2-23 available at http://mirror.aarnet.edu.au/pub/CRAN Update (y/N/c)? y VR : Version 7.2-16 installed in C:/PROGRA~1/R/rw2011/library Version 7.2-17 available at http://mirror.aarnet.edu.au/pub/CRAN Update (y/N/c)? y cluster : Version 1.10.0 installed in C:/PROGRA~1/R/rw2011/library Version 1.10.1 available at http://mirror.aarnet.edu.au/pub/CRAN Update (y/N/c)? y foreign : Version 0.8-8 installed in C:/PROGRA~1/R/rw2011/library Version 0.8-9 available at http://mirror.aarnet.edu.au/pub/CRAN Update (y/N/c)? y lattice : Version 0.11-8 installed in C:/PROGRA~1/R/rw2011/library Version 0.12-3 available at http://mirror.aarnet.edu.au/pub/CRAN Update (y/N/c)? y mgcv : Version 1.3-1 installed in C:/PROGRA~1/R/rw2011/library Version 1.3-4 available at http://mirror.aarnet.edu.au/pub/CRAN Update (y/N/c)? y nlme : Version 3.1-60 installed in C:/PROGRA~1/R/rw2011/library Version 3.1-62 available at http://mirror.aarnet.edu.au/pub/CRAN Update (y/N/c)? y trying URL 'http://mirror.aarnet.edu.au/pub/CRAN/bin/windows/contrib/2.1/boot_1.2-23.zip' Content type 'application/zip' length 767814 bytes opened URL downloaded 749Kb trying URL 'http://mirror.aarnet.edu.au/pub/CRAN/bin/windows/contrib/2.1/VR_7.2-17.zip' Error in download.file(url, destfile, method, mode = "wb") : cannot open URL 'http://mirror.aarnet.edu.au/pub/CRAN/bin/windows/contrib/2.1/VR_7.2-17.zip' In addition: Warning message: cannot open: HTTP status was '404 Not Found' > options(repos=c(CRAN="http://cran.au.r-project.org/";)) > options()$repos CRAN "http://cran.au.r-project.org/"; > update.packages() boot : Version 1.2-22 installed in C:/PROGRA~1/R/rw2011/library Version 1.2-23 available at http://cran.au.r-project.org Update (y/N/c)? y VR : Version 7.2-16 installed in C:/PROGRA~1/R/rw2011/library Version 7.2-19 available at http://cran.au.r-project.org Update (y/N/c)? y cluster : Version 1.10.0 installed in C:/PROGRA~1/R/rw2011/library Version 1.10.1 available at http://cran.au.r-project.org Update (y/N/c)? y foreign : Version 0.8-8 installed in C:/PROGRA~1/R/rw2011/library Version 0.8-10 available at http://cran.au.r-project.org Update (y/N/c)? y lattice : Version 0.11-8 installed in C:/PROGRA~1/R/rw2011/library Version 0.12-5 available at htt
Re: [Rd] Writing R-extensions
G'day Luke,
>>>>> "LT" == Luke Tierney <[EMAIL PROTECTED]> writes:
>> On Sat, 27 Aug 2005, Berwin A Turlach wrote:
>>> 3) The final sentence in the section on `Registering S3
>>> methods' is:
>>>
>>> Any methods for a generic defined in a package that does not
>>> use a name space should be exported, and the package defining
>>> and exporting the method should be attached to the search path
>>> if the methods are to be found.
>>>
>>> [...] is the implication of that sentence that if I have a
>>> package with a name space which defines a method for a generic
>>> defined in another package that does not use a name space,
>>> then this method is only found if my package is attached to
>>> the search path and mere loading of the namespace is not
>>> sufficient?
LT> There is no typo here and your reading in the paragraph above
LT> is correct.
Thanks for the clarification.
May I suggest that nevertheless there is a typo in this sentence and
it should be " the package defining and exporting the methods..."?
One reason why this sentence had me puzzled was that it uses twice
"methods" and once "method". :)
Cheers,
Berwin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] small bug in gl1ce, package lasso2 (PR#8280)
>>>>> "BDR" == ripley <[EMAIL PROTECTED]> writes:
BDR> Please do read the FAQ:
BDR> Finally, check carefully whether the bug is with R, or a
BDR> contributed package. Bug reports on contributed packages
BDR> should be sent first to the package maintainer, and only
BDR> submitted to the R-bugs repository by package maintainers,
BDR> mentioning the package in the subject line.
And Brian forgot to point out that you should probably not file a bug
report on your bug report since somebody has to clean up after you. :)
Now there is PR#8279 and PR#8280 to deal with, the second one should
have been a follow up for the first.
BDR> You are not the maintainer, so this is the wrong place.
Well, I am not the maintainer either, but just a short note:
You should read the documentation of the argument 'standardize', whose
default is TRUE:
standardize: logical flag: if 'TRUE', then the columns of the model
matrix that correspond to parameters that are constrained
are standardized to have empirical variance one. The
standardization is done after taking possible weights into
account and after sweeping out variables whose parameters
are not constrained.
If you have a constant term in your model, then you can not
standardize it. So if you set 'sweep.out' to NULL and have a constant
term in your model, then you should set standardize to FALSE. If you
still want to standardize your non constant regressor variables, then
you have to do it yourself and pass the variables as you want them to
gl1ce.
IMO, there is no bug here, the functions were designed to work in this
way.
Cheers,
Berwin
====== Full address
Berwin A Turlach Tel.: +61 (8) 6488 3338 (secr)
School of Mathematics and Statistics+61 (8) 6488 3383 (self)
The University of Western Australia FAX : +61 (8) 6488 1028
35 Stirling Highway
Crawley WA 6009e-mail: [EMAIL PROTECTED]
Australiahttp://www.maths.uwa.edu.au/~berwin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Suggested changes to R-lang.texi and R-exts.texi
Dear all,
I would like to suggest the following changes to the R documentation:
1) R-exts.texi:
Having had my first experience with uploading a package to
ftp://cran.R-project.org/incoming/, I think it would be nice if the
documentation pointed out that one should use ftp and not sftp (at
least on my machine sftp failed to make a connection) and that one
should log in as user 'anonymous' and not 'guest'. As it is, I had
to figure this out by trial and error. It would also be nice, if
in the phrase "sent a message to [EMAIL PROTECTED] about it" the
e-mail address would be a mailto: URL.
The patch file attached below would modify R-exts.texi to
incorporate all these chanes.
2) R-lang.texi:
There was recently a short discussion on one of the R mailing list
by someone who got bitten by partial matching. Looking at
R-lang.texi and the section that explains how function arguments
are matched, I notice that the second step is explained thus:
"Each named supplied argument is compared to the remaining formal
arguments using partial matching."
It might be just me, but when reading a sentence like this I start
to wonder why the qualifier "remaining" is used for formal
arguments but not for named supplied arguments and I am left
momentarily confused. I would like to suggest that the start of
the sentence is changed to "Each remaining named supplied
argument...".
The patch file attached below would modify R-exts.texi to
incorporate all these chanes.
The patch file attached below was produced by running "svn diff" on my
machine in the directory that contains the trunk of the R-devel
version of R. So the patch file also includes the patch corresponding
to my bugreport #8218
Cheers,
Berwin
Index: src/library/base/man/complex.Rd
===
--- src/library/base/man/complex.Rd (revision 36285)
+++ src/library/base/man/complex.Rd (working copy)
@@ -52,7 +52,8 @@
complex values. Modulus and argument are also called the \emph{polar
coordinates}. If \eqn{z = x + i y} with real \eqn{x} and \eqn{y},
\code{Mod}\eqn{(z) = \sqrt{x^2 + y^2}}, and for
- \eqn{\phi= Arg(z)}, \eqn{x = \cos(\phi)} and \eqn{y = \sin(\phi)}.
+ \eqn{\phi= \code{Arg}(z)}, \eqn{x = \code{Mod}(z)\cos(\phi)} and
+ \eqn{y = \code{Mod}(z)\sin(\phi)}.
They are all generic functions: methods can be defined
for them individually or via the \code{\link{Complex}} group generic.
Index: doc/manual/R-lang.texi
===
--- doc/manual/R-lang.texi (revision 36285)
+++ doc/manual/R-lang.texi (working copy)
@@ -2257,7 +2257,7 @@
the same formal argument match several actuals or vice versa.
@item @strong{Partial matching on tags}.
-Each named supplied argument is compared to the remaining formal
+Each remaining named supplied argument is compared to the remaining formal
arguments using partial matching. If the name of the supplied argument
matches exactly with the first part of a formal argument then the two
arguments are considered to be matched. It is an error to have multiple
Index: doc/manual/R-exts.texi
===
--- doc/manual/R-exts.texi (revision 36285)
+++ doc/manual/R-exts.texi (working copy)
@@ -1369,16 +1369,18 @@
principle, packages must pass @code{R CMD check} without warnings to be
admitted to the main @acronym{CRAN} package area.
-When all the testing is done, upload the @file{.tar.gz} file to
+When all the testing is done, upload the @file{.tar.gz} file, using
[EMAIL PROTECTED] as log-in name and your e-mail address as password, to
@example
@url{ftp://cran.R-project.org/incoming/}
@end example
@noindent
-and send a message to @url{cran@@r-project.org} about it. The
[EMAIL PROTECTED] maintainers will run these tests before putting a
-submission in the main archive.
+(note: use @code{ftp} and not @code{sftp} to connect to this server) and
+send a message to @url{mailto:cran@@r-project.org,,cran@@r-project.org}
+about it. The @acronym{CRAN} maintainers will run these tests before
+putting a submission in the main archive.
Currently, packages containing compiled code should contain at most one
dot in their name to work smoothly under Windows.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Bug or a feature that I completely missed?
Dear all,
while looking at some R-code submitted by students in a unit that I
teach, I came across constructs that I thought would lead to an error.
Much to my surprise, the code is actually executed.
A boiled down version of the code is the following:
> tt <- function(x, i){
+ mean(x[i,2])/mean(x[i,1])
+ }
> dat <- matrix(rnorm(200), ncol=2)
> mean(dat[,2])/mean(dat[,1])
[1] -1.163893
> dat1 <- data.frame(dat)
> tt(dat1) ### Why does this work?
[1] -1.163893
> tt(dat)
Error in mean(x[i, 2]) : argument "i" is missing, with no default
Since the data for the assignment was in a data frame, the students got
an answer and not an error message when they called the equivalent of
tt(dat1) in their work.
I tested this code on R 1.8.1, 1.9.1, 2.0.0, 2.0.1, 2.1.0, 2.1.1,
2.2.0 and R-devel (2005-11-14 r36330), all with the same result, no
error message when executing tt(dat1).
I would have expected that tt(dat1) behaves in the same way as tt(dat)
and would produce an error. Thus, I think it is a bug, but the fact
that so many R versions accept this code makes me wonder whether it is
a misunderstanding on my side. Can somebody enlighten me why this
code is working?
Cheers,
Berwin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R-exts.texi in SVN version 36380
G'day all,
after issuing `svn up' on my machine this morning, I noticed that
`make info' choked on R-exts.texi. Below is a patch that seems to
solve the problem. BTW, while `make info' runs now, I still get the
following warning:
/usr/bin/makeinfo --enable-encoding -D UseExternalXrefs
-I/opt/src/R-devel-src/doc/manual /opt/src/R-devel-src/doc/manual/R-exts.texi
/opt/src/R-devel-src/doc/manual/R-exts.texi:1219: warning: @strong{Note...}
produces a spurious cross-reference in Info; reword to avoid that.
No idea how to fix that, my texinfo knowledge is not good enough. :)
Actually, I am not clear on the following two questions:
1) Should such patches be sent to r-devel, r-bugs or both?
2) Should such patches be sent at all, or should users just wait till
R-core fixes it itself?
Cheers,
Berwin
Index: doc/manual/R-exts.texi
===
--- doc/manual/R-exts.texi (revision 36380)
+++ doc/manual/R-exts.texi (working copy)
@@ -1715,24 +1715,24 @@
@code{myDLL}:
@example
-R_CMethodDef cMethods[] = {
- {"foo", &foo, 4, {REALSXP, INTSXP, STRSXP, LGLSXP}},
- {"bar_sym", &bar, 0},
- {NULL, NULL, 0}
-};
+R_CMethodDef cMethods[] = @{
+ @{"foo", &foo, 4, @{REALSXP, INTSXP, STRSXP, [EMAIL PROTECTED]@},
+ @{"bar_sym", &bar, [EMAIL PROTECTED],
+ @{NULL, NULL, [EMAIL PROTECTED]
[EMAIL PROTECTED];
-R_CallMethodDef callMethods[] = {
- {"R_call_sym", &R_call, 4},
- {"R_version_sym", &R_version, 0},
- {NULL, NULL, 0}
-};
[EMAIL PROTECTED]
+R_CallMethodDef callMethods[] = @{
+ @{"R_call_sym", &R_call, [EMAIL PROTECTED],
+ @{"R_version_sym", &R_version, [EMAIL PROTECTED],
+ @{NULL, NULL, [EMAIL PROTECTED]
[EMAIL PROTECTED];
[EMAIL PROTECTED] example
Then, the directive in the @file{NAMESPACE} file
@example
useDynLib(myDLL, .registration = TRUE)
[EMAIL PROTECTED]
[EMAIL PROTECTED] example
causes the DLL to be loaded and also for the R variables @code{foo},
@code{bar_sym}, @code{R_call_sym} and @code{R_version_sym} to be
@@ -1748,10 +1748,10 @@
@example
R_version =
function()
-{
[EMAIL PROTECTED]
.Call(R_version_sym)
-}
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED] example
More information about this symbol lookup, along with some approaches
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Help page of "par"
Dear all,
the second paragraph on the value returned by par() on the help page
of par says:
When just one parameter is queried, the value is a character
string. When two or more parameters are queried, the result is a
list of character strings, with the list names giving the
parameters.
But this does not seem to be correct:
> par("lty", "ask", "lwd", "oma")
$lty
[1] "solid"
$ask
[1] FALSE
$lwd
[1] 1
$oma
[1] 0 0 0 0
Only the first one is a character string, the other ones are a
logical, a number and a vector of numbers, respectively. Should it
rather be something like (also in view of the next sentence):
When just one parameter is queried, the value of that parameter
is returned as a vector. When two or more parameters are
queried, their values are returned in a list, with the list names
giving the parameters.
Cheers,
Berwin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Enlightenment sought and a possible buglet in vector.Rd
Dear all,
First, I recently had reasons to read the help page of as.vector() and
noticed in the example section the following example:
x <- c(a = 1, b = 2)
is.vector(x)
as.vector(x)
all.equal(x, as.vector(x)) ## FALSE
However, in all versions of R in which I executed this example, the
all.equal command returned TRUE which suggest that either the comment
in the help file is wrong or the all.equal/as.vector combination does
not work as intended in this case. For the former case, I attach
below a patch which would fix vector.Rd.
Secondly, I stumbled across two behaviours of R that I cannot explain
but would like to know why R behaves as it does. But since I expect
the explanations to be quite technical, I though that r-devel is the
more appropriate list to ask on than r-help.
The first example is the following:
> f1
function(){
par.def <- par(no.readonly=TRUE)
on.exit(par(par.def))
tt <- sys.on.exit()
print(tt)
str(tt)
invisible()
}
> f1()
par(par.def)
language par(par.def)
> f2
function(){
par.def <- par(no.readonly=TRUE)
on.exit(par(par.def))
print(tt <- sys.on.exit())
str(tt)
invisible()
}
> f2()
NULL
NULL
I found in the R language definition manual the passage that
discourages users of assigning objects within function calls since it
is not guaranteed that the assignment is ever made because of R's lazy
evaluation model. But this does not seem to explain the above
behaviour since the argument to print is evaluated. If I replace
sys.on.exit() with, say, ls() in both functions, then they produce the
same output (and the output that I expect). Why does f2() not work
with sys.on.exit()?
The second behaviour that I cannot explain was produced by code
written by somebody else, namely:
> foo
function(x){
z <- x/4
while( abs(z*z*z-x) > 1e-10 ){
z <- (2*z+x/z^2)/3
}
}
The documentation of function() says that if "the end of a function is
reached without calling 'return', the value of the last evaluated
expression is returned." And this seems to happen in this case:
> z <- foo(3)
> z
[1] 1.442250
However, my understanding was always that the return value of a
function issued on the command line will be printed; except, of
course, if invisible() is used to return the value. This is not the
case for the above function:
> foo(3)
produces no output. And this had us stunned for some time. On the
other hand:
> ( foo(3) )
[1] 1.442250
So my question is why does R, when "foo(3)" is issued on the command
line, not print the value returned by the function?
Any enlightening comments are highly appreciated.
Cheers,
Berwin
Index: src/library/base/man/vector.Rd
===
--- src/library/base/man/vector.Rd (revision 36569)
+++ src/library/base/man/vector.Rd (working copy)
@@ -66,7 +66,7 @@
x <- c(a = 1, b = 2)
is.vector(x)
as.vector(x)
-all.equal(x, as.vector(x)) ## FALSE
+all.equal(x, as.vector(x)) ## TRUE
###-- All the following are TRUE:
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Enlightenment sought and a possible buglet in vector.Rd
G'day Brian,
>>>>> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]> writes:
BDR> On Fri, 2 Dec 2005, Berwin A Turlach wrote: [...]
>> The second behaviour that I cannot explain was produced by code
>> written by somebody else, namely:
[...]
>> The documentation of function() says that if "the end of a
>> function is reached without calling 'return', the value of the
>> last evaluated expression is returned." And this seems to
>> happen in this case:
BDR> Yes, but that value can be returned with R_Visible set to 0,
BDR> by calling invisible() _or otherwise_.
Thanks for the clarification. I had the sneaking suspicion that
something like this was happening, but couldn't find anything in the
documentation.
I vaguely remember that S has a mechanism to switch auto-printing
on/off via a variable, whose name started with ".", but couldn't find
anything in the blue book (by now I found .Auto.print in Suesselbeck
and VR "S programming). Since we don't have a license for S-plus
anymore, I couldn't check S-Plus and I didn't find anything similar in
R. I take it that R handles all this via R_Visible at the C level?
BDR> R does not print the value of a while() loop. [...] (Look
BDR> up the code of do_while for why.)
I can see that in the code of do_while the variable R_Visible is set
to zero, but there is no explanation for why this is done. But I
guess it is for compatibility reasons with S, since by now I found in
various books on the S language that the while() loop returns its
value invisible.
Thanks for adding the value section to the help page to clarify this
issue in the R documentation.
Cheers,
Berwin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Enlightenment sought and a possible buglet in vector.Rd
G'day Brian,
> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]> writes:
>> I found in the R language definition manual the passage that
>> discourages users of assigning objects within function calls
>> since it is not guaranteed that the assignment is ever made
>> because of R's lazy evaluation model. But this does not seem
>> to explain the above behaviour since the argument to print is
>> evaluated. If I replace sys.on.exit() with, say, ls() in both
>> functions, then they produce the same output (and the output
>> that I expect). Why does f2() not work with sys.on.exit()?
BDR> It does work, but you seems to have misunderstood what it
BDR> does. See e.g. the `bug' report discussed at
BDR> http://tolstoy.newcastle.edu.au/~rking/R/devel/05/02/2112.html
Mmh, mea culpa, I am a bit red-faced here, in my quest to find out
what was going on, I checked about everything (including a private
e-mail to an R-core member) but the bug repository and the help page
of sys.on.exit(). I guess that if I have read the latter, I would
have figured out what was going on. Instead I was satisfied with what
the on.exit() help page stated in its "see also" section:
\seealso{
\code{\link{sys.on.exit}} to see the current expression.
}
May I request that this help page is changed according to the patch
attached below to clarify on the on.exit() help page what it is that
sys.on.exit() is returning?
BDR> You might find
BDR> g <- function(test) {}
BDR> f2 <- function(){
BDR> par.def <- par(no.readonly=TRUE)
BDR> on.exit(par(par.def))
BDR> g(tt <- sys.on.exit())
BDR> str(tt)
BDR> invisible()
BDR> }
BDR> f2()
BDR> illuminating.
Mmh, in this code the function g is not evaluating its argument. So I
would expect an error message in f2() that tt is not defined no matter
which function (sys.on.exit, ls, ...) I am using in the call to g()
within f(). Exactly the situation about which the R language
definition is warning, so this seems to be a different trap than the
one I stepped into
Cheers,
Berwin
Index: src/library/base/man/on.exit.Rd
===
--- src/library/base/man/on.exit.Rd (revision 36611)
+++ src/library/base/man/on.exit.Rd (working copy)
@@ -19,7 +19,8 @@
\arguments{
\item{expr}{an expression to be executed.}
\item{add}{if TRUE, add \code{expr} to be executed after any previously
-set expressions.}
+set expressions; otherwise (the default) \code{expr} will overwrite
+any previously set expressions.}
}
\references{
Becker, R. A., Chambers, J. M. and Wilks, A. R. (1988)
@@ -27,7 +28,9 @@
Wadsworth \& Brooks/Cole.
}
\seealso{
- \code{\link{sys.on.exit}} to see the current expression.
+ \code{\link{sys.on.exit}} which returns the expression stored for use
+ by \code{on.exit()} in the function in which \code{sys.on.exit()} is
+ evaluated.
}
\examples{
opar <- par(mai = c(1,1,1,1))
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check, NAMESPACE, import: bad error?
G'day Seth,
> "SF" == Seth Falcon <[EMAIL PROTECTED]> writes:
SF> I'm seeing errors with R CMD check that I don't understand
SF> when checking a package that uses a NAMESPACE file with an
SF> import directive.
I came sometime ago across a similar problem and it took me some time
to figure it out. In my case it was that a .Fortran() call didn't
have a "package=" argument. My advise would be to check all .C() and
.Fortran() calls in your package and add the "package=" argument if it
is missing.
I also guess that if you temporarily remove the NAMESPACE file, the
following step in the checking process:
* checking foreign function calls ... WARNING
Error: package/namespace load failed for 'DNAhelperseth'
Call sequence:
2: stop(gettextf("package/namespace load failed for '%s'",
libraryPkgName(package)),call. = FALSE, domain = NA)
1: library(package, lib.loc = lib.loc, character.only = TRUE, verbose =
FALSE)
Execution halted
See section 'System and foreign language interfaces' of the 'Writing R
Extensions' manual.
will tell you which call the culprit is.
Cheers,
Berwin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check, NAMESPACE, import: bad error?
G'day Brian, > "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]> writes: BDR> We do recommend you try INSTALLing and loading the package BDR> before R CMD check. I have to rely on my memory, but if I remember correctly, installing and loading the package worked. It was only when it came to "R CMD check" that the combination of having a NAMESPACE and no "PACKAGE=" argument in a .Fortran() call made "R CMD check" complain. (With much the same complaints that Seth reported). But now I am utterly confused because I wanted to test if my memory is correct. So I went back to the package (called SCSS) with which I experienced these problems (according to the dates of the files I was putting that package together around 12 October 2005, which was just after the release of R 2.2.0 and I believe I was using that version). After removing the "PACKAGE=" arguments from the .Fortran() calls, the package installs and loads fine. But to my utter amazement, "R CMD check" now works without a problem. I tried this command with R 2.1.1, R 2.2.0, R 2.2.1 and R 2.3.0 (i.e. R-devel). What surprised me most, was that all these versions said * checking foreign function calls ... OK I thought that this check is supposed to catch missing "PACKAGE=" arguments in .C(), .Fortran() &c calls??? The only explanation I have, is that my Debian linux system was some time ago upgraded to gcc 4.0.3 and gfortran. Indeed, running "R CMD check" with R 2.3.0 produces a 00install.out file in the SCSS.Rcheck directory that says: * Installing *source* package 'SCSS' ... ** libs make[2]: Entering directory `/home/berwin/lang/R/Develop/SCSS/src' gfortran -fpic -g -O2 -c evsp.f -o evsp.o gfortran -fpic -g -O2 -c evsp1d.f -o evsp1d.o gfortran -fpic -g -O2 -c repar.f -o repar.o gcc -shared -L/usr/local/lib -o SCSS.so evsp.o evsp1d.o repar.o -lgfortran -lm -lgcc_s whereas R 2.1.1, R 2.2.0 and R 2.2.1 issue the following lines during "R CMD check": * Installing *source* package 'SCSS' ... ** libs make[2]: Entering directory `/home/berwin/lang/R/Develop/SCSS/src' g77 -fPIC -g -O2 -c evsp.f -o evsp.o g77 -fPIC -g -O2 -c evsp1d.f -o evsp1d.o g77 -fPIC -g -O2 -c repar.f -o repar.o gcc -shared -L/usr/local/lib -o SCSS.so evsp.o evsp1d.o repar.o -L/usr/lib/gcc/i486-linux-gnu/3.4.5 -lg2c -lm -lgcc_s since those versions of R where compiled and installed while I was using gcc 3.4 on my machine. But on my machine I have now: [bossiaea:Develop]$ file `which gcc` /usr/bin/gcc: symbolic link to `gcc-4.0' I redirected the link to point to gcc-3.4, but I still could not reproduce the problems that I experienced last October (and which Seth experienced right now). Perhaps the problem only occurs with a very specific version of the gcc compiler?? >> [...] My advise would be to check all .C() and .Fortran() >> calls in your package and add the "package=" argument if it is >> missing. BDR> (It had better be PACKAGE= !) Of course, my bad. Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Development version of R fails tests and is not installed
G'day all,
I have daily scripts running to install the patched version of the
current R version and the development version of R on my linux box
(Ubuntu 18.04.2 LTS).
The last development version that was successfully compiled and
installed was "R Under development (unstable) (2019-02-25 r76159)" on
26 February. Since then the script always fails as a regression test
seems to fail. Specifically, in the tests/ subdirectory of my build
directory I have a file reg-tests-1d.Rout.fail which ends with:
> ## checking ar.yw.default() multivariate case
> estd <- ar(unclass(y) , aic = FALSE, order.max = 2) ## Estimate VAR(2)
> es.d <- ar(unclass(y.), aic = FALSE, order.max = 2, na.action=na.pass)
> stopifnot(exprs = {
+ all.equal(est$ar[1,,], diag(0.8, 2), tol = 0.08)# seen 0.0038
+ all.equal(est[1:6], es.[1:6], tol = 5e-3)
+ all.equal(estd$x.mean, es.d$x.mean, tol = 0.01) # seen 0.0023
+ all.equal(estd[c(1:3,5:6)],
+ es.d[c(1:3,5:6)], tol = 1e-3)## seen {1,3,8}e-4
+ all.equal(lapply(estd[1:6],unname),
+ lapply(est [1:6],unname), tol = 2e-12)# almost identical
+ all.equal(lapply(es.d[1:6],unname),
+ lapply(es. [1:6],unname), tol = 2e-12)
+ })
Error: lapply(es.d[1:6], unname) and lapply(es.[1:6], unname) are not equal:
Component "aic": Mean relative difference: 3.297178e-12
Execution halted
Would it be possible to make this tolerance more lenient? In case it
matters, I am configuring R to be compiled using Openblas and this test
fails for the 64 bit installation, the 32 bit installation seems to
pass all tests.
Happy to provide any more information/context that might be needed.
Cheers,
Berwin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Development version of R fails tests and is not installed
G'day all,
I have daily scripts running to install the patched version of the
current R version and the development version of R on my linux box
(Ubuntu 18.04.4 LTS).
The last development version that was successfully compiled and
installed was "R Under development (unstable) (2020-01-25 r77715)" on
27 January. Since then the script always fails as a regression test
seems to fail. Specifically, in the tests/ subdirectory of my build
directory I have a file reg-tests-1d.Rout.fail which ends with:
> ## more than half of the above were rounded *down* in R <= 3.6.x
> ## Some "wrong" test cases from CRAN packages (partly relying on wrong R <=
> 3.6.x behavior)
> stopifnot(exprs = {
+ all.equal(round(10.7775, digits=3), 10.778, tolerance = 1e-12) # even
tol=0, was 10.777
+ all.equal(round(12345 / 1000, 2), 12.35 , tolerance = 1e-12) # even
tol=0, was 12.34 in Rd
+ all.equal(round(9.18665, 4),9.1866, tolerance = 1e-12) # even
tol=0, was 9.1867
+ })
Error: round(10.7775, digits = 3) and 10.778 are not equal:
Mean relative difference: 9.27902e-05
Execution halted
This happens while the 32bit architecture is installed, which is a bit
surprising as I get the following results for the last installed
version of R's development version:
R Under development (unstable) (2020-01-25 r77715) -- "Unsuffered Consequences"
Copyright (C) 2020 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu/32 (32-bit)
[...]
> round(10.7775, digits=3)
[1] 10.778
and
R Under development (unstable) (2020-01-25 r77715) -- "Unsuffered Consequences"
Copyright (C) 2020 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu/64 (64-bit)
[...]
> round(10.7775, digits=3)
[1] 10.778
On the other hand, the R 3.6.2 version, that I mainly use at the moment,
gives the following results:
R version 3.6.2 (2019-12-12) -- "Dark and Stormy Night"
Copyright (C) 2019 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu/32 (32-bit)
[...]
> round(10.7775, digits=3)
[1] 10.777
and
R version 3.6.2 (2019-12-12) -- "Dark and Stormy Night"
Copyright (C) 2019 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu/64 (64-bit)
[...]
> round(10.7775, digits=3)
[1] 10.777
So it seems as if the behaviour of round() has changed between R 3.6.2
and the development version. But I do not understand why this test all
of a sudden failed if the results from the last successfully installed
development version of R suggest that the test should be passed.
Thanks in advance for any insight and tips.
Cheers,
Berwin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Development version of R fails tests and is not installed
G'day Jeroen, On Sun, 9 Feb 2020 01:04:24 +0100 Jeroen Ooms wrote: > I think the intention was to add something similar in R's autoconf > script to enable sse on 32-bit unix systems, but seemingly this hasn't > happened. For now I think you should be able to make your 32-bit > checks succeed if you build R with CFLAGS=-mfpmath=sse -msse2. Just for the record, adding CFLAGS="-mfpmath=sse -msse2" to the config.site file used to compile the 32bit version of R's development version fixed the problem indeed. The installation script ran from the command line with out error to the end, and every day since then at this crontab'd time. Looks as if it would be good indeed if R's autoconf script would enable sse on 32-bit unix systems. :) Thank you for the solution. Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Matrix install fails because of defunct save in require
G'day Uwe, On Fri, 17 Sep 2010 19:22:04 +0200 Uwe Ligges wrote: > > > On 17.09.2010 16:04, Thomas Petzoldt wrote: > > Dear R-Devel, > > > > I've just tried to compile the fresh R-devel and found that the > > install of package Matrix failed: > > > > - > > ** help > > *** installing help indices > > ** building package indices ... > > Error in require(Matrix, save = FALSE) : > > unused argument(s) (save = FALSE) > > ERROR: installing package indices failed > > - > > > Have you got the Matrix package from the appropriate 2.12/recommended > repository or installed via > > make rsync-recommended > make recommended Are those the commands that should now be used? My script is essentially doing: svn up tools/rsync-recommended make make check FORCE=FORCE Running the script now, I experience the same problem as Thomas. But I note that Thomas did not state exactly what he is compiling. My 'svn up' updates the version checked out from: https://svn.r-project.org/R/trunk which I think of as R-devel. Now after the svn up the file VERSION in the source directory says: 2.13.0 Under development (unstable) The SVN-REVISION file in my build directory says: Revision: 52938 Last Changed Date: 2010-09-17 And I have Matrix_0.999375-44.tar.gz in src/library/Recommended of my source directory. As you refer to 2.12/recommended, you and Thomas might talk about different versions when talking about R-devel. Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] checking user interrupts in C(++) code
G'day Simon,
since Karl brought up this topic, I thought I might use it to seek
clarification for something that bothered me for some time.
On Tue, 28 Sep 2010 14:55:34 -0400
Simon Urbanek wrote:
> There are several ways in which you can make your code respond to
> interrupts properly - which one is suitable depends on your
> application. Probably the most commonly used for interfacing foreign
> objects is to create an external pointer with a finalizer - that
> makes sure the object is released even if you pass it on to R later.
> For memory allocated within a call you can either use R's transient
> memory allocation (see Salloc) or use the on.exit handler to cleanup
> any objects you allocated manually and left over.
But what about objects created by allocVector() or NEW_ in C code
that is called via .Call that need to be PROTECT'd?
The "Writing R Extensions" manual states:
The programmer is solely responsible for housekeeping the calls
to @code{PROTECT}. There is a corresponding macro
@code{UNPROTECT} that takes as argument an @code{int} giving
the number of objects to unprotect when they are no longer
needed. The protection mechanism is stack-based, so
@code{UNPROTECT(@var{n})} unprotects the last @var{n} objects
which were protected. The calls to @code{PROTECT} and
@code{UNPROTECT} must balance when the user's code returns.
@R{} will warn about @code{"stack imbalance in .Call"} (or
@code{.External}) if the housekeeping is wrong.
If a call to R_CheckUserInterrupt() may not return, does that mean that
you should not call this function while you have objects PROTECT'd?
Even more, the section on R_CheckUserInterrupt() states:
Note that it is possible that the code behind one of the entry
points defined here if called from your C or FORTRAN code could
be interruptible or generate an error and so not return to your
code.
This seems to imply that, if you have objects PROTECT'd in your code,
you shouldn't use any of the R API defined in Chapter 6 of the manual,
except if you know that it doesn't call R_CheckUserInterrupt(), and
there seems to be no documentation on which functions in the API do and
which don't.
I guess my question is, essentially, does the PROTECT mechanism and
R_CheckUserInterrupt() play together nicely? Can I call the latter
from code that has objects PROTECT'd? If yes, and the code gets
interrupted, is the worse that happens a warning about a stack
imbalance, or will the R session become "unusable/unstable"?
Thanks in advance for any enlightening comments.
Cheers,
Berwin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Query about .check_packages_used_in_examples
G'day all,
looking at
http://cran.at.r-project.org/web/checks/check_results_Sleuth2.html
I noticed that r-prerel-* and r-devel-* issue notes. Apparently, now
examples are more thoroughly checked by R CMD check and the note
pointed out that a package used in the examples was not declared. This
was easily fixed by adding 'Suggests: lattice' to the DESCRIPTION file
(now this change has to migrate through R-forge to CRAN).
But then I noticed that for another package I have on R-forge a similar
note is issued:
https://r-forge.r-project.org/R/?group_id=630&log=check_x86_64_linux&pkg=DeconWK&flavor=devel
O.k., R-forge is using R-devel, so I installed R 2.12.0 RC (2010-10-10
r53273) on my machine to check, same note is issued.
The note issued by R CMD check says:
* checking for unstated dependencies in examples ... NOTE
'library' or 'require' call not declared from: ks
which is a bit surprising.
There are three .Rd files that have a library(ks) in them and ks is
listed in the Imports: of the description file.
This seems to be completely in line with the documentation in "Writing
R extensions":
@item
Packages whose name space only is needed to load the package
using @code{library(@var{pkgname})} must be listed in the
@samp{Imports} field and not in the @samp{Depends} field.
that's why ks is listed in depends
@item
All packages that are needed to successfully run @code{R CMD
check} on the package must be listed in one of @samp{Depends}
or @samp{Suggests} or @samp{Imports}. [...]
which seems to be adhered to, since ks is in the depends.
But upon digging into .check_packages_used_in_examples in QC.R in
package tools, I have the impression that packages loaded in examples
via library() or require() are only checked against packages listed in
Suggests, Enhances and Depends, the package's own name and the standard
packages, but not against those listed in Imports. Thus, I believe
there is some disconnect between documentation and behaviour at the
moment.
In this particular case, possible solutions would be to list ks in
both, Imports and Suggests, or, to have only one entry, to move it to
Depends.
But I believe the cleaner solution would be that
.check_packages_used_in_examples includes the packages listed in
Imports when checking whether all packages used in library() or
require() commands in examples are declared.
Cheers,
Berwin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Query about .check_packages_used_in_examples
G'day all,
sorry, should proof-read better before hitting the send button...
On Mon, 11 Oct 2010 06:06:46 +0800
Berwin A Turlach wrote:
> But then I noticed that for another package I have on R-forge a
> similar note is issued:
> https://r-forge.r-project.org/R/?group_id=630&log=check_x86_64_linux&pkg=DeconWK&flavor=devel
> O.k., R-forge is using R-devel, so I installed R 2.12.0 RC (2010-10-10
> r53273) on my machine to check, same note is issued.
>
> The note issued by R CMD check says:
> * checking for unstated dependencies in examples ... NOTE
> 'library' or 'require' call not declared from: ks
> which is a bit surprising.
>
> There are three .Rd files that have a library(ks) in them and ks is
> listed in the Imports: of the description file.
>
> This seems to be completely in line with the documentation in "Writing
> R extensions":
>
> @item
> Packages whose name space only is needed to load the package
> using @code{library(@var{pkgname})} must be listed in the
> @samp{Imports} field and not in the @samp{Depends} field.
>
> that's why ks is listed in depends
ks is listed in the Imports: line in the DESCRIPTION file of the package
in question, not in the Depends: line.
> @item
> All packages that are needed to successfully run @code{R CMD
> check} on the package must be listed in one of @samp{Depends}
> or @samp{Suggests} or @samp{Imports}. [...]
>
> which seems to be adhered to, since ks is in the depends.
Again, this depends should read Imports.
Sorry if this created confusion.
Cheers,
Berwin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Query about .check_packages_used_in_examples
G'day Brian, On Mon, 11 Oct 2010 11:11:42 +0100 (BST) Prof Brian Ripley wrote: > Sounds reasonable to count Imports, so we'll alter this. Thanks for that. I noticed the changes to R-devel and to the R-2-12-branch. Looking at the diffs (an example is appended below), it seems to me that, except for the ordering, the variables `depends_suggests' and `imports' are the same. This would suggest that only one of them is necessary and that the remaining code could be made leaner... but probably that is something to do after the code freeze is over... > Thank you for the report, However, the pre-test period for 2.12.0 is > already 80% over and we are in code freeze -- reports early on in the > period are much more useful and at this stage anything but very > simple localized changes need to be deferred to 2.12.1. Point taken. When I am back home, I will think about what versions of R I want to have installed on my main machine... should probably also write some scripts that regularly check my packages... Cheers, Berwin ber...@goodenia:/opt/src/R-2-12-branch/src/library/tools/R$ svn diff -r53024 QC.R Index: QC.R === --- QC.R(revision 53024) +++ QC.R(working copy) @@ -3937,7 +3937,7 @@ ## it is OK to refer to yourself and standard packages standard_package_names <- .get_standard_package_names()$base -depends_suggests <- c(depends, suggests, enhances, pkg_name, +depends_suggests <- c(depends, imports, suggests, enhances, pkg_name, standard_package_names) imports <- c(imports, depends, suggests, enhances, pkg_name, standard_package_names) @@ -4038,7 +4038,7 @@ ## it is OK to refer to yourself and standard packages standard_package_names <- .get_standard_package_names()$base -depends_suggests <- c(depends, suggests, enhances, pkg_name, +depends_suggests <- c(depends, imports, suggests, enhances, pkg_name, standard_package_names) imports <- c(imports, depends, suggests, enhances, pkg_name, standard_package_names) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Trying to understand the search path and namespaces
G'day Hadley,
On Mon, 15 Nov 2010 19:45:30 -0600
Hadley Wickham wrote:
> > 1.6 of Writing R Extensions says
> >
> > Note that adding a name space to a package changes the search
> > strategy. The package name space comes first in the search, then
> > the imports, then the base name space and then the normal search
> > path.
> >
> > I'm not sure of the details, but I think
> >
> > Â parents(getNamespace("devtools"))
>
> Ah, my mistake was assuming that the package namespace and environment
> were the same thing.
>
> Interestingly the namespace is dynamic:
Not sure what you mean with this. Section 1.6 of "Writing R
Extensions" explicitly states:
Name spaces are @emph{sealed} once they are loaded. Sealing
means that imports and exports cannot be changed and that
internal variable bindings cannot be changed.
> > parents(getNamespace("devtools"))
> ...
> [31] "base"
> > library(roxygen)
> > parents(getNamespace("devtools"))
> ...
> [31] "Autoloads""base"
Well, as the part of "Writing R Extensions" that Martin quoted states,
the normal search path is part of the search path used by packages with
name spaces. So if you attach another package via library(), the
normal search path changes and, hence,
`parents(getNamespace("devtools"))' has one more location to report.
Cheers,
Berwin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Trying to understand the search path and namespaces
G'day Hadley,
On Tue, 16 Nov 2010 07:35:09 -0600
Hadley Wickham wrote:
> > Well, as the part of "Writing R Extensions" that Martin quoted
> > states, the normal search path is part of the search path used by
> > packages with name spaces. Â So if you attach another package via
> > library(), the normal search path changes and, hence,
> > `parents(getNamespace("devtools"))' has one more location to report.
>
> It's still not at all obvious how this happens - when does variable
> look up use the stack of environments given by the package environment
> and when does it use the stack of environments given by the namespace?
Well, if we are going to nitpick, the former presumably never
happens. :) Section 3.5.4 "Search path" of the "R Language Definition"
might be more illuminating than quotes from "Writing R Extensions".
The first two paragraphs of that section are :
In addition to the evaluation environment structure, @R{}
has a search path of environments which are searched for
variables not found elsewhere. This is used for two things:
packages of functions and attached user data.
The first element of the search path is the global environment
and the last is the base package. An @code{Autoloads}
environment is used for holding proxy objects that may be
loaded on demand. Other environments are inserted in the path
using @code{attach} or @code{library}.
I guess this is what you refer to by "stack of environments given by the
package environment" (though it clearly isn't, if the object/variable
is not found in the evaluation environment structure [I guess Section
3.5.2 "Lexical environment" explains what this is], the search starts in
the global environment, not the environment of the package). The third
and last paragraph of Section 3.5.4 states:
Packages which have a @emph{namespace} have a different search
path. When a search for an @R{} object is started from an
object in such a package, the package itself is searched first,
then its imports, then the base namespace and finally the
global environment and the rest of the regular search path.
The effect is that references to other objects in the same
package will be resolved to the package, and objects cannot be
masked by objects of the same name in the global environment or
in other packages.
I hope this clarifies your remaining doubts about the process.
Cheers,
Berwin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Clean up after "R CMD INSTALL" and/or "R CMD check"
G'day all, I noticed the following (new) behaviour of R 2.12.0, running on Kubuntu 10.10, when installed with sub-architectures: When I run "R CMD INSTALL" or "R CMD check" on the source directory of a package that contains C or FORTRAN code, R creates sub-directories src-32/ and src-64/ that seem to be copies of the src/ subdirectory plus the compiled objects. These directories are not deleted at the end of a successful INSTALL/check and I wonder if there is any particular reason for this? Would it be possible to delete these sub-directories during clean-up at the end of a successful INSTALL/check? Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Clean up after "R CMD INSTALL" and/or "R CMD check"
G'day Brian,
On Fri, 3 Dec 2010 13:14:44 + (GMT)
Prof Brian Ripley wrote:
> > I noticed the following (new) behaviour of R 2.12.0, running on
> > Kubuntu 10.10, when installed with sub-architectures:
>
> Yes, there are new features when there are multiple sub-architectures.
Indeed. One new feature seems to be that if the installation of a
package via
R arch=XXX CMD INSTALL --libs-only
fails then the package is not completely removed but rather the
previously install version is re-installed. IIRC, I had requested this
behaviour some years ago and it is nice to see it now implemented. :)
> > These directories are not deleted at the end of a successful
> > INSTALL/check and I wonder if there is any particular reason for
> > this?
>
> Because it might be partially successful and you want to look at the
> generated objects?
I agree that it would be helpful to look at the generated objects if
the INSTALL/check is only partially successful, that's why I asked
about a successful INSTALL/check. However, it looks...
> In particular 'success' means that the primary sub-architecture is
> installed: others might fail.
... as if we have different definitions of what constitutes 'success';
I take 'success' as meaning successful installation for all
architectures, but accept that you are using the official definition. :)
> > Would it be possible to delete these sub-directories during clean-up
> > at the end of a successful INSTALL/check?
>
> Try INSTALL --clean, etc.
This does not seem to help, the directories in question are not removed.
> But I normally do this from a tarball to keep the sources clean and
> to test the reference sources.
I used to do this too but changed my habits when it was once pointed out
to me that the section "Checking and building packages" in the "Writing
R Extensions" manual starts with:
Before using these tools, please check that your package can be
installed and loaded. @code{R CMD check} will @emph{inter
alia} do this, but you may get more detailed error messages
doing the checks directly.
IIRC, the context was that it took me some time to track down a problem
via "R CMD check foo.tar.gz" as the error messages were not as helpful
in locating the problem as the error messages of "R CMD INSTALL" would
have been. But if "R CMD INSTALL" is to be run before "R CMD check"
and/or "R CMD build" it has to be run on the source directory, hasn't
it? This looks like a chicken-and-egg problem. :)
Or are you now saying that it is o.k. to first run "R CMD build" and
then "R CMD INSTALL" on the tarball?
> There are a few improvements to R-patched in the detection of
> sub-architectures, so you might like to see if you prefer what it
> does.
I tried with:
R version 2.13.0 Under development (unstable) (2010-12-02 r53747)
and
R version 2.12.0 Patched (2010-12-02 r53747)
and I did not see any different behaviour. The subdirectories src-32/
and src-64/ are created and not deleted.
Thank you very much for your comments/insights.
Cheers,
Berwin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] On 'R CMD INSTALL' with multiple architectures
G'day all, I guess it is still early enough in the year to wish everybody a happy and successful new year. I thought I should report that the installation of the CRAN package rstan regularly fails on my machine (a 64 bit linux box running Xubuntu 15.10). The reason being that I have the 32-bit and the 64-bit architecture of R installed, and my /tmp file is on a partition with about 1Gb space. During the installation of rstan the compilation of the source directory regularly fills up my /tmp directory such that at some point the compilation for the 64-bit architecture (my main architecture) fails as /tmp runs out of space. At that time, the src-32 subdirectory has a size of about 460 MB (~ half of the partition!). The most recent version of rstan I finally managed to install by issuing the commands: R CMD INSTALL --no-multiarch rstan_2.9.0.tar.gz followed by R --arch=32 CMD INSTALL --libs-only rstan_2.9.0.tar.gz The last command, to my surprise, actually tried to compile both libraries (32-bit and 64-bit) again. So the installation kept failing until I deleted the src-32 directory while the 64 libraries where build. By now I realise that the R-admin manual only suggests/documents that R --arch=name CMD INSTALL --libs-only pkg1 pgk2 only installs the library for the specified architecture if the package has "an executable configure script or a src/Makefile file", and is quite about its behaviour otherwise. But I wonder whether it would be reasonable for users to expect that 'R --arch=32 CMD INSTALL --libs-only' installs only the library for the specified architecture in all circumstances. Playing around with a package that also has compiled code, but is faster to install than rstan, I realise now that my second command should have been: R --arch=32 CMD INSTALL --libs-only --no-multiarch rstan_2.9.0.tar.gz In summary, I would like to suggest that 'R CMD INSTALL' deletes architecture specific 'src' subdirectories as soon as they are no longer needed and/or that 'R --arch=name CMD INSTALL --libs-only' installs only libraries for the specified architecture (as an unwary user might expect). Cheers, Berwin == Full address A/Prof Berwin A Turlach Tel.: +61 (8) 6488 3338 (secr) School of Maths and Stats (M019)+61 (8) 6488 3383 (self) The University of Western Australia FAX : +61 (8) 6488 1028 35 Stirling Highway Crawley WA 6009 e-mail: berwin.turl...@gmail.com Australiahttp://www.maths.uwa.edu.au/~berwin http://www.researcherid.com/rid/A-4995-2008 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Small inaccuracy in the Writing R Extensions manual
G'day all,
In Chapter 1.4 (Writing package vignettes) the Writing R Extensions
manual states:
By default @code{R CMD build} will run @code{Sweave} on all
Sweave vignette source files in @file{vignettes}. If
@file{Makefile} is found in the vignette source directory, then
@code{R CMD build} will try to run @command{make} after the
@code{Sweave} runs, otherwise @code{texi2pdf} is run on each
@file{.tex} file produced.
This does not seem to be quite correct as stated. 'R CMD build' seems
to run make only if there was a file in the directory vignettes that
Sweave successfully processed. If the directory vignettes contains a
Makefile and subdirectories in which the actual vignettes are, 'R CMD
build' does not run make.
Cheers,
Berwin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Small inaccuracy in the Writing R Extensions manual
G'day Duncan,
On Tue, 12 Jan 2016 07:32:05 -0500
Duncan Murdoch wrote:
> On 11/01/2016 11:59 PM, Berwin A Turlach wrote:
> > G'day all,
> >
> > In Chapter 1.4 (Writing package vignettes) the Writing R Extensions
> > manual states:
> >
> > By default @code{R CMD build} will run @code{Sweave} on all
> > Sweave vignette source files in @file{vignettes}. If
> > @file{Makefile} is found in the vignette source directory,
> > then @code{R CMD build} will try to run @command{make} after the
> > @code{Sweave} runs, otherwise @code{texi2pdf} is run on each
> > @file{.tex} file produced.
> >
> > This does not seem to be quite correct as stated. 'R CMD build'
> > seems to run make only if there was a file in the directory
> > vignettes that Sweave successfully processed. If the directory
> > vignettes contains a Makefile and subdirectories in which the
> > actual vignettes are, 'R CMD build' does not run make.
> >
>
> I think it is behaving as documented: it says it will run make after
> Sweave, so if Sweave never ran, neither would make.
Sorry, I disagree. It says that "R CMD build will try to run make
after the Sweave runs". For me (and probably others) "after the Sweave
runs" (note the plural) include the cases of "no Sweave runs" and "one
Sweave run". Otherwise the case of one vignette in the vignettes
directory would produce undocumented (albeit expected) behaviour. :-)
Cheers,
Berwin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Building R-patched and R-devel fails
G'day all, probably you have noticed this by now, but I thought I ought to report it. :) My scripts that update the SVN sources for R-patched and R-devel, run `tools/rsync-recommended' (for both) and then install both these versions from scratch failed this morning. Apparently the new version of the recommended package `survival' depends on the recommended package `Matrix', but the makefile does not ensure that Matrix is build before survival. So my log files had entries: [...] ERROR: dependency ‘Matrix’ is not available for package ‘survival’ * removing ‘/opt/src/R-devel-build/library/survival’ Makefile:51: recipe for target 'survival.ts' failed make[2]: *** [survival.ts] Error 1 make[2]: *** Waiting for unfinished jobs [...] Presumably, in both branches, the files Makefile.in and Makefile.win in src/library/Recommended have to be adapted to contain the following line at the end among the "Hardcoded dependencies": survival.ts: Matrix.ts Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [patch] Error in reg-tests-1c.R (R-devel)
G'day Martin, On Wed, 18 May 2016 12:50:21 +0200 Martin Maechler wrote: > > Mikko Korpela > > on Wed, 18 May 2016 13:05:24 +0300 writes: > > > I get an error when running "make check" after building > > R-devel r70629 on Ubuntu 14.04. > > Here are the relevant > > lines in the file "reg-tests-1c.Rout.fail": [...] > This is ..hmm.. "interesting". We have a few other non-ASCII > characters in a few of the tests/*.R files and they don't seem to > harm your checks; even reg-tests-1c.R contains some. > > Also, the "Installation and Administration" R Manual mentions > that some of the tests only run flawlessly if you are not using > "unusual" locales. So I am a bit puzzled that exactly this > (new) test fails in your locale, but the others did not. [...] Well, my nightly script had also failed to complete due to the same problem. But I usually wait a day or two before reporting such a problem, in the hope that the problem sorts itself out. :) But to confirm this issue: * My (bash) script sets: export LANG=en_AU.UTF-8 * The crontab entry that runs it is: 44 5 * * * cd /opt/src ; /usr/bin/xvfb-run ./R-aop-Doit * The relevant part of reg-tests-1c.Rout.fail says: > ## m1z uses match(x, *) with length(x) == 1 and failed in R 3.3.0 > ## PR#16909 - a consequence of the match() bug; check here too: > dv <- data.frame(varé1 = 1:3, varé2 = 3); dv[,"varé2"] <- 2 Error: unexpected input in "dv <- data.frame(var�" Execution halted Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Problem compiling R patched and R devel on Ubuntu
G'day all, since about a week my daily re-compilations of R patched and R devel are falling over, i.e. they stop with an error during "make check" (while building the 32 bit architecture) on my Ubuntu 16.04.3 LTS machine. Specifically, a test in graphics-Ex.R seems to fail and the last lines of graphics-ex.Rout.fail are: > ## Extreme outliers; the "FD" rule would take very large number of 'breaks': > XXL <- c(1:9, c(-1,1)*1e300) > hh <- hist(XXL, "FD") # did not work in R <= 3.4.1; now gives warning Warning in hist.default(XXL, "FD") : 'breaks = 4.44796e+299' is too large and set to 1e9 Error in pretty.default(range(x), n = breaks, min.n = 1) : cannot allocate vector of length 11 Calls: hist -> hist.default -> pretty -> pretty.default Execution halted My R 3.4.1 installation, the last R patched version that I could compile (R version 3.4.1 Patched (2017-07-26 r72974)) and the last R devel version that I could compile (R Under development (unstable) (2017-07-26 r72974)) give the following results (under the 32bit architecture and the 64bit architecture): > XXL <- c(1:9, c(-1,1)*1e300) > hh <- hist(XXL, "FD") Error in pretty.default(range(x), n = breaks, min.n = 1) : invalid 'n' argument In addition: Warning message: In pretty.default(range(x), n = breaks, min.n = 1) : NAs introduced by coercion to integer range Not sure if this is a general problem, or only a problem on my machine. Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Trying to compile R 4.2.x on Linux as 32bit sub-architecture
G'day all,
On Sat, 18 Jun 2022 22:58:19 +0800
Berwin A Turlach wrote:
> [...] I attach the relevant file from trying to compile R-patched
> during last night's run.
Mmh, on the web-interface to the mailing list I see that the attachment
might have been deleted. Perhaps because it was too large?
So below the start and the final part from reg-tests-1d.Rout.fail which
shows where the error occurs.
Cheers,
Berwin
R version 4.2.1 RC (2022-06-17 r82501) -- "Funny-Looking Kid"
Copyright (C) 2022 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu/32 (32-bit)
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
> ## Regression tests for R >= 3.4.0
[...very large snip...]
> ## pretty(x) when range(x) is finite but diff(range(x)) is +/- Inf:
> B <- 1e308; 2*B; (s <- seq(-B,B,length.out = 3))
[1] Inf
[1] -1e+308 0e+00 1e+308
> options(warn=1) # => warnings *as they happen*
> (ps <- pretty(c(-B,B)))
[1] -1e+308 -5e+307 0e+00 5e+307 1e+308
> ## Warning in pretty.default(c(-B, B)) :
> ## Internal(pretty()): very large range 4e+307, corrected to 2.24712e+307
> nps <- length(ps)
> dd <- sum((dps <- diff(ps))/length(dps)) # mean w/o overflow
> epsC <- .Machine$double.eps
> relD <- (dps/dd - 1)/epsC
> relEr <- function(f, y) abs((f-y)/(f+y)*2) # cheap relative error, |f| > 0 !
> stopifnot(is.finite(mean(ps)), ## these all failed without "long-double"
+ is.finite(mdp <- mean(dps)),
+ all.equal(dd, mdp, tolerance=1e-15))
> stopifnot(relEr(c(-B,B), ps[c(1L,nps)]) <= 4*epsC,
+ -8 <= relD, relD <= 8) # seen [-1.5,.., 3.0]; w/o long-double: [-5,
.., 4]
> ## ps was 0 Inf Inf Inf Inf Inf Inf Inf Inf Inf 0 , in R <= 4.1.0
> f. <- c(-1.797, -1.79, -1.75, seq(-1.7, -1, by=.1))
> stopifnot(!is.unsorted(f.)) ; f.nm <- setNames(, f.)
> fmtRng <- function(x) paste(format(range(x)), collapse=", ")
> ns <- c(2:12, 15, 20, 30, 51, 100, 2001, 1e5)
> nms.n <- formatC(ns, digits=0, format="f")
> nmsRng <- c(t(outer(paste0("r",1:2), c("lo","hi"), paste, sep=".")))
> rr <- matrix(NA, length(ns), 4, dimnames=list(nms.n, nmsRng))
> for(i.n in seq_along(ns)) {
+ n <- ns[i.n]
+ cat("n = ", n,":\n\n")
+ pBL <- lapply(f., function(f) structure(pretty(c(f*1e308, 2^1023.9), n),
f=f))
+ ## -> a warning per f
+ n.s <- lengths(pBL) # how close to target 'n' ??
+ cat("lengths(.) in [", fmtRng(n.s), "]\n")
+ if(n <= 15) stopifnot(n.s <= 20)# seen {14,..,17}
+ else stopifnot(abs(n.s/n - 1) <= 1/2)
+ if(n) cat("length(.) <> n relative err in [", fmtRng(n.s/n - 1), "]\n")
+ ## .pretty(*, bounds=FALSE) :
+ prM <- t(sapply(f.nm, function(f)
+ unlist( .pretty(c(f*1e308, 2^1023.9), n, bounds=FALSE) )))
+ print(prM)
+ luM <- prM[,c("ns","nu")] * prM[,"unit"] # the pretty-scaled unit
+ r1 <- luM[,"ns"] / (f.nm*1e308)
+ rr[i.n, 1:2] <- r1 <- range(r1)
+ cat(sprintf("range(r1): [%g, %g]\n", r1[1], r1[2]))
+ r2 <- luM[,"nu"] / 2^1023.9
+ rr[i.n, 3:4] <- r2 <- range(r2)
+ cat(sprintf("range(r2): [%g, %g]\n", r2[1], r2[2]))
+ stopifnot(exprs = { is.matrix(prM)
+ prM[,"nu"] - prM[,"ns"] == prM[,"n"] # could differ, but not for
this data
+ identical(colnames(prM), c("ns", "nu", "n", "unit"))
+ ## These bounds depend on 'n' :
+ r1 >= if(n <= 12) 0.55 else 0.89
+ r1 <= if(n <= 15) 1.4 else 1.1
+ r2 >= if(n <= 12) 0.58 else 0.95
+ r2 <= if(n <= 15) 1else 1.025
+ })
+ invisible(lapply(pBL, function(ps) {
+ mdB <- sum((dB <- diff(ps))/length(dB))
+ rd <- dB/mdB - 1 # relative differences
+ ## print(range(rd))
+ x <- c(attr(ps,"f")*1e308, 2^1023.9)
+ stopifnot(if(n >= 1) abs(rd) <= n * 3e-15 else TRUE,
+ ps[1] <= x[1] , x[2] <= ps[length(ps)])
+ }))
+ }
Re: [Rd] A potential POSIXlt->Date bug introduced in r-devel
G'day all, On Thu, 6 Oct 2022 10:15:29 +0200 Martin Maechler wrote: > > Davis Vaughan > > on Wed, 5 Oct 2022 17:04:11 -0400 writes: > > # Weird, where is the `NA`? > > as.Date(x) > > #> [1] "2013-01-31" "1970-01-01" "2013-03-31" > > ``` > > I agree that the above is wrong, i.e., a bug in current R-devel. I have no intention of hijacking this thread, but I wonder whether this is a good opportunity to mention that the 32 bit build of R-devel falls over on my machine since 25 September. It fails one of the regression tests in reg-tests-1d.R. The final lines of reg-tests-1d.Rout.fail are: > tools::Rd2txt(rd, out <- textConnection(NULL, "w"), fragment = TRUE) > stopifnot(any(as.character(rd) != "\n"), + identical(textConnectionValue(out)[2L], "LaTeX")); close(out) > ## empty output in R <= 4.2.x > > > ## as.POSIXlt() gave integer overflow > stopifnot(as.POSIXlt(.Date(2^31 + 10))$year == 5879680L) Error: as.POSIXlt(.Date(2^31 + 10))$year == 5879680L is not TRUE Execution halted I should have reported this earlier, but somehow did not find the time to do so. So I thought I mention it here. :) Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] specials and ::
G'day Terry, On Mon, 26 Aug 2024 09:42:10 -0500 "Therneau, Terry M., Ph.D. via R-devel" wrote: [...] > I now get "bug reports" from the growing segment that believes one > should put packagename:: in front of every single instance. [...] > What are other's thoughts? Not that I want to start a flame war, or say anything controversial, but IMHO people who want to put packagename:: in front of every function do not understand S3 method dispatch and are just clutching at a comfort blanket that sets them up for failure. ;-) Admittedly, it is now quite a while back that I had the joy of debugging the following situation (but it happened at least twice in this millennium if memory serves correctly): * Author of package X relies on foo(bar) to be dispatched to foo.default(). * Author of package Y loads a zillion packages, one of which defines (and registers) a method foo.bar() * User first attaches package X and then package Y (well, order does not really matter). There is no warning about masked functions (why would there be?) or anything else. * User calls function in package X that relies on foo(bar) to be dispatched to foo.default(), but it is now dispatched to foo.bar(). * foo.bar() returns something different to foo.default() on an object of class bar and, hence, all hell breaks lose in the function in package X that used the call foo(bar). And you can put packagename:: in front of every function call in package X (and Y and Z &c) until the cows come home and it would not avoid this problem. Sorry, but except if the "put package:: in front of every function" crowd does not also start advocating that generics are not be used but rather the desired method be called directly, I don't think they can be taken seriously. Just my 0.02 (Australian of course). Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] specials and ::
G'day Terry, On Mon, 26 Aug 2024 09:42:10 -0500 "Therneau, Terry M., Ph.D. via R-devel" wrote: [...] > I now get "bug reports" from the growing segment that believes one > should put packagename:: in front of every single instance. [...] > What are other's thoughts? Not that I want to start a flame war, or say anything controversial, but IMHO people who want to put packagename:: in front of every function do not understand S3 method dispatch and are just clutching at a comfort blanket that sets them up for failure. ;-) Admittedly, it is now quite a while back that I had the joy of debugging the following situation (but it happened at least twice in this millennium if memory serves correctly): * Author of package X relies on foo(bar) to be dispatched to foo.default(). * Author of package Y loads a zillion packages, one of which defines (and registers) a method foo.bar() * User first attaches package X and then package Y (well, order does not. There is no warning about masked functions (why would there be?) or anything else. * User calls function in package X that relies on foo(bar) to be dispatched to foo.default(), but it is now dispatched to foo.bar(). * foo.bar() returns something different to foo.default() on an object of class bar and, hence, all hell breaks lose in the function in package X that used the call foo(bar). And you can put packagename:: in front of every function call in package X (and Y and Z &c) until the cows come home and it would not avoid this problem. Sorry, but except if the "put package:: in front of every function" crowd does not also start advocating that generics are not be used but rather the desired method be called directly, I don't think they can be taken seriously. Just my 0.02 (Australian of course). Cheers, Berwin [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Fortran BLAS giving bad results
G'day Emmanuel,
On Sat, 11 Jan 2014 14:08:41 -0800
Emmanuel Sharef wrote:
> Example: this program creates two double vectors, takes the dot
> product with ddot, and prints the result:
>
> test.f:
> subroutine testddot(n,x,y)
> integer i,n
> double precision x,y,d1(n),d2(n)
> do 100 i=1,n
> d1(i)=x
> d2(i)=y
> 100 continue
> print *,ddot(n,d1,1,d2,1)
> end
>
> Compiling
> R CMD SHLIB test.f
Mmh, FORTRAN77 does not have dynamical memory allocation (though I have
been told that many compilers implement it as an extension to the
standard). So I am surprised that this code works. It is certainly
not portable (i.e. a compiler that implements the FORTRAN77 standard
strictly would barf on this code).
Also, output to * in FORTRAN code dynamically linked to R is
discouraged, see chapter 5.7 (Fortran I/O) in the "Writing R Extension"
manual. From memory, many years ago one could do so (on linux and
SUN machines atleast), then it stopped working. I am surprised that it
works again.
But neither of these two issues are the reason for your strange
results. You would have pinpointed your actual problem easily if you
would have used my favourite none-FORTRAN77 feature (which is
implemented by most compilers as an extension), namely having "implicit
none" as the first line in each function/subroutine. (The FORTRAN77
compliant version, AFAIK, was to write "IMPLICIT CHARACTER (A-Z)" into
the first line of all functions/subroutines.)
Essentially, your routine testddot does not know what kind of result
ddot returns and by the implicit type definition rules of FORTRAN77 it
expects an INTEGER back. The fact that a DOUBLE PRECISION value is
returned when an INTEGER is expected creates some confusion. Somewhere
at the start of your routine you have to add a "DOUBLE PRECISION ddot"
statement.
HTH.
Cheers,
Berwin
== Full address
A/Prof Berwin A Turlach Tel.: +61 (8) 6488 3338 (secr)
School of Maths and Stats (M019)+61 (8) 6488 3383 (self)
The University of Western Australia FAX : +61 (8) 6488 1028
35 Stirling Highway
Crawley WA 6009 e-mail: berwin.turl...@gmail.com
Australiahttp://www.maths.uwa.edu.au/~berwin
http://www.researcherid.com/rid/A-4995-2008
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN: How to list a non-Sweave doc under "Vignettes:" on package page?
G'day Henrik, On Sun, 6 Nov 2011 16:41:22 -0800 Henrik Bengtsson wrote: > is it possible to have non-Sweave vignettes(*) in inst/doc/ be listed > under 'Downloads' on CRAN package pages? As far as I know, only by a little trick. Create an Sweave based vignette that uses the pdfpages package to include the .pdf file that you want to have listed. This dummy vignette should then be listed on CRAN. See the lasso2 package for an example. The vignette in inst/doc/ in that package is actually a bit more complicated than necessary. As I think there is no point of having two nearly identical copies of PDF files in a package, I use .buildignores to have the original PDF file not included in the source package. This started to create a problem when R decided to rebuild vignettes during the checking process and pdfpages decided to hang if the PDF file to be included was missing. HTH. Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Changed behaviour of 'R CMD INSTALL'
G'day all, I found the following snippet in the NEWS file for R 2.14.1: • R CMD INSTALL will now do a test load for all sub-architectures for which code was compiled (rather than just the primary sub-architecture). This seems to have the following (unintended?) consequence: Most of my machines are running some version of 64-bit Ubuntu and I do not necessarily have all 32-bit libraries installed on these. In particular, the 32-bit TCL/Tk libraries are frequently missing. Thus, on such a machine the 32-bit sub-architecture of R does not have the capability to use TCL/tk and the tcltk package is only installed for the primary sub-architecture (64-bit). Until now, I could always install the Rcmdr package on these machine. However, this is no longer possible in 2.14.1. Now attempts to install Rcmdr on such a machine ends with: ** testing if installed package can be loaded *** arch - 32 Error : package 'tcltk' is not installed for 'arch=32' Error: loading failed Execution halted *** arch - 64 ERROR: loading failed for '32' * removing '/home/opt/R/R-2.14.1/lib64/R/library/Rcmdr' Is there a way of installing Rcmdr only for the 64-bit primary sub-architecture? Or do I really have to install the 32-bit versions of the TCL/Tk libraries and then reinstall R from scratch? Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Changed behaviour of 'R CMD INSTALL'
G'day Simon, On Wed, 11 Jan 2012 08:53:27 -0500 Simon Urbanek wrote: > try --no-multiarch Thanks, works perfectly. And now I notice that this option is given as an example in the help file for install.packages() as a possible value that one wants to pass to 'R CMD INSTALL'. Could kick myself. Well, it is always easier to find something when one knows what one is looking for... :) Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] nobs() and logLik()
Dear all, I am studying a bit the various support functions that exist for extracting information from fitted model objects. >From the help files it is not completely clear to me whether the number returned by nobs() should be the same as the "nobs" attribute of the object returned by logLik(). If so, then there is a slight inconsistency in the methods for 'nls' objects with logLik.nls() taking zero weights into account while nobs.nls() does not. Admittedly, the help page of nobs() states that: For 'lm' and 'glm' fits, observations with zero weight are not included. i.e. does not comment on what nls does. But I wonder whether the following behaviour is desirable: R> DNase1 <- subset(DNase, Run == 1) R> fm3DNase2 <- nls(density ~ Asym/(1 + exp((xmid - log(conc))/scal)), + data = DNase1, weights=c(0,rep(1,14),0), + start = list(Asym = 3, xmid = 0, scal = 1)) R> nobs(fm3DNase2) [1] 16 > logLik(fm3DNase2) 'log Lik.' 42.62777 (df=4) > nobs(logLik(fm3DNase2)) [1] 14 Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] nobs() and logLik()
G'day Brian, On Fri, 20 Jan 2012 06:20:30 + Prof Brian Ripley wrote: > I do wonder why people use zero weights rather than 'subset', and I > don't particularly like the discontinuity as a weight goes to zero. I completely agree, and for developers it is a bit of a pain to make sure that all possible combinations of 'subset' and 'weights' play "nicely" together. One reason that I can see for people to use zero weights rather than 'subset' is that fitted() and predict() in the former case readily produce fitted values for the observations that received a zero weight. Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Calling FORTRAN function from R issue?
G'day Dominick,
On Mon, 5 Mar 2012 19:21:01 -0500
Dominick Samperi wrote:
> Section 5.2 of the R manual (on Extending R) says that only
> FORTRAN subroutines can be called (not functions), probably
> because of the non-standard way the compilers map FORTRAN
> function names to symbols in the DLL.
Section 5.2 deals with calling C/FORTRAN code from R via .C()
or .Fortran(), and is not directly relevant to the question on how to
call FORTRAN code from C code. :)
> This is consistent with the interface prototype for the BLAS
> routine zdotc contained in /include/R_ext/BLAS.h, namely,
>
> BLAS_extern Rcomplex
> F77_NAME(zdotc)(Rcomplex * ret_val, int *n,
> Rcomplex *zx, int *incx, Rcomplex *zy, int *incy);
>
>[...]
>
> On the other hand, this is not consistent with the standard
> FORTRAN definition for zdotc that is contained in
> /src/extra/blas/cmplxblas.f, where the first argument is
> n, not ret_val.
This seems to be indeed inconsistent and, presumably, a bug. Applying
the attach patch to R's development version (compiles, installs and
passes all checks with this patch), and changing in your code the line
F77_CALL(zdotc)(&ret_val, &n, zx, &incx, zy, &incy);
to
ret_val = F77_CALL(zdotc)(&n, zx, &incx, zy, &incy);
produces the expected output.
> Consequently, it is not clear where the wrapper
> is defined that is called via the prototype.
The F77_ macros seem to be defined in /include/R_ext/RS.h, and
their sole purpose seems to be to append a _ to the argument if
needed.
Cheers,
Berwin
Index: src/include/R_ext/BLAS.h
===
--- src/include/R_ext/BLAS.h(revision 58604)
+++ src/include/R_ext/BLAS.h(working copy)
@@ -245,10 +245,10 @@
F77_NAME(zcopy)(int *n, Rcomplex *zx, int *incx,
Rcomplex *zy, int *incy);
BLAS_extern Rcomplex
-F77_NAME(zdotc)(Rcomplex * ret_val, int *n,
+F77_NAME(zdotc)(int *n,
Rcomplex *zx, int *incx, Rcomplex *zy, int *incy);
BLAS_extern Rcomplex
-F77_NAME(zdotu)(Rcomplex * ret_val, int *n,
+F77_NAME(zdotu)(int *n,
Rcomplex *zx, int *incx, Rcomplex *zy, int *incy);
BLAS_extern void
F77_NAME(zdrot)(int *n, Rcomplex *zx, int *incx, Rcomplex *zy,
Index: doc/manual/R-exts.texi
===
--- doc/manual/R-exts.texi (revision 58604)
+++ doc/manual/R-exts.texi (working copy)
@@ -12229,7 +12229,7 @@
The @R{} for Windows installers have for a long time allowed the value
of @code{R_HOME} to be recorded in the Windows Registry: this is
-optional but selected by default. @emph{Where} is it is recorded has
+optional but selected by default. @emph{Where} it is recorded has
changed over the years to allow for multiple versions of @R{} to be
installed at once, and to allow 32- and 64-bit versions of @R{} to be
installed on the same machine.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Calling FORTRAN function from R issue?
G'day Berend,
On Tue, 6 Mar 2012 11:19:07 +0100
Berend Hasselman wrote:
> On 06-03-2012, at 01:21, Dominick Samperi wrote:
[...]
> >zx[0].r = 1.0; zx[0].i = 0.0;
> >zx[1].r = 2.0; zx[0].i = 0.0;
> >zx[2].r = 3.0; zx[0].i = 0.0;
Just noticing that it is always zx[0].i, same with the imaginary part
of zy. But this is probably not of importance. :)
> I tried calling zdotc through an intermediate Fortran routine hoping
> it would solve your problem.
[...]
> Above C routine changed to
[...]
> The fortran subroutine is
>
>
> subroutine callzdotc(retval,n, zx, incx, zy, incy)
> integer n, incx, incy
> double complex retval, zx(*), zy(*)
> external double complex zdotc
>
> retval = zdotc(n, zx, incx, zy, incy)
>
> return
> end
>
>
> Made a shared object with
>
> R CMD SHLIB --output=dozdot.so callzdotc.f czdot.c
>
> and ran
>
> dyn.load("dozdot.so")
> .C("testzdotc")
>
> with the result 0.0, 0.0
Same here.
Once I change the line
external double complex zdotc
in your fortran subroutine to
double complex zdotc
everything works fine and I get as result 14.0, 0.0.
It is long time ago that I was taught (and studied) the FORTRAN 77
standard. But flipping through some books from that time I thing I
have some inkling on what is going on. The "external" statement is not
needed here (seems to be used in the sense that C is using the
"external" statement).
Cheers,
Berwin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Calling FORTRAN function from R issue?
G'day Berend, On Tue, 6 Mar 2012 13:06:34 +0100 Berend Hasselman wrote: [... big snip ...] > But I would really like to hear from an Rexpert why you > shouldn't/can't use external here in the Fortran. Probably less a question for an Rexpert but for a Fortran expert If you insert "implicit none" (one of my favourite extensions that I always use) as the first statement after subroutine callzdotc(retval,n, zx, incx, zy, incy) you will see what is going on. The compiler should refuse compilation and complain that the type of zdotc was not declared (at least my compiler does). For FORTRAN to know that zdotc returns a double complex you need the double complex zdotc declaration in callzdotc. An external double complex zdotc would be necessary if you were to call another subroutine/function, say foo, that accepts functions as formal arguments and you want to pass zdotc via such an argument. Something like subroutine callzdotc() external double complex zdotc call foo(a, b, zdotc) return end subroutine(a, b, h) double complex h, t t = h(..,..,..,..) return end In C, the qualifier (or whatever the technical term is) "external" is used to indicate that the function/variable/symbol is defined in another compilation unit. In FORTRAN77, "external" is used to tell the compiler that you are passing a function to another function/subroutine. At least that is my understanding from what I re-read in my FORTRAN documentation. Thus, perhaps strangely, if there is only a external double complex zdotc declaration in your subroutine, the compiler doesn't know that a call to zdotc will return a double complex but will assume that the result has the implicitly defined type, a real*8 IIRC. So zdotc is called, and puts a double complex as result on the stack (heap?), but within callzdotc a real as return is expected and that is taken from the stack (heap?), that real is than coerced to a double complex when assigned to retval. Note that while I am pretty sure about the above, this last paragraph is more speculative. :) But it would explain why the erroneous code returns 0 on little-endian machines. HTH. Cheers, Berwin Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Recommended way to call/import functions from a Suggested package
G'day David,
On Fri, 22 Feb 2013 18:50:07 -0800
David Winsemius wrote:
> On Feb 22, 2013, at 6:39 PM, David Winsemius wrote:
[...]
> > I've always wondered: How does lattice manage to use grid functions
> > without putting them on the search path?
Because lattice imports the grid package and has a NAMESPACE (as have
all packages nowadays):
R> packageDescription("lattice")
Package: lattice
Version: 0.20-10
Date: 2012/08/21
[...]
Suggests: grid, KernSmooth, MASS
Imports: grid, grDevices, graphics, stats, utils, methods
[...]
And the relevant information is not in the "Writing R Extensions"
manual but in section 3.5.4 of the "R Language Definition" manual:
Packages which have a @emph{namespace} have a different search
path. When a search for an @R{} object is started from an
object in such a package, the package itself is searched first,
then its imports, then the base namespace and finally the
global environment and the rest of the regular search path.
The effect is that references to other objects in the same
package will be resolved to the package, and objects cannot be
masked by objects of the same name in the global environment or
in other packages.
Thus, as grid is imported by lattice, it is loaded but not attached
(i.e. does not appear in the search path). However, function in the
lattice package will find functions in the grid package as the imports
are searched.
> Neither can the R interpreter find it. But it's clearly available if
> you ask nicely:
>
> > grid::grid.text
This will always work, whether the grid package is loaded/attached or
not:
R> sessionInfo()
R version 2.15.2 (2012-10-26)
Platform: x86_64-unknown-linux-gnu/64 (64-bit)
locale:
[1] C
attached base packages:
[1] stats graphics grDevices utils dataset methods base
loaded via a namespace (and not attached):
[1] tools_2.15.2
R> grid::grid.text
function (label, x = unit(0.5, "npc"), y = unit(0.5, "npc"),
just = "centre", hjust = NULL, vjust = NULL, rot = 0, check.overlap =
FALSE,
default.units = "npc", name = NULL, gp = gpar(), draw = TRUE,
vp = NULL)
{
tg <- textGrob(label = label, x = x, y = y, just = just,
hjust = hjust, vjust = vjust, rot = rot, check.overlap = check.overlap,
default.units = default.units, name = name, gp = gp,
vp = vp)
if (draw)
grid.draw(tg)
invisible(tg)
}
You specifically asked R to get object grid.text from the grid
package, so R obliges to do so. For the help system to find the help
pages on an object, the package that contains the help pages has to be
on the search path AFAIK.
Cheers,
Berwin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD config for R >= 3.0.1
Dear all,
When installing the usual packages that I use, after installing R
3.0.1, I noticed that the installation of some packages that query R about
its configuration did not succeed. The problem is exemplified by:
berwin@bossiaea:~$ R-3.0.1 CMD config CC
/opt/R/R-3.0.1/lib/R/bin/config: 222: .: Can't open
/opt/R/R-3.0.1/lib/R/etc/Renviron
Prior to R 3.0.1 such commands worked fine:
berwin@bossiaea:~$ R-3.0.0 CMD config CC
gcc -std=gnu99
I noticed now that my installations of the development and
patched version of R have the same problem (since I usually do not install
packages in those versions that query the configuration, I hadn't
noticed the issue earlier).
The problem seems to be line 222 of `R RHOME`/bin/config (when R is R
3.0.1) which reads:
. ${R_HOME}/etc/Renviron
The file ${R_HOME}/etc/Renviron does not necessarily exists if one has
opted for 32/64-bit builds and installed both as sub-architectures,
which I have. In my installation ${R_HOME}/etc/32/Renviron and
${R_HOME}/etc/64/Renviron exist, but no ${R_HOME}/etc/Renviron.
Is it necessary for R >= 3.0.1 to have one build as
"main"-architecture and the other one as sub-architecture? I could not
find anything in the NEWS file or the Admin manual that indicated that
this would now be necessary.
Cheers,
Berwin
For completeness:
I am running an Ubuntu 12.04 system and:
berwin@bossiaea:~$ echo "sessionInfo()" | R-3.0.1 --slave
R version 3.0.1 (2013-05-16)
Platform: x86_64-unknown-linux-gnu/64 (64-bit)
locale:
[1] C
attached base packages:
[1] stats graphics grDevices utils datasets methodsbase
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD config for R >= 3.0.1
G'day Brian,
On Sat, 18 May 2013 10:28:43 +0100
Prof Brian Ripley wrote:
[...]
> > Is it necessary for R >= 3.0.1 to have one build as
> > "main"-architecture and the other one as sub-architecture? I could
> > not find anything in the NEWS file or the Admin manual that
> > indicated that this would now be necessary.
>
> Not exclusively, but as the Mac build no longer uses this, we do need
> people who do to test pre-releases. One of us needs to build such a
> setup and test it
Either that, or amend the administration and installation manual to
state that one installation should not be a sub-architecture
installation. :)
But the latter solution also seems to have some problems. My usual
install script did the following:
1) Run ./configure with 'r_arch=32' (and a few other options) using a
config.site, configured for a 32bit build; followed by make
2) make check ; make install
3) `make distclean'; run ./configure with 'r_arch=64' (and a few other
options using a config.site configured for a 64 bit build; followed
by make
4) make check ; make install
5) make pdf info; make install-pdf install-info
When trying to install Rgraphviz afterwards (mmh, this is a
BioConductor package and not a CRAN package, so perhaps I should ask on
their lists?), Rgrahviz couldn't find the correct compiler settings as
"R CMD config ..." did not work (as reported originally).
So I changed my install script to remove the 'r_arch=64' in step 3.
(The modified script is attached.) But now, trying to install
Rgraphviz falls over earlier when a dependencies of Rgraphviz,
BiocGenerics, is installed. Trying to install BiocGenerics fails with:
[...]
** help
*** installing help indices
** building package indices
** testing if installed package can be loaded
*** arch - 32
*** arch - R
ERROR: sub-architecture 'R' is not installed
ERROR: loading failed for 'R'
* removing '/opt/R/R-3.0.1/lib/R/library/BiocGenerics'
I have no idea why the process tries to check for an 'arch - R'. But
this seems to be happening for packages that do not contain code that
needs to be compiled, another example is 'car' which is needed by 'AER'.
So I am bit puzzled how I should change my scripts. Does step 3 needs
something stronger than 'make distclean'? Or should the 'r_arch=32' be
dropped in step 1 but step 3 should use 'r_arch=64'?
Essentially, I would like to install 32bit and 64bit builds on my
machines, with one or both as sub-architectures (to save space) and
with the 64bit the 'default', i.e. the one that is run by
${R_HOME}/bin/R.
Cheers,
Berwin
#!/bin/bash -e
VERSION=3.0.1
part1a ()
{
cd /opt/src/R-$VERSION
echo "**"
echo "*** configure (32bit) "
echo "**"
cp ../R-config.site-32 config.site
./configure --prefix=/opt/R/R-$VERSION --with-blas --with-lapack
--enable-R-shlib r_arch=32 | tee CONFIGURE_32
echo "*"
echo "*** make (32 bit)"
echo "*"
make -j6
}
part2()
{
echo "*"
echo "*** make check "
echo "*"
make check
make install
}
part1b ()
{
echo "**"
echo "*** configure (64bit) "
echo "**"
make distclean
cp ../R-config.site-64 config.site
./configure --prefix=/opt/R/R-$VERSION --with-blas --with-lapack
--enable-R-shlib | tee CONFIGURE_64
echo "*"
echo "*** make (64 bit)"
echo "*"
make -j6
}
part3 ()
{
echo "**"
echo "*** make documentation"
echo "**"
make pdf info
make install-pdf install-info
}
export http_proxy=http://proxy.uwa.edu.au:
export LANG=en_AU.UTF-8
echo "Installing R-$VERSION"
part1a > /opt/src/R-$VERSION-LOG 2>&1
part2 > /opt/src/R-$VERSION-CheckLOG 2>&1
part1b >> /opt/src/R-$VERSION-LOG 2>&1
part2 >> /opt/src/R-$VERSION-CheckLOG 2>&1
part3 >> /opt/src/R-$VERSION-LOG 2>&1
echo "Done"
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD config for R >= 3.0.1
G'day Brian, On Sun, 19 May 2013 08:40:04 +0100 Prof Brian Ripley wrote: > Could you try current R-patched or R-devel? Works in my tests at > least. Tried R-patched (2013-05-18 r62762) and R-devel (2013-05-18 r62762), installed with my original script. Things seem fine when I try to install my usual selection of packages in either of those versions. Loading under correct (and existing) architectures is tested and packages that query the configuration get the correct answers from `R CMD config'. Thank you very much for the help. Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] inconsistency in ?factor
G'day Petr,
On Mon, 25 May 2009 09:04:14 +0200
Petr Savicky wrote:
> The first formulation "Be careful to compare ... levels in the same
> order" may be just a warning against a potential problem if the
> levels have different order, however this is not clear.
Well, the first statement is a remark on comparison in general while
the second statement is specific to "comparison operators and generic
methods". There are other ways of comparing objects; note:
R> f1 <- factor(c("a", "b", "c", "c", "b", "a"), levels=c("a", "b", "c"))
R> f2 <- factor(c("a", "b", "c", "c", "b", "a"), levels=c("c", "b", "a"))
R> f1==f2
[1] TRUE TRUE TRUE TRUE TRUE TRUE
R> identical(f1,f2)
[1] FALSE
R> all.equal(f1,f2)
[1] "Attributes: < Component 2: 2 string mismatches >"
Just my 2c.
Cheers,
Berwin
=== Full address =
Berwin A TurlachTel.: +65 6516 4416 (secr)
Dept of Statistics and Applied Probability+65 6516 6650 (self)
Faculty of Science FAX : +65 6872 3919
National University of Singapore
6 Science Drive 2, Blk S16, Level 7 e-mail: sta...@nus.edu.sg
Singapore 117546http://www.stat.nus.edu.sg/~statba
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] build, data and vignettes
G'day Uwe, On Fri, 26 Feb 2010 17:03:10 +0100 Uwe Ligges wrote: > R CMD check executes the R code in the vignettes and checks if that > works, and it checks if the PDFs are available. It does not check if > it can build the vignettes, because that is only necessary on the > maintainer's machine since the PDFs are shipped with the (built) > source package. Are you implying that "R CMD check" has reverted to its pre-2.6.0 behaviour? If I remember correctly, for R versions before 2.6.0 "R CMD check" did not attempt to build the vignette, with version 2.6.0 it started to do so. The relvant NEWS entry is: o R CMD check now (by default) attempts to latex the vignettes rather than just weave and tangle them: this will give a NOTE if there are latex errors. Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] LOGICAL arguments in FORTRAN code
G'day all, I just took over maintenance of the quadprog package from Kurt Hornik and noticed that one of the FORTRAN routines has an argument that is declared to be a LOGICAL. The R code that calls this routine (via the .Fortran interface) passes the argument down wrapped in a call to as.logical(). This was fine (and as documented) under S-Plus 3.4, for which this code was originally developed. However, as far as I know, in R objects of storage mode logical were always supposed to be passed to FORTRAN arguments of type INTEGER; and that is what the current "Writing R extension manual states". Thus, given that the port of quadprog existed for quite some time, I am wondering whether it is o.k. to pass R objects with storage mode logical into FORTRAN code to arguments declared as LOGICAL? Or should the FORTRAN code be corrected to declare the argument in question as INTEGER? Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] LOGICAL arguments in FORTRAN code
G'day Brian, On Thu, 8 Apr 2010 12:40:45 +0100 (BST) Prof Brian Ripley wrote: > On Thu, 8 Apr 2010, Berwin A Turlach wrote: [...] > > Thus, given that the port of quadprog existed for quite some time, I > > am wondering whether it is o.k. to pass R objects with storage mode > > logical into FORTRAN code to arguments declared as LOGICAL? Or > > should the FORTRAN code be corrected to declare the argument in > > question as INTEGER? > > The second to be safe. [...] Thanks for the quick and informative response. I will make the necessary changes. BTW, can I assume that if R passes down TRUE to the FORTRAN routine the corresponding integer argument will be set to 1, and that it will be set to zero if FALSE is passed down? Likewise, can I assume that if at the end of the FORTRAN routine the integer holds a value of zero, then FALSE is passed back to R and if the integer holds any other value then TRUE is passed back? I don't remember ever reading any documentation about this; and most documentation that I would search is not at hand but back on the bookshelves of my office. Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bugs? when dealing with contrasts
tment" "contr.poly"
> > model.matrix(lm(seq(15) ~ fac, contrasts = c("contr.sum",
> > "contr.poly")))
>(Intercept) fac2 fac3
> 1100
> 2100
> 3100
> 4100
> 5100
> 6110
> 7110
> 8110
> 9110
> 10 110
> 11 101
> 12 101
> 13 101
> 14 101
> 15 101
> attr(,"assign")
> [1] 0 1 1
> attr(,"contrasts")
> attr(,"contrasts")$fac
> [1] "contr.treatment"
No bug either, but wrong use of the optional argument "contrasts" for
"lm". Please read the help page of "lm", which points you to the help
page of "model.matrix.default", which contains pertinent examples; in
your case:
R> model.matrix(lm(seq(15) ~ fac, contrasts = list(fac="contr.sum")))
(Intercept) fac1 fac2
1110
2110
3110
4110
5110
6101
7101
8101
9101
10 101
11 1 -1 -1
12 1 -1 -1
13 1 -1 -1
14 1 -1 -1
15 1 -1 -1
attr(,"assign")
[1] 0 1 1
attr(,"contrasts")
attr(,"contrasts")$fac
[1] "contr.sum"
HTH.
Cheers,
Berwin
== Full address
Berwin A Turlach Tel.: +61 (8) 6488 3338 (secr)
School of Maths and Stats (M019)+61 (8) 6488 3383 (self)
The University of Western Australia FAX : +61 (8) 6488 1028
35 Stirling Highway
Crawley WA 6009e-mail: ber...@maths.uwa.edu.au
Australiahttp://www.maths.uwa.edu.au/~berwin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Indexing bug?
G'day Duncan, On Wed, 26 May 2010 05:57:38 -0400 Duncan Murdoch wrote: > Is this expected behaviour? Yes, according to the answer that this poster https://stat.ethz.ch/pipermail/r-devel/2008-March/048674.html got. Indeed, the help page of '[' states: The index object i can be numeric, logical, character or empty. Indexing by factors is allowed and is equivalent to indexing by the numeric codes (see factor) and not by the character values which are printed (for which use [as.character(i)]). Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] ?mean
G'day Gabor, On Thu, 25 Jan 2007 09:53:49 -0500 "Gabor Grothendieck" <[EMAIL PROTECTED]> wrote: > The help page for mean does not say what happens when one > applies mean to a matrix. Well, not directly. :-) But the help page of mean says that one of the arguments is: x: An R object. Currently there are methods for numeric data frames, numeric vectors and dates. A complex vector is allowed for 'trim = 0', only. And the `Value' section states: For a data frame, a named vector with the appropriate method being applied column by column. If 'trim' is zero (the default), the arithmetic mean of the values in 'x' is computed, as a numeric or complex vector of length one. If any argument is not logical (coerced to numeric), integer, numeric or complex, 'NA' is returned, with a warning. Since a matrix is a vector with a dimension attribute, and not a data frame, one can deduce that the second paragraph describes the return value for `mean(x)' when x is a matrix. As I always tell my students, reading R help pages is a bit of an art. :) > mean and sd work in an inconsistent way on a matrix so that should at > least be documented. Agreed. But it is documented in the help page of sd, which clearly states: [] If 'x' is a matrix or a data frame, a vector of the standard deviation of the columns is returned. I guess you also want to have it documented in the mean help page? But then, should `var' also be mentioned in the mean help page? This command also work in an a different and inconsistent manner to mean on matrices. And, of course, there are other subtle inconsistencies in the language used in these help pages. Note that the mean help page talks about "numeric data frames" while the help pages of `var' and `se' talk about "data frames" only, though all components of the data frame have to be numeric, of course. > Also there should be a See Also to colMeans since that provides the > missing column-wise analog to sd. That's probably a good idea. What would you suggest should be mentioned to provide the column-wise analog of `var'? Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Solve.QP
G'day Serge,
On Thu, 6 Dec 2007 13:34:58 +0100
"de Gosson de Varennes Serge (4100)"
<[EMAIL PROTECTED]> wrote:
> I have a major problem (major for me that is) with solve.QP and I'm
> new at this. You see, to solve my quadratic program I need to have
> the lagrange multipliers after each iteration. Solve.QP gives me the
> solution, the unconstrained solution aswell as the optimal value.
> Does anybody have an idea for how I could extract the multipliers?
You could calculate them. For the quadratic program
min 1/2 x'Dx - d'x such that A'x >= b
the KKT conditions are:
( D -A) (x) = (d)
( A' 0) (l) = (b)
plus the complementary conditions. solve.QP tells you the solution x*
and which constraints are active. If A* is the submatrix of A that
contains only those columns of A that correspond to active constraints
at the solution, then the first line in the above set of equations
imply that the corresponding Lagrange multiplier l* fulfill the
equations:
D x* - A* l* = d --> l* = (A*' A*)^{-1} A*'(D x* - d)
all other Lagrange multiplier would be zero.
Thus, using the example from the help page and expanding it, the
following code should calculate the Lagrange multipliers:
Dmat <- matrix(0,3,3)
diag(Dmat) <- 1
dvec <- c(0,5,0)
Amat <- matrix(c(-4,-3,0,2,1,0,0,-2,1),3,3)
bvec <- c(-8,2,0)
res <- solve.QP(Dmat,dvec,Amat,bvec=bvec)
xst <- res$solution
tmp <- Dmat %*% xst -dvec
Ast <- Amat[,res$iact]
ll <- solve(crossprod(Ast,Ast), crossprod(Ast, tmp))
## a small check
cbind(tmp, Ast %*% ll)
lagr <- rep(0, ncol(Amat))
lagrange[res$iact] <- ll
lagrange
[1] 0.000 0.2380952 2.0952381
Alternatively, somewhere down in the FORTRAN code the Lagrange
multipliers are actually calculated. About 4 years ago somebody asked
me about this and he could locate where they are calculated. He
modified the FORTRAN code and the R code such that the Lagrange
multipliers would be returned too. Curiously, he sent the modified
code to me and not to the package maintainer, but I had no time at that
moment to check his modification, so I never passed anything on to the
package maintainer either. But if you are interested in modifying the
FORTRAN and R code and recompile the package yourself, I can see if I
can find that code.
I still think that this package should be worked over by someone with a
better understanding of the kind of fudges that do not come back to
bite and of finite precision arithmetic than the original author's
appreciation of such issues when the code was written. ;-)) Given
Bill's recent comments on r-help, I wonder whether this package is one
of those on his list of downright dangerous packages. LOL.
Hope this helps.
Cheers,
Berwin
=== Full address =
Berwin A TurlachTel.: +65 6516 4416 (secr)
Dept of Statistics and Applied Probability+65 6516 6650 (self)
Faculty of Science FAX : +65 6872 3919
National University of Singapore
6 Science Drive 2, Blk S16, Level 7 e-mail: [EMAIL PROTECTED]
Singapore 117546http://www.stat.nus.edu.sg/~statba
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 0.45<0.45 = TRUE (PR#10744)
On Tue, 12 Feb 2008 15:47:56 +0100 Gabor Csardi <[EMAIL PROTECTED]> wrote: > OMG, not again please! > > FAQ 7.31. Yeah, there seems to be a cluster of that type of questions at the moment. Perhaps it is time to introduce a global option "HaveReadFAQ7.31" whose default is "FALSE" but can be changed via the normal mechanism to "TRUE". Any comparison of numeric values/vectors should print a warning message "You are comparing numbers calculated using finite precision arithmetic, have you read FAQ 7.31." while the value of this option is FALSE. Perhaps that will help. :) Cheers, Berwin ======= Full address = Berwin A TurlachTel.: +65 6516 4416 (secr) Dept of Statistics and Applied Probability+65 6516 6650 (self) Faculty of Science FAX : +65 6872 3919 National University of Singapore 6 Science Drive 2, Blk S16, Level 7 e-mail: [EMAIL PROTECTED] Singapore 117546http://www.stat.nus.edu.sg/~statba __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] On Section 2.5:Sub-architectures in the R Installation and Administration manual
Dear all,
there are a few issues regarding Section 2.5: Sub-architectures in the
R Installation and Administration manual (referring to Version 2.6.2)
that I would like to raise:
1.) The manual states:
@code{R CMD INSTALL} will detect if more that one build is installed
and try to install packages with the appropriate library objects
for each. This will not be done if the package has an executable
@code{configure} script or a @file{src/Makefile} file. In such
cases you can install for extra builds by
@example
R [EMAIL PROTECTED] CMD INSTALL --libs-only @var{pkg}(s)
@end example
My experience with the --libs-only flag is that if the installation of
the package fails, then the package is removed. Is this really desired
behaviour? If yes, then the manual should perhaps warn that this might
happen. However, in my opinion, this behaviour is undesirable. As I
understand it, `--libs-only' would only be used if the package was
already successfully installed for (at least) one sub-architecture.
Why should the failure to install it for another sub-architecture
remove the complete package, including the successful build for another
sub-architecture.
2.) On my machines (running Kubuntu Linux (gutsy)), I usually install a
32 bit version, by specifying r_arch=32 to the configure line, and a 64
version, by specifying r_arch=64 to the configure line. This seems to
be in line with the following recommendation in the manual:
If you want to mix sub-architectures compiled on different
platforms (for example @cputype{x86_64} Linux and @cputype{i686}
Linux), it is wise to use explicit names for each, and you may
also need to set @option{libdir} to ensure that they
install into the same place.
However, after installing R 2.6.2 in such manner, trying to start R
resulted in the following error message:
Error: R executable not found
As far as I can tell, this is due to the code that was added at the
beginning of the bash script R (to support parallel 32/64-bit
installations using multilib on Linux?) which tries to locate the R
executable but does not search deep enough into the directory structure
if multiple architectures are installed using the r_arch option to the
configure line (for both/all architectures).
3) The manual also states in that section:
On Linux, there is an alternative mechanism for mixing 32-bit and
64-bit libraries known as @emph{multilib}. If a Linux distribution
supports multilib, then parallel builds of @R{} may be installed in
the sub-directories @file{lib} (32-bit) and @file{lib64} (64-bit).
[...]
As far as I can tell, Kubuntu Linux distributions support multilib.
However on these distributions /lib64 and /usr/lib64 are links to /lib
and /usr/lib, respectively, where the 64-bit libraries reside and the
32-bit libraries reside in /lib32 and /usr/lib32. Thus, the above
paragraph is somewhat confusing to somebody who is running a Kubuntu
Linux distribution. (Presumably the same holds for Debian and all
other distributions derived from Debian.)
Cheers,
Berwin
=== Full address =
Berwin A TurlachTel.: +65 6515 4416 (secr)
Dept of Statistics and Applied Probability+65 6515 6650 (self)
Faculty of Science FAX : +65 6872 3919
National University of Singapore
6 Science Drive 2, Blk S16, Level 7 e-mail: [EMAIL PROTECTED]
Singapore 117546http://www.stat.nus.edu.sg/~statba
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] patch for random.c
Dear all, while looking for some inspiration of how to organise some code, I studied the code of random.c and noticed that for distributions with 2 or 3 parameters the user is not warned if NAs are created while such a warning is issued for distributions with 1 parameter. E.g: R version 2.7.0 Under development (unstable) (2008-02-29 r44639) [...] > rexp(2, rate=Inf) [1] NaN NaN Warning message: In rexp(2, rate = Inf) : NAs produced > rnorm(2, mean=Inf) [1] NaN NaN Surprisingly, the code for issuing warnings for distributions with 2 or 3 parameters is essentially there, but does not seem to be used. The attached patch rectifies this. With the patch the above command produce the following output: > rexp(2, rate=Inf) [1] NaN NaN Warning message: In rexp(2, rate = Inf) : NAs produced > rnorm(2, mean=Inf) [1] NaN NaN Warning message: In rnorm(2, mean = Inf) : NAs produced Please ignore the patch if the code that was designed to produce the warning had been removed on purpose. BTW, there are other places in the code were NAs can be created but no warning is issued. E.g: > rexp(2, rate=numeric()) [1] NA NA > rnorm(2, mean=numeric()) [1] NA NA I wonder whether a warning should be issued in this case too. Best wishes, Berwin Index: src/main/random.c === --- src/main/random.c (revision 44639) +++ src/main/random.c (working copy) @@ -123,7 +123,7 @@ #define RAND2(num,name) \ case num: \ - random2(name, REAL(a), na, REAL(b), nb, REAL(x), n); \ + naflag = random2(name, REAL(a), na, REAL(b), nb, REAL(x), n); \ break /* "do_random2" - random sampling from 2 parameter families. */ @@ -207,7 +207,7 @@ #define RAND3(num,name) \ case num: \ - random3(name, REAL(a), na, REAL(b), nb, REAL(c), nc, REAL(x), n); \ + naflag = random3(name, REAL(a), na, REAL(b), nb, REAL(c), nc, REAL(x), n); \ break __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] patch for random.c
G'day Martin,
On Mon, 3 Mar 2008 10:16:45 +0100
Martin Maechler <[EMAIL PROTECTED]> wrote:
> >>>>> "BAT" == Berwin A Turlach <[EMAIL PROTECTED]>
> >>>>> on Fri, 29 Feb 2008 18:19:40 +0800 writes:
>
> BAT> while looking for some inspiration of how to organise some
> BAT> code, I studied the code of random.c and noticed that for
> BAT> distributions with 2 or 3 parameters the user is not warned
> BAT> if NAs are created while such a warning is issued for
> BAT> distributions with 1 parameter. [...] The attached patch
> BAT> rectifies this. [...]
>
> I cannot imagine a design reason for that. If there was, it
> should have been mentioned as a comment in the C code.
>
> I'll commit your patch (if it passes the checks).
Sorry, I was a bit in a hurry when writing the e-mail, so I forgot to
mention that the source code modified by this patch compiles and passes
"make check FORCE=FORCE" on my machine.
And in my hurry, I also posted from my NUS account, without realising
it, which forced you to intervene as moderator and to approve the
posting. My apologies for the extra work. But this gave me the idea
to also subscribe to r-devel with my NUS account and configure the
subscriptions so that I only receive e-mail at my UWA account. Thus,
hopefully, you will not have to intervene again. (Which this e-mail
should test.)
> BAT> BTW, there are other places in the code were NAs can be
> BAT> created but no warning is issued. E.g:
>
> >> rexp(2, rate=numeric())
> BAT> [1] NA NA
> >> rnorm(2, mean=numeric())
> BAT> [1] NA NA
>
> BAT> I wonder whether a warning should be issued in this case
> BAT> too.
>
> Yes, "should in principle".
>
> If you feel like finding another elegant patch...
Well, elegance is in the eye of the beholder. :-) I attach two
patches. One that adds warning messages at the other places where NAs
can be generated.
The second one in additiona rearranges the code a bit such that in the
case when all the "vectors" that contain the parameter values of the
distribution, from which one wants to simulate, are of length one some
unnecessary calculations is taken out of the for loop. I am not sure
how much time is actually saved in this situation, but I belong to the
school that things such kind of optimisation should be done. :) If you
think it bloats the code too much (or duplicates things too much
leading to hard to maintain code), then feel free to ignore this second
patch.
> Thank you Berwin, for your contribution!
My pleasure.
Cheers,
Berwin
Index: src/main/random.c
===
--- src/main/random.c (revision 44677)
+++ src/main/random.c (working copy)
@@ -81,6 +81,7 @@
if (na < 1) {
for (i = 0; i < n; i++)
REAL(x)[i] = NA_REAL;
+warning(_("NAs produced"));
}
else {
PROTECT(a = coerceVector(CADR(args), REALSXP));
@@ -123,7 +124,7 @@
#define RAND2(num,name) \
case num: \
- random2(name, REAL(a), na, REAL(b), nb, REAL(x), n); \
+ naflag = random2(name, REAL(a), na, REAL(b), nb, REAL(x), n); \
break
/* "do_random2" - random sampling from 2 parameter families. */
@@ -155,6 +156,7 @@
if (na < 1 || nb < 1) {
for (i = 0; i < n; i++)
REAL(x)[i] = NA_REAL;
+warning(_("NAs produced"));
}
else {
PROTECT(a = coerceVector(CADR(args), REALSXP));
@@ -207,7 +209,7 @@
#define RAND3(num,name) \
case num: \
- random3(name, REAL(a), na, REAL(b), nb, REAL(c), nc, REAL(x),
n); \
+ naflag = random3(name, REAL(a), na, REAL(b), nb, REAL(c), nc,
REAL(x), n); \
break
@@ -244,6 +246,7 @@
if (na < 1 || nb < 1 || nc < 1) {
for (i = 0; i < n; i++)
REAL(x)[i] = NA_REAL;
+warning(_("NAs produced"));
}
else {
PROTECT(a = coerceVector(a, REALSXP));
Index: src/main/random.c
===
--- src/main/random.c (revision 44677)
+++ src/main/random.c (working copy)
@@ -41,10 +41,19 @@
double ai;
int i;
errno = 0;
-for (i = 0; i < n; i++) {
+if( na == 1 ){
+ ai = a[0];
+ for (i = 0; i < n; i++) {
+ x[i] = f(ai);
+ if (!R_FINITE(x[i])) naflag = 1;
+ }
+}
+else{
+ for (i = 0; i < n; i++) {
ai = a[i % na];
x[i] = f(ai);
if (!R_FINITE(x[i])) naflag = 1;
+ }
}
return(naflag);
}
@@ -81,6 +90,7 @@
if (na < 1) {
for (i = 0; i < n; i++)
[Rd] A patch
Dear all, since a day or two "make dvi" and "make pdf" fails on my machine when I try to install the latest version of R from scratch. The attached patch seems to solve this problem. Cheers, Berwin === Full address ============= Berwin A TurlachTel.: +65 6515 4416 (secr) Dept of Statistics and Applied Probability+65 6515 6650 (self) Faculty of Science FAX : +65 6872 3919 National University of Singapore 6 Science Drive 2, Blk S16, Level 7 e-mail: [EMAIL PROTECTED] Singapore 117546http://www.stat.nus.edu.sg/~statba __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] A patch
On Wed, 5 Mar 2008 21:02:34 +0800
Berwin A Turlach <[EMAIL PROTECTED]> wrote:
> since a day or two "make dvi" and "make pdf" fails on my machine when
> I try to install the latest version of R from scratch. The attached
> patch seems to solve this problem.
Sorry, forgot to change the attachment from application/octet-stream to
text/plain and it got scrubbed. Patch is attached now.
Cheers,
Berwin
Index: src/library/grDevices/man/unix/x11.Rd
===
--- src/library/grDevices/man/unix/x11.Rd (revision 44677)
+++ src/library/grDevices/man/unix/x11.Rd (working copy)
@@ -136,7 +136,7 @@
\code{cairo} (on Mac OS X and perhaps elsewhere). Both make use of
\code{fontconfig} (\url{http://.fontconfig.org}) to select fonts
and so the results depend on the fonts installed on the system running
- \R -- setting the environmnent variable \env{FC_DEBUG} to 1 allows
+ \R -- setting the environmnent variable \env{FC\_DEBUG} to 1 allows
some tracing of the selection process.
This works best when high-quality scalable fonts are installed,
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NA warnings for r() {aka "patch for random.c"}
G'day Martin (and "listeners"),
On Fri, 7 Mar 2008 15:01:26 +0100
Martin Maechler <[EMAIL PROTECTED]> wrote:
[...]
> >> If you feel like finding another elegant patch...
>
> BAT> Well, elegance is in the eye of the beholder. :-)
>
> BAT> I attach two patches. One that adds warning messages at
> BAT> the other places where NAs can be generated.
>
> ok. The result is very simple ``hence elegant''.
>
> But actually, part of the changed behavior may be considered
> undesirable:
>
> rnorm(2, mean = NA)
>
> which gives two NaN's would now produce a warning,
> where I could argue that
>'arithmetic with NAs should give NAs without a warning'
> since
> 1:2 + NA
> also gives NAs without a warning.
>
> So we could argue that a warning should *only* be produced in a
> case where the parameters of the distribution are not NA.
>
> What do others (particularly R-core !) think?
I can agree with that point of view. But then, should a warning not
be issued only if one of the parameters of the distribution is NA, or
should it also not be issued if any non-finite parameter is
encountered? After all,
> 1:2 + Inf
[1] Inf Inf
does not create any warning either. In that case, a patch as the
attached should do, it checks all parameters for finiteness and then
checks whether the generated number is not finite.
Thus, with the patch applied I see the following behaviour:
> rnorm(2, mean=NA)
[1] NaN NaN
> rnorm(5, mean=c(0,Inf, -Inf, NA, NaN))
[1] 1.897874 NaN NaN NaN NaN
> rbinom(2, size=20, p=1.2)
[1] NaN NaN
Warning message:
In rbinom(2, size = 20, p = 1.2) : NAs produced
> rexp(2, rate=-2)
[1] NaN NaN
Warning message:
In rexp(2, rate = -2) : NAs produced
Without the patch:
> rnorm(2, mean=NA)
[1] NaN NaN
> rnorm(5, mean=c(0,Inf, -Inf, NA, NaN))
[1] -0.1719657NaNNaNNaNNaN
> rbinom(2, size=20, p=1.2)
[1] NaN NaN
> rexp(2, rate=-2)
[1] NaN NaN
Warning message:
In rexp(2, rate = -2) : NAs produced
On my machine, "make check FORCE=FORCE" passes with this patch.
[...]
> For now, I will ignore this second patch.
>
> - it does bloat the code slightly (as you conceded)
Fair enough. :) I also proved my point that more complicated code is
harder to maintain. In the two parameter case I was testing twice na
for being one instead of testing na and nb...
[...]
> but most importantly:
>
> - we have no idea if the speedup (when is TRUE)
>is in the order of 10%, 1% or 0.1%
>
>My guess would be '0.1%' for rnorm(), and that would
>definitely not warrant the extra check.
I would not bet against this. Probably even with all the additional
checks for finiteness of parameters there would be not much speed
difference. The question might be whether you want to replace the
(new) R_FINITE()'s rather by ISNA()'s (or something else). One could
also discuss in which order the checks should be made (first generated
number then parameters of distribution or vice versa). But I will
leave this to R-core to decide. :)
> >> Thank you Berwin, for your contribution!
>
> and thanks again!
Still my pleasure. :)
Cheers,
Berwin
Index: src/main/random.c
===
--- src/main/random.c (revision 44693)
+++ src/main/random.c (working copy)
@@ -44,7 +44,7 @@
for (i = 0; i < n; i++) {
ai = a[i % na];
x[i] = f(ai);
- if (!R_FINITE(x[i])) naflag = 1;
+ if (!R_FINITE(x[i]) && R_FINITE(ai)) naflag = 1;
}
return(naflag);
}
@@ -81,6 +81,7 @@
if (na < 1) {
for (i = 0; i < n; i++)
REAL(x)[i] = NA_REAL;
+warning(_("NAs produced"));
}
else {
PROTECT(a = coerceVector(CADR(args), REALSXP));
@@ -116,14 +117,14 @@
ai = a[i % na];
bi = b[i % nb];
x[i] = f(ai, bi);
- if (!R_FINITE(x[i])) naflag = 1;
+ if (!R_FINITE(x[i]) && R_FINITE(ai) && R_FINITE(bi)) naflag = 1;
}
return(naflag);
}
#define RAND2(num,name) \
case num: \
- random2(name, REAL(a), na, REAL(b), nb, REAL(x), n); \
+ naflag = random2(name, REAL(a), na, REAL(b), nb, REAL(x), n); \
break
/* "do_random2" - random sampling from 2 parameter families. */
@@ -155,6 +156,7 @@
if (na < 1 || nb < 1) {
for (i = 0; i < n; i++)
REAL(x)[i] = NA_REAL;
+warning(_("NAs produced"));
}
else {
PROTECT(a = coerceVector(CADR(args), REALSXP));
@@ -200,14 +202,14 @@
bi = b[i % nb];
ci = c[i % nc];
x[i] = f(ai, bi, ci);
- if (!R_FINITE(x[i])) naflag = TRUE;
+ if (!R_FINITE(x[i]) && R_FINITE(ai) && R_FINITE(bi) && R_FINITE(ci))
naflag = TRUE;
}
return(naflag);
}
#define RAND3(num,name) \
case num: \
- random3(name, REAL(a), na, REAL(b), nb, REAL(c), nc, REAL(x),
n); \
+ naflag = random3(name, REAL(a), na, RE
Re: [Rd] NA warnings for r() {aka "patch for random.c"}
G'day Martin and others,
On Mon, 10 Mar 2008 12:06:01 +0100
Martin Maechler <[EMAIL PROTECTED]> wrote:
> >>>>> "BAT" == Berwin A Turlach <[EMAIL PROTECTED]>
> >>>>> on Fri, 7 Mar 2008 23:54:06 +0800 writes:
>
> BAT> After all,
>
> >> 1:2 + Inf
> BAT> [1] Inf Inf
>
> BAT> does not create any warning either.
>
> but it doesn't give NA either.
> A bit more relevant (and I'm sure you meant implicitly)
You give me more credit than I deserve. :)
I was guided by what rexp() was doing when I chose that example, i.e.
(potentially) warning about NAs being created when actually +/- Infs
were created. In this thread I was already once or twice tempted to
comment on the appropriateness of the warning message but for various
reasonx always refrained from doing so.
> BTW, I've also found that I
> rnorm(n, mu=Inf) |--> NA was not ok, and changed that to
> rnorm(n, mu=Inf) |--> Inf
>
> More feedback is welcome,
> but please now "start" with R-devel rev >= 44715
While I agree with this change, I think it opens a whole can of worms,
since it invites a rethink about all distributions. At the moment
we have:
R version 2.7.0 Under development (unstable) (2008-03-10 r44730)
> set.seed(1) ; exp(rnorm(2))
[1] 0.5344838 1.2015872
> set.seed(1) ; rlnorm(2)
[1] 0.5344838 1.2015872
> set.seed(1) ; exp(rnorm(2, mean=c(-Inf,Inf)))
[1] 0 Inf
> set.seed(1) ; rlnorm(2, mean=c(-Inf,Inf))
[1] NaN NaN
Warning message:
In rlnorm(2, mean = c(-Inf, Inf)) : NAs produced
The first two lines give identical results, as one could reasonably
expect. But the other two do not and I would argue that a user could
reasonably expect that the commands in these two lines should lead to
identical results.
Likewise, coming back to the one-parameter distribution used in this
thread for illustration purposes, the *exp() functions in R are
parameterised by the rate and an exponential random variable with rate
r has mean (1/r) and variance (1/r^2). Thus, I would argue that
rexp(2, Inf) should return 0's and not NaN's, since in the limit
a rate of Inf seems to refer to a variable with mean 0 and variance 0,
i.e. the constant 0. And it would also be "more consistent" with the
behaviour of rexp() when the rate parameter is "large but finite".
Then one can argue about rgeom() when p=0. But I guess in that case
the limit is a "random" variable with "infinite mean" and "infinite
variance" and hence it is o.k. to return NaNs and not Infs. After all,
your comments in rnorm.c seem to indicate that you think that reporting
+/- Inf back is only o.k. if the mean is +/- Inf but the variance is
finite.
I did not look at (or think about) extreme cases for any other
distributions, but further discussion/feedback would indeed be helpful
it seems. :)
And the attached patch would address the behaviour of rlnorm() and
rexp() that I have raised above. With these changes, on my machine,
"make check FORCE=FORCE" succeeds.
BTW, I was surprised to realise that the *exp() functions in the
underlying C code use the opposite parameterisation from the
corresponding functions at R level. Perhaps it would be worthwhile to
point this out in section 6.7.1 of the Writing R extension manual? In
particular since the manual states:
Note that these argument sequences are (apart from the names and that
@code{rnorm} has no @var{n}) exactly the same as the corresponding
@R{} functions of the same name, so the documentation of the @R{}
functions can be used.
Well, as I noticed the hard way, for *exp() the documentation of the
corresponding R functions cannot be used. ;-)
Thanks for you patience.
Cheers,
Berwin
Index: src/library/stats/R/distn.R
===
--- src/library/stats/R/distn.R (revision 44730)
+++ src/library/stats/R/distn.R (working copy)
@@ -19,7 +19,7 @@
.Internal(pexp(q, 1/rate, lower.tail, log.p))
qexp <- function(p, rate=1, lower.tail = TRUE, log.p = FALSE)
.Internal(qexp(p, 1/rate, lower.tail, log.p))
-rexp <- function(n, rate=1) .Internal(rexp(n, 1/rate))
+rexp <- function(n, rate=1) .Internal(rexp(n, ifelse(rate==-Inf, -Inf,
1/rate)))
dunif <- function(x, min=0, max=1, log = FALSE)
.Internal(dunif(x, min, max, log))
Index: src/nmath/rexp.c
===
--- src/nmath/rexp.c(revision 44730)
+++ src/nmath/rexp.c(working copy)
@@ -32,7 +32,7 @@
double rexp(double scale)
{
-if (!R_FINITE(scale) || scale <= 0.0)
+if (!R_FINITE(scale) || scale < 0.0)
ML_ERR_return_NAN;
return scale * exp_rand();
Index: src/nmath/rlnorm.c
=
Re: [Rd] NA warnings for r() {aka "patch for random.c"}
G'day Martin,
On Tue, 11 Mar 2008 18:07:35 +0100
Martin Maechler <[EMAIL PROTECTED]> wrote:
> >>>>> "BAT" == Berwin A Turlach <[EMAIL PROTECTED]>
> >>>>> on Tue, 11 Mar 2008 13:19:46 +0800 writes:
[...]
> BAT> The first two lines give identical results, as one could
> BAT> reasonably expect.
>
> Yes, but I don't think a user should *rely* on the way R
> generates these random number; though I agree for the very
> specific case of rlnorm(..).
>
> BAT> But the other two do not and I would argue that a user could
> BAT> reasonably expect that the commands in these two lines
> BAT> should lead to identical results.
>
> They now do.
Well, actually I forgot to mention one could also put another argument
forward. As the log-mean parameter of the lognormal distribution
goes to -Inf, the distribution degenerates to something that has mean 0
and variance 0, i.e. could be taken as the constant zero and, hence,
one might expect that rlnorm(1, -Inf) returns 0.
But as the log-mean parameter goes to Inf, the distribution degenerates
to something with infinite mean and infinite variance. Thus, perhaps
it is more sensible for rlnorm(1, Inf) to return NaN instead of Inf.
> I don't think your change to .../R/distn.R was good,
I didn't like it either, but it was the simplest way I could think of
that would allow the C rexp() routine to realise that a scale parameter
of 0 actually came from a rate parameter of -Inf in the R code.
> but the others I have more or less committed together with a few
> more similar ones.
Thanks.
> BAT> BTW, I was surprised to realise that the *exp() functions in
> BAT> the underlying C code use the opposite parameterisation from
> BAT> the corresponding functions at R level. Perhaps it would be
> BAT> worthwhile to point this out in section 6.7.1 of the Writing
> BAT> R extension manual? In particular since the manual states:
>
> BAT> Note that these argument sequences are (apart from the names
> BAT> and that @code{rnorm} has no @var{n}) exactly the same as
> BAT> the corresponding @R{} functions of the same name, so the
> BAT> documentation of the @R{} functions can be used.
>
> BAT> Well, as I noticed the hard way, for *exp() the
> BAT> documentation of the corresponding R functions cannot be
> BAT> used. ;-)
>
> We often also gratefully accept patches for the documentation
I know, and I am always amazed that despite this policy (or perhaps
because of it?) the documentation of R is not patchy ;-)
Cheers,
Berwin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] prod(0, 1:1000) ; 0 * Inf etc
G'day Martin, On Mon, 21 Apr 2008 18:40:43 +0200 Martin Maechler <[EMAIL PROTECTED]> wrote: > I think most of us would expect prod(0:1000) to return 0, and ... > ... it does. > > However, many of us also expect > prod(x1, x2)to be equivalent to > prod(c(x1,x2)) > the same as we can expect that for min(), max(), sum() and such > members of the "Summary" group. Many may also expect that prod(x) and prod(rev(x)) are equivalent. Unfortunately, this does not hold in finite precision arithmetic: > prod(0:1000) [1] 0 > prod(1000:0) [1] NA > prod(rev(0:1000)) [1] NA It might be better to educate useRs on finite precision arithmetic than trying to catch such situations. Note, I am saying "better", not "easier". :-) Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] troubles with R CMD check and examples under Ubuntu gutsy
G'day Patrick,
since you seem to be hell-bent on having r-devel in this discussion, I
guess I might CC this there too. :)
On Mon, 05 May 2008 08:50:04 +0200
Patrick Giraudoux <[EMAIL PROTECTED]> wrote:
> There has been a threat on something similar in R-devel on August
> 2007... but I cannot understand the meaning.
It might be a good idea to provide a link to that discussion. Perhaps
others can understand the meaning and judge the relevance to this
thread.
> > Did you look at the file in pgirmess.Rcheck that I mentioned?
> You'll find a copy of pgirmess-Ex.R, but I cannot get what is the
> meaning of this file...
This file collects all the code in the example sections of your
documentation file, and puts some necessary code in front, in between
the examples and at the end. This file is then sourced to run all the
examples and the output can be found in pgrimess-Ex.Rout. And it was
this file that I suggested you look at to see if it provides further
clues about what goes wrong.
> > Also, did you try to load the version of the library in
> > pgrimess.Rcheck in a R session and check if you find the PermTest
> > function in that case?
> Yes indeed. I found PermTest in the R folder and in the R-ex folder
> of the pgirmess folder in the pgirmess.Rcheck folder.
I am surprised to hear this. R-ex holds all the code from the example
sections in the Rd files, so it is no surprise that you will find a
file PermTest.R in the R-ex folder, it just contains the code from the
example section of PermTest.Rd, at last on my machine. It definitely
does not contain the definition of the funcion. And on my machine,
after running `R CMD check' on the tar.gz file, the R folder in
pgirmess.Rcheck/pgirmess contains the files pgirmess, pgirmess.rdb and
pgirmess.rdx, but no files with R code. So how did you find PermTest
in the R folder? Is lazy-loading somehow switched off in your version
of `R CMD check'?
> > With these problems, I am a bit of a trial-and-error person, so if I
> > cannot reproduce the error, I cannot find out what the problem
> > is
> Thanks anyway for the hints. It may help.
I would suggest the following:
1) remove the directore pgirmess.Rcheck
2) run `R CMD check pgirmess' and see if the error occurs again
3) look at pgirmess.Rcheck/pgirmess/R. Does it contain the three files
that I mentioned or the original source files. If the latter,
check whether PermTest.R is in that directory and whether it really
contains the commands that define that function. If the former, start
an R session and issue the following commands:
R> env <- new.env()
R> lazyLoad("/path/to/pgirmess.Rcheck/pgirmess/R/pgirmess", envir=env)
R> ls(envir=env)
Make sure to replace the /path/to part above with the correct path. Do
you see the PermTest function listed?
This should establish whether the file that contains the PermTest
function is part of the sources that you believe make up your package
source. At the moment, I am leaning towards agreeing with Brian that
the most likely reason for your problem is that the PermTest function
got lost from your sources and is not installed.
Best wishes,
Berwin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] literate programming
G'day Terry, On Tue, 5 Aug 2008 09:38:23 -0500 (CDT) Terry Therneau <[EMAIL PROTECTED]> wrote: > I'm working on the next iteration of coxme. (Rather slowly during > the summer). > This is the most subtle code I've done in S, both mathematically > and technically, and seems a perfect vehicle for the "literate > programming" paradym of Knuth. The Sweave project is pointed at S > output however, not source code. I would appreciate any pointers to > an noweb type client that was R-aware. I would suggest you look at relax: http://www.wiwi.uni-bielefeld.de/~wolf/software/relax/relax.html Cheers, Berwin ======= Full address = Berwin A TurlachTel.: +65 6515 4416 (secr) Dept of Statistics and Applied Probability+65 6515 6650 (self) Faculty of Science FAX : +65 6872 3919 National University of Singapore 6 Science Drive 2, Blk S16, Level 7 e-mail: [EMAIL PROTECTED] Singapore 117546http://www.stat.nus.edu.sg/~statba __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] why is \alias{anRpackage} not mandatory?
G'day Hadley,
On Mon, 6 Oct 2008 08:55:14 -0500
"hadley wickham" <[EMAIL PROTECTED]> wrote:
> >> The main problem with vignettes at the moment is that
> >> they must be sweave, a format which I don't really like. I wish I
> >> could supply my own pdf + R code file produced using whatever
> >> tools I choose.
> >
> > I like Sweave, and it is also possible to include your own PDFs and
> > R files and then to reference them in anRpackage.Rd.
>
> Yes, but they're not vignettes - which means they're not listed under
> vignette() and it's yet another place for people to look for
> documentation.
Well, there is a kind of subversive way of how do use the facilities
provided to vignettes for PDFs that were created by some other
mechanism. That was discussed sometime ago on this list. The idea was
to create an "empty" vignette that uses the LaTeX package pdfpages to
include the existing PDF into a vignette.
Since you ended up with essentially two copies of the same PDF file,
you can use .Rbuildignore to exclude the original PDF from the build
and only distribute the PDF created from the vignette.
This trick worked really well as long as "R CMD check" was not trying
to latex the .tex file produced from the vignette (apparently since R
2.6.0 the behaviour of "R CMD check" in this respect has changed,
though the "Writing R Extension" manual was not updated to reflect
this change; which reminds me that I promised Kurt Hornik to file a
bug report about this). What makes things worse is that with the
current TeX installation on Debian based operating system, latex hangs
if a file, from which pdfpages wants to include some (or all) pages,
does not exist. That is "R CMD check" on such a tar.gz file hangs and
doesn't stop with an error message.
The solution that I am using at the moment is shown in the attached
file which resides in inst/doc of the lasso2 package on my machine. On
my machine, "R CMD build" and "R CMD check" will, of course, work.
Essentially, this vignette only creates the information needed to index
it and then includes the file Manual-wo-help.pdf (which is the old help
for the S-Plus version of that package; I should really update all
this). Manual-wo-help.pdf is excluded from lasso2_x.y-z.tar.gz via an
entry in .Rbuildignore but the vignette is distributed and listed under
vignette(). And "R CMD check" on works the .tar.gz file too.
Cheers,
Berwin
=== Full address =
Berwin A TurlachTel.: +65 6516 4416 (secr)
Dept of Statistics and Applied Probability+65 6516 6650 (self)
Faculty of Science FAX : +65 6872 3919
National University of Singapore
6 Science Drive 2, Blk S16, Level 7 e-mail: [EMAIL PROTECTED]
Singapore 117546http://www.stat.nus.edu.sg/~statba
\documentclass[a4paper]{article}
%\VignetteIndexEntry{Manual of lasso2 package}
%\VignettePackage{lasso2}
\usepackage{pdfpages}
\begin{document}
\newread\PDFtoInclude
\openin\PDFtoInclude=Manual-wo-help.pdf
\ifeof\PDFtoInclude
\typeout{No file Manual-wo-help.pdf}
\else
\includepdf[fitpaper=true,pages=-]{Manual-wo-help.pdf}
\fi
\end{document}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] splinefun gives incorrect derivs when extrapolating to the left (PR#13132)
On Tue, 7 Oct 2008 19:31:03 +0800
Berwin A Turlach <[EMAIL PROTECTED]> wrote:
> The attached patch (against the current SVN version of R) implements
> the latter strategy. With this patch applied, "make check
> FORCE=FORCE" passes on my machine. The version of R that is build
> seems to give the correct answer in your example:
Perhaps I should have thought a bit more about this. For a natural
spline c[1] is zero, and d[1] is typically not but for evaluations
left of the first knot it should be taken as zero. So the attached
patch solves the problem in what some might consider a more elegant
manner. :)
With the patch "make check FORCE=FORCE" works on my machine and it
also solves your example:
R> x <- 1:10
R> y <- sin(x)
R>
R> splfun <- splinefun(x,y, method='natural')
R>
R> # these should be linear (and are)
R> splfun( seq(0,1, 0.1) )
[1] 0.5682923 0.5956102 0.6229280 0.6502459 0.6775638 0.7048816
[7] 0.7321995 0.7595174 0.7868352 0.8141531 0.8414710
R>
R> # these should all be the same
R> splfun( seq(0,1, 0.1), deriv=1 )
[1] 0.2731787 0.2731787 0.2731787 0.2731787 0.2731787 0.2731787
[7] 0.2731787 0.2731787 0.2731787 0.2731787 0.2731787
R>
R> # these should all be 0
R> splfun( seq(0,1, 0.1), deriv=2 )
[1] 0 0 0 0 0 0 0 0 0 0 0
R> splfun( seq(0,1, 0.1), deriv=3 )
[1] 0 0 0 0 0 0 0 0 0 0 0
HTH.
Cheers,
Berwin
=== Full address =
Berwin A TurlachTel.: +65 6516 4416 (secr)
Dept of Statistics and Applied Probability+65 6516 6650 (self)
Faculty of Science FAX : +65 6872 3919
National University of Singapore
6 Science Drive 2, Blk S16, Level 7 e-mail: [EMAIL PROTECTED]
Singapore 117546http://www.stat.nus.edu.sg/~statba
Index: src/library/stats/R/splinefun.R
===
--- src/library/stats/R/splinefun.R (revision 46635)
+++ src/library/stats/R/splinefun.R (working copy)
@@ -38,7 +38,6 @@
y <- as.vector(tapply(y,x,ties))# as.v: drop dim & dimn.
x <- sort(ux)
nx <- length(x)
- rm(ux)
} else {
o <- order(x)
x <- x[o]
@@ -93,7 +92,7 @@
d=double(nx),
e=double(if(iMeth == 1) nx else 0),
PACKAGE="stats")
-rm(x,y,nx,o,method,iMeth)
+rm(x,y,nx,ux,o,method,iMeth)
z$e <- NULL
function(x, deriv = 0) {
deriv <- as.integer(deriv)
@@ -114,18 +113,25 @@
## where dx := (u[j]-x[i]); i such that x[i] <= u[j] <=
x[i+1},
##u[j]:= xout[j] (unless sometimes for periodic spl.)
## and d_i := d[i] unless for natural splines at left
- .C("spline_eval",
- z$method,
- as.integer(length(x)),
- x=as.double(x),
- y=double(length(x)),
- z$n,
- z$x,
- z$y,
- z$b,
- z$c,
- z$d,
- PACKAGE="stats")$y
+ res <- .C("spline_eval",
+ z$method,
+ as.integer(length(x)),
+ x=as.double(x),
+ y=double(length(x)),
+ z$n,
+ z$x,
+ z$y,
+ z$b,
+ z$c,
+ z$d,
+ PACKAGE="stats")$y
+
+## deal with points to the left of first knot if natural
+## splines are used (Bug PR#13132)
+if( deriv > 0 && z$method==2 && any(ind <- x<=z$x[1]) )
+ res[ind] <- ifelse(deriv == 1, z$y[1], 0)
+
+res
}
}
Index: src/library/stats/man/splinefun.Rd
===
--- src/library/stats/man/splinefun.Rd (revision 46635)
+++ src/library/stats/man/splinefun.Rd (working copy)
@@ -131,7 +131,7 @@
par(op)
## Manual spline evaluation --- demo the coefficients :
-.x <- get("ux", envir = environment(f))
+.x <- splinecoef$x
u <- seq(3,6, by = 0.25)
(ii <- findInterval(u, .x))
dx <- u - .x[ii]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] splinefun gives incorrect derivs when extrapolating to the left (PR#13132)
G'day Greg,
On Mon, 6 Oct 2008 19:50:13 +0200 (CEST)
[EMAIL PROTECTED] wrote:
> This is a low priority bug that has been around for a while, but I
> came across it again while alpha testing 2.8.
Indeed, that bug must have been around since splinefun was changed to
return a function with a deriv argument. Looks as if the person who
produced the initial patch didn't really think through all
possibilities. ;-)
> The resulting function for splinefun gives incorrect deriv values
> when x is less than the smallest x-value used to create the function
> (at least in one circumstance), but does the correct thing for x
> greater than the largest x-value.
In a nutshell, splinefun calls, after some initial processing, the C
routine spline_coef to fit the desired spline. spline_coef returns
coefficients for the following representation of the spline;
a[i] + dx*(b[i] + dx*(c[i] + dx* d[i])
where dx := u-x[i]; i such that x[i] <= u <= x[i+1]. This would
evaluate the spline at u; the xs are the original knots.
I.e., the four coefficients returned for a knot correspond to the
polynomial to the "right" of that knot. Hence no problem with
evaluating derivatives to the right of the largest knot.
The routine returned by splinefun, calls the C function spline_eval to
evaluate the spline at the desired points. If deriv > 0, then the above
representation of the polynomials that make up the splines is
differentiated within the R code to obtain the desired derivative of
the spline. The problem is that spline_eval does not know which
derivative is evaluated and assumes that the function itself is
evaluated. Thus, for evaluation points left of the first knot it sets
d[1] to zero (d[1] is usually not zero). This, of course, breaks down
when derivatives are evaluated (in this case spline_eval should set
c[1], b[1] or a[1] to zero depending on whether the 1, 2 or 3
derivative is evaluated).
The solution would be to either make spline_eval aware that a
derivative is evaluated, but this would imply that that C function gets
another parameter and the changes in the C code would probably not be
very "elegant", or to have the R code of the function returned by
splinefun check whether a natural spline was fitted and is now
evaluated at points to the left of the first knot; with appropriate
actions if this happens.
The attached patch (against the current SVN version of R) implements the
latter strategy. With this patch applied, "make check FORCE=FORCE"
passes on my machine. The version of R that is build seems to give the
correct answer in your example:
R> x <- 1:10
R> y <- sin(x)
R>
R> splfun <- splinefun(x,y, method='natural')
R>
R> # these should be linear (and are)
R> splfun( seq(0,1, 0.1) )
[1] 0.5682923 0.5956102 0.6229280 0.6502459 0.6775638 0.7048816
[7] 0.7321995 0.7595174 0.7868352 0.8141531 0.8414710
R>
R> # these should all be the same
R> splfun( seq(0,1, 0.1), deriv=1 )
[1] 0.2731787 0.2731787 0.2731787 0.2731787 0.2731787 0.2731787
[7] 0.2731787 0.2731787 0.2731787 0.2731787 0.2731787
R>
R> # these should all be 0
R> splfun( seq(0,1, 0.1), deriv=2 )
[1] 0 0 0 0 0 0 0 0 0 0 0
R> splfun( seq(0,1, 0.1), deriv=3 )
[1] 0 0 0 0 0 0 0 0 0 0 0
HTH.
Cheers,
Berwin
=== Full address =
Berwin A TurlachTel.: +65 6516 4416 (secr)
Dept of Statistics and Applied Probability+65 6516 6650 (self)
Faculty of Science FAX : +65 6872 3919
National University of Singapore
6 Science Drive 2, Blk S16, Level 7 e-mail: [EMAIL PROTECTED]
Singapore 117546http://www.stat.nus.edu.sg/~statba
Index: src/library/stats/R/splinefun.R
===
--- src/library/stats/R/splinefun.R (revision 46635)
+++ src/library/stats/R/splinefun.R (working copy)
@@ -38,7 +38,6 @@
y <- as.vector(tapply(y,x,ties))# as.v: drop dim & dimn.
x <- sort(ux)
nx <- length(x)
- rm(ux)
} else {
o <- order(x)
x <- x[o]
@@ -93,7 +92,7 @@
d=double(nx),
e=double(if(iMeth == 1) nx else 0),
PACKAGE="stats")
-rm(x,y,nx,o,method,iMeth)
+rm(x,y,nx,ux,o,method,iMeth)
z$e <- NULL
function(x, deriv = 0) {
deriv <- as.integer(deriv)
@@ -114,18 +113,31 @@
## where dx := (u[j]-x[i]); i such that x[i] <= u[j] <=
x[i+1},
##u[j]:= xout[j] (unless sometimes for periodic spl.)
## and d_i := d[i] unless for natural splines at left
- .C("spline_eval",
- z$method,
- as.integer(length(x)),
- x=as.double(x),
-
Re: [Rd] (PR#13132) splinefun gives incorrect derivs when extrapolating to the left
Dear Brian, On Thu, 9 Oct 2008 07:27:24 +0100 (BST) Prof Brian Ripley <[EMAIL PROTECTED]> wrote: > Thanks, I've merged this (second version) patch into 2.8.0 beta. My pleasure. I thought it would be only fair that I fix the infelicity in the code after having provided the initial patch that introduced it. :) Apologies also for not realising that the bug repository truncates over long subject line and having thus filed two additional reports. Will remember that in future. Best wishes, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] typo in ?pie
G'day Brian, On Mon, 10 Nov 2008 21:07:44 + (GMT) Prof Brian Ripley <[EMAIL PROTECTED]> wrote: > 'British' spelling is in the majority amongst R-core, and preferred > for R documentation (that is in the guidelines somewhere). I have a vague memory of a discussion that ended with the conclusion that words like "colour" should be spelt "color"; at least in function names and function arguments. IIRC, this was for compatible reasons with S/S-Plus. Does your comment mean that we can send it patches for help pages in which "colour" is spelt "color" (e.g. lines in package:graphics) and such patches would be applied? Sorry, couldn't resist. :) Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] chisq.test with simulate.p.value=TRUE (PR#13292)
G'day Reginaldo, On Sun, 16 Nov 2008 01:00:09 +0100 (CET) [EMAIL PROTECTED] wrote: > Full_Name: Reginaldo Constantino > Version: 2.8.0 > OS: Ubuntu Hardy (32 bit, kernel 2.6.24) > Submission from: (NULL) (189.61.88.2) > > > For many tables, chisq.test with simulate.p.value=TRUE gives a p > value that is obviously incorrect and inversely proportional to the > number of replicates: Why is this Monte-Carlo p-value obviously incorrect? In your example, did you look at the observed ChiSquare statistics? Any idea how likely it is to observe a value that is at least as extreme as the one observed? Essentially, you are doing B Monte-Carlo simulations and in none of these simulations do you obtain a statistic that is at least as extreme as the one that you have observed. So your Monte-Carlo p-value ends up to be 1/(B+1). I do not see any problem or bug here. > > data(HairEyeColor) > > x <- margin.table(HairEyeColor, c(1, 2)) > > chisq.test(x,simulate.p.value=TRUE,B=2000) > Pearson's Chi-squared test with simulated p-value (based on > 2000 replicates) > data: x > X-squared = 138.2898, df = NA, p-value = 0.0004998 > > > chisq.test(x,simulate.p.value=TRUE,B=1) > X-squared = 138.2898, df = NA, p-value = 1e-04 > > > chisq.test(x,simulate.p.value=TRUE,B=10) > X-squared = 138.2898, df = NA, p-value = 1e-05 > > > chisq.test(x,simulate.p.value=TRUE,B=100) > X-squared = 138.2898, df = NA, p-value = 1e-06 > ... > > Also tested the same R version under Windows XP and got the same > results. Cheers, Berwin === Full address = Berwin A TurlachTel.: +65 6516 4416 (secr) Dept of Statistics and Applied Probability+65 6516 6650 (self) Faculty of Science FAX : +65 6872 3919 National University of Singapore 6 Science Drive 2, Blk S16, Level 7 e-mail: [EMAIL PROTECTED] Singapore 117546http://www.stat.nus.edu.sg/~statba __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Warning: missing text for item ... in \describe?
G'day Spencer,
On Sun, 30 Nov 2008 22:31:54 -0800
Spencer Graves <[EMAIL PROTECTED]> wrote:
> Hello:
>
> What might be the problem generating messages like "Warning:
> missing text for item ... in \describe" with "R CMD check" and "R CMD
> install"?
>
> With the current version of "fda" on R-Forge, I get the
> following:
>
>
> Warning: missing text for item 'fd' in \describe
> Warning: missing text for item 'fdPar' in \describe
fRegress.Rd, which contains
\item{fd} { ...
\item{fdPar} {...
Apparently the space between the closing and the opening bracket leads
to some confusion; remove the space and the warning goes away.
I am not sure why an extra space here leads to problems, would be nicer
if it would not. If it have to lead to a problem, then it would be
nice if the name of the .Rd files that produces the problem is actually
mentioned. :)
Don't ask me how I found this, let us just say that long live
find-grep-dired in emacs and perseverance (or should that be
stubbornness?)
HTH.
Cheers,
Berwin
=== Full address =
Berwin A TurlachTel.: +65 6516 4416 (secr)
Dept of Statistics and Applied Probability+65 6516 6650 (self)
Faculty of Science FAX : +65 6872 3919
National University of Singapore
6 Science Drive 2, Blk S16, Level 7 e-mail: [EMAIL PROTECTED]
Singapore 117546http://www.stat.nus.edu.sg/~statba
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Warning: missing text for item ... in \describe?
G'day Brian,
On Fri, 5 Dec 2008 15:35:00 + (GMT)
Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
> On Mon, 1 Dec 2008, Berwin A Turlach wrote:
>
> > G'day Spencer,
> >
> > On Sun, 30 Nov 2008 22:31:54 -0800
> > Spencer Graves <[EMAIL PROTECTED]> wrote:
> >
> >> Hello:
> >>
> >> What might be the problem generating messages like "Warning:
> >> missing text for item ... in \describe" with "R CMD check" and "R
> >> CMD install"?
> >>
> >> With the current version of "fda" on R-Forge, I get the
> >> following:
> >>
> >>
> >> Warning: missing text for item 'fd' in \describe
> >> Warning: missing text for item 'fdPar' in \describe
> >
> > fRegress.Rd, which contains
> >
> > \item{fd} { ...
> > \item{fdPar} {...
[...]
> Well, the warning/errors always come out just before the file with
> the problem (unless you have stdout buffered and stderr not). So
> finding which file does not seem so hard.
Which platform are we talking here? I was using linux and "R CMD check
fda", using R 2.8.0, on the command line said:
[...]
* checking for executable files ... OK
* checking whether package 'fda' can be installed ... WARNING
Found the following significant warnings:
Warning: missing text for item 'fd' in \describe
Warning: missing text for item 'fd' in \describe
Warning: missing text for item 'fdPar' in \describe
See '/home/berwin/lang/R/Develop/Others/fda.Rcheck/00install.out' for
details.
* checking package directory ... OK
[...]
And 00install.out said:
[...]
Attaching package: 'zoo'
The following object(s) are masked from package:base :
as.Date.numeric
** help
Warning: missing text for item 'fd' in \describe
Warning: missing text for item 'fd' in \describe
Warning: missing text for item 'fdPar' in \describe
>>> Building/Updating help pages for package 'fda'
Formats: text html latex example
CSTR texthtmllatex example
CanadianWeather texthtmllatex example
[...]
I am not aware that either stdout or stderr are buffered on my linux
box.
> This *is* an error: nothing in the description allows whitespace
> between arguments to \item (nor \section). It seems that only a few
> people misread the documentation (sometimes even after their error is
> pointed out to them).
But there is also nothing that explicitly forbid such whitespace, is
it? I guess this comes down to the question whether "everything is
allowed that is not expressively forbidden" or "everything is forbidden
unless it is expressively allowed". Strangely enough, though I am
German, I don't tend to subscribe to the latter philosophy.
The language of Rd files, and the notation used, seems to have some
clear roots in (La)TeX; and in (La)TeX whitespace between arguments to
macros is ignored. So one may argue that it is a bit of a surprise
that whitespace between arguments to \item matter here.
> What we can do is detect the error, and I am about to commit code in
> R-devel to do so.
Thanks. I am sure Spencer will be happy about this. :)
Cheers,
Berwin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Warning: missing text for item ... in \describe?
G'day Brian,
On Fri, 5 Dec 2008 17:32:58 + (GMT)
Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
[...]
> > Which platform are we talking here? I was using linux and "R CMD
> > check fda", using R 2.8.0, on the command line said:
>
> That writes to a file, and writes to a file are buffered. Try R CMD
> INSTALL, where they are not. We do recommend getting a clean install
> before R CMD check.
Indeed, forgot about that. Thanks for reminding me. With R CMD
INSTALL the messages are right next to the help files with the problems.
> >> This *is* an error: nothing in the description allows whitespace
> >> between arguments to \item (nor \section). It seems that only a few
> >> people misread the documentation (sometimes even after their error
> >> is pointed out to them).
> >
> > But there is also nothing that explicitly forbid such whitespace, is
> > it? I guess this comes down to the question whether "everything is
> > allowed that is not expressively forbidden" or "everything is
> > forbidden unless it is expressively allowed". Strangely enough,
> > though I am German, I don't tend to subscribe to the latter
> > philosophy.
>
> It really doesn't matter: the author of the convertor (not me)
> decidedly to silently ignore arguments after whitespace so you get an
> incorrect conversion. I also added sentences to the documentation
> that say that explicitly. But if I see documentation that says
>
> \item{foo}{bar}
>
> I don't see why anyone would be surprised that
>
> \item {foo} {bar}
>
> goes haywire.
Well, I was. :) And I guess anybody who knows that the TeX parser does
not care about whitespaces between arguments to macros but forgets
that .Rd files are not directly parsed by the TeX parser would have
been surprised too.
Use of whitespace and indentation is pretty much a matter of taste and
personal style to improve readability; and while there are languages
where they matter (Python, makefiles, &c), and some projects (including
R) have style-guides, usually a developer is left with a lot of
flexibility to suit her or his style. But I guess only Spencer knows
why a whitespace at this place was desirable and/or improved
readability.
Cheers,
Berwin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] unloadNamespace (Was: How to unload a dll loaded via library.dynam()?)
G'day all,
On Fri, 20 Feb 2009 04:01:07 + (GMT)
Prof Brian Ripley wrote:
> library.dynam.unload() does work if the OS is cooperative. And if
> you have your package set up correctly and unload the namespace (and
> not just detach the package if there is a namespace) then the shared
> object/DLL will be unloaded. [...]
I guess I have a similar code-install-test development cycle as Alex;
and I seem to work on a cooperative OS (Kubuntu 8.04).
My set up is that I install packages on which I work into a separate
library. To test changes to such packages, I start R in a directory
which contains a .Rprofile file which, via .libPaths(), adds the above
library to the library path. In this R session I then test the changes.
I also used to quit and restart R whenever I re-installed a package with
namespace to test the changes made. Somehow I got the impression that
this was the way to proceed when namespaces were introduced; and I did
not realise until recently that better ways (unloading the namespace)
exist.
However, I noticed the following behaviour under R 2.8.1 and "R version
2.9.0 Under development (unstable) (2009-02-19 r47958)" which I found
surprising:
1) In the running R session, issue the command "unloadNamespace(XXX)"
2) Do changes to the code of the package; e.g. add a "print("hello
world")" statement to one of the R functions.
3) Install the new package
4) In the running R session, issue the command "library(XXX)" and call
the R function that was changed.
Result: "Hello world" is not printed, somehow the old R function is
still used. If I issue the commands "unloadNamespace(XXX)" and
"library(XXX)" once more then a call to the R function that was changed
will print "Hello world"; i.e. the new code is used.
If the above sequence is changed to 2), 3) and then 1), then 4) behaves
"as expected" and the new R code is used immediately.
As far as I can tell, if via the .onUnload() hook the shared object is
unloaded via library.dynam.unload(), changes in the C code take effect
no matter whether I perform the above steps in the sequence 1-2-3-4 or
2-3-1-4.
My preference is to use the sequence 1-2-3-4 since it seems to be the
"more logical and cleaner" sequence; and I have vague memories that I
managed to crash R in the past after using 2-3 and then trying to quit
R.
I am wondering why does it make a difference with respect to R code in
which order these steps are done but not with respect to compiled
code. Well, I guess I understand why the order does not matter for
compiled code, but I do not understand why the order matters for R
code. I could not find anything in the documentation that would
explain this behaviour, or indicate that this is the intended
behaviour.
Enlightening comments and/or pointers to where this behaviour is
documented would be welcome.
Cheers,
Berwin
=== Full address =
Berwin A TurlachTel.: +65 6516 4416 (secr)
Dept of Statistics and Applied Probability+65 6516 6650 (self)
Faculty of Science FAX : +65 6872 3919
National University of Singapore
6 Science Drive 2, Blk S16, Level 7 e-mail: sta...@nus.edu.sg
Singapore 117546http://www.stat.nus.edu.sg/~statba
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] unloadNamespace (Was: How to unload a dll loaded via library.dynam()?)
G'day Brian, On Fri, 20 Feb 2009 11:37:18 + (GMT) Prof Brian Ripley wrote: > This was rather a large shift of subject, [...] Well, yes, from the clean unloading of compiled code to the clean unloading of R code. :-) Though, I also confirmed that the former is possible on a cooperative OS when library.dynam.unload() is correctly used via an .onUnload() hook. > Is lazy loading involved? Yes, the DESCRIPTION file has the default "LazyLoad: yes" entry. If I set "LazyLoad: no", then both sequences use the new version of the R code immediately. > If so I have an idea that may or may not be relevant. We do cache in > memory the lazy-loading database for speed on slow (network-mounted > or USB drive) file systems. Now the cache is flushed at least if you > do detach(foo, unload = TRUE) or but I can envisage a set of > circumstances in which it might not be. As far as I can tell, "detach(foo, unload=TRUE)" and "unloadNamespace(foo)" behave identical on my machines (while the DESCRIPTION file has "LazyLoad: yes"); the modified R code is only used if either of this command is given (followed by "library(foo)") after the new version of the package was installed. > So perhaps try detach(foo, unload = TRUE) or not using lazy-loading > when developing the package? Unfortunately, the former does not work and although the latter works I am hesitant to use it since: a) as I understand it, most packages that use S4 methods need lazy-loading (though the particular package with which I noticed the behaviour does not have S4 methods); and b) it seems that these days the DESCRIPTION file is the only way of switching lazy loading on and off and that there is no way of overriding that value. Knowing myself, I would forget changing the DESCRIPTION file back to "LazyLoad: yes" before building the .tar.gz file for distribution (once the package is ready). As it is, I have already to remember to take "-Wall -pedantic" out of the Makevars file in the src/ directory; but I am reminded of that by R CMD check. Well, thinking a bit more about b), I could probably complicate my Makefile a bit more such that a "make install" first modifies the DESCRIPTION file to "LazyLoad: no" before installing the package to the local library and that "make build" first modifies the DESCRIPTION in the opposite way. But this would still leave concern a). Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] vignette compilation times
G'day Robin,
On Thu, 19 Feb 2009 11:10:45 +
Robin Hankin wrote:
> I am preparing a number of vignettes that require a very long time to
> process with Sweave. The longest one takes 10 hours.
Is the sum of all chunks taking this time? Or is it mostly the code in
only a view chunks? And if so, are there chunks following that depend
on the result of these time-intensive chunks?
I wonder if it is feasible to construct your vignette according to the
lines.
1) have a file, say, vignette1.Rnw.in that contains:
#ifdef BUILDVERSION
you may want to try the commands
\begin{Sinput}
> command1
> command2
\end{Sinput}
but be aware that his might take a long time.
#else
Now we run the commands
<<>>=
command1
command2
@
#endif
--
2) Now construct a Makefile that, using a preprocesser like cpp,
produces vignette1.Rnw from vignette1.Rnw.in using the first version
before an "R CMD build" but otherwise (for your own testing) the
second version. Using .Rbuildignore, you can ensure that
vignett1.Rnw.in would not be distributed.
> I love the weaver package!
Thanks for pointing this package out. I was aware of cacheSweave, but
that package seems to require that each chunk has a label which I find
kind of inconvenient. weaver does not seem to have such a requirement.
Cheers,
Berwin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] vignette compilation times
G'day Gabor, On Thu, 19 Feb 2009 17:47:53 -0500 Gabor Grothendieck wrote: > [...] > Unless this has changed recently,I've tried including a PDF but it > does not appear in library(help = myPackage) nor on the CRAN site on > http://cran.r-project.org/package=myPackage > while Sweave'd PDFs do. If you want a PDF file to appear in library(help=myPackage), then you can write a vignette that just includes that PDF file via \includepdf from the LaTeX package(?) pdfpages. You will, of course, end up with two PDF files that are practically identical. So you might want to exclude the original PDF file from the build package via .Rbuildignore. If you do so, the next problem is that since R 2.6.0 "R CMD check" is trying to latex the vignette and not just checks the code in the vignette. And in current TeX systems latex will hang if \includepdf does not find the specified PDF file; latex does not stop with an error, it hangs. So the vignette has to be written smart enough to try to include the PDF file via \includepdf only if the file really exists, but that can easily be done. See the package lasso2 for an example. If you follow this set up, your PDF file will show up in library(help=myPackage) and your package will pass "R CMD check" on CRAN. HTH. Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] vignette compilation times
G'day Fritz, On Fri, 20 Feb 2009 12:46:49 +1100 Friedrich Leisch wrote: [...] > It is also unclear to me whether including a PDF without sources in a > GPLed package isn't a violation of the GPL (I know people who very > strongly think so). And source according to the GPL means "the > preferred form of the work for making modifications to it." So for a > PDF showing R output that would mean the text plus R code plus > data ... which boils down to XXXweave anyway. Well, GPL-2 says "This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License". I am somehow unable to locate the equivalent statement in GPL-3. Thus, under GPL-2, if the source that produces the PDF file does not contain a statement that it may be distributed under the terms of the GPL, then, in my understanding, you do not have to distribute the source. On occasions I wondered whether stating in the DESCRIPTION file that your package is GPL-2 extends this license to all other files and to those in inst/doc in particular. Or whether one should better slap a GPL-2 notice (or a GNU Free Documentation License) explicitly on the documentation. Actually, the fact that the GNU Free Documentation License exists makes me wonder whether it is tenable to apply GPL to documentation such as PDF files. But the phrase "or other work" in the above cite part of GPL-2 and the explicit `"The Program" refers to any copyrightable work' in GPL-3 seem to indicate that it is possible. Though, I guess you would still have to state *within* the (source of) vignette that it is under the GPL. But then IANAL. Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Semantics of sequences in R
G'day Stavros,
On Sun, 22 Feb 2009 16:50:13 -0500
Stavros Macrakis wrote:
> On Sun, Feb 22, 2009 at 4:12 PM, Duncan Murdoch
> wrote:
[]
> > Which ones in particular should change? What should they change
> > to? What will break when you do that?
>
> In many cases, the orthogonal design is pretty straightforward. And
> in the cases where the operation is currently an error (e.g.
> sort(list(...))), I'd hope that wouldn't break existing code. [...]
This could actually be an example that would break a lot of existing
code.
sort is a generic function, and for sort(list(...)) to work, it would
have to dispatch to a function called sort.list; and as Patrick Burns'
"The R Inferno" points out, such a function exists already and it is not
for sorting list.
In fact, currently you get:
R> cc <- list(a=runif(4), b=rnorm(6))
R> sort(cc)
Error in sort.list(cc) : 'x' must be atomic for 'sort.list'
Have you called 'sort' on a list?
Thus, to make sort(list()) work, you would have to rename the existing
sort.list and then change every call to that function to the new name.
I guess this might break quite a few packages on CRAN.
Cheers,
Berwin
=== Full address =
Berwin A TurlachTel.: +65 6516 4416 (secr)
Dept of Statistics and Applied Probability+65 6516 6650 (self)
Faculty of Science FAX : +65 6872 3919
National University of Singapore
6 Science Drive 2, Blk S16, Level 7 e-mail: sta...@nus.edu.sg
Singapore 117546http://www.stat.nus.edu.sg/~statba
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Semantics of sequences in R
On Mon, 23 Feb 2009 08:52:05 +0100 Wacek Kusnierczyk wrote: > Berwin A Turlach wrote: > > G'day Stavros, > > >> In many cases, the orthogonal design is pretty straightforward. > >> And in the cases where the operation is currently an error (e.g. > >> sort(list(...))), I'd hope that wouldn't break existing code. [...] > >> > > > > This could actually be an example that would break a lot of existing > > code. > > > > sort is a generic function, and for sort(list(...)) to work, it > > would have to dispatch to a function called sort.list; and as > > Patrick Burns' "The R Inferno" points out, such a function exists > > already and it is not for sorting list. > > > > and you mean that sort.list not being applicable to lists is a) good > design, and b) something that by noe means should be fixed, right? I neither said nor meant this and I do not see how what I said could be interpreted in such a way. I was just commenting to Stavros that the example he picked, hoping that it would not break existing code, was actually a bad one which potentially will break a lot (?) of existing code. Also, until reading Patrick Burns' "The R Inferno" I was not aware of sort.list. That function had not registered with me since I hardly used it. And I also have no need of calling sort() on lists. For em a lists is a flexible enough data structure such that defining a sort() command for them makes no sense; it could only work in very specific circumstances. > > In fact, currently you get: > > > > R> cc <- list(a=runif(4), b=rnorm(6)) > > R> sort(cc) > > Error in sort.list(cc) : 'x' must be atomic for 'sort.list' > > Have you called 'sort' on a list? > > > > one of the most funny error messages you get in r. note also that, > following rolf turner's lists and vectors unproven theorem, a vector > can be considered a list I do not remember the exact context of Rolf's comments, but I believe he was talking in a more general sense and not in technical terms. I find it perfectly valid, even when talking about R, to say something like "vectors are stored as a list of numbers in consecutive memory locations in memory". Clearly, in a phrase like this, we are not talking about "vectors" and "list" as defined by the "R Language Definition" or "R Internals", or what functions like is.vector(), is.list() &c return for various R objects. BTW, as I mentioned once before, you might want to consider to lose these chips on your shoulders. > -- hence sort.list should raise the error on any vector input, no? You will have to take that up with the designers of sort.list. > > Thus, to make sort(list()) work, you would have to rename the > > existing sort.list and then change every call to that function to > > the new name. I guess this might break quite a few packages on CRAN. > > > > scary! it's much preferred to confuse new users. I usually learn a lot when I get confused about some issues/concept. Confusion forces one to sit down, think deeply and, thus, gain some understanding. So I am not so much concerned with new users being confused. It is, of course, a problem if the new user never comes out of his or her confusion. Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Semantics of sequences in R
On Mon, 23 Feb 2009 11:31:16 +0100 Wacek Kusnierczyk wrote: > Berwin A Turlach wrote: > > On Mon, 23 Feb 2009 08:52:05 +0100 > > Wacek Kusnierczyk wrote: [...] > >> and you mean that sort.list not being applicable to lists is a) > >> good design, and b) something that by noe means should be fixed, > >> right? > > > > I neither said nor meant this and I do not see how what I said > > could be interpreted in such a way. I was just commenting to > > Stavros that the example he picked, hoping that it would not break > > existing code, was actually a bad one which potentially will break > > a lot (?) of existing code. > > would it, really? if sort.list were, in addition to sorting atomic > vectors (can-be-considered-lists), able to sort lists, how likely > would this be to break old code? Presumably not. > can you give one concrete example, and suggest how to estimate how > much old code would involve the same issue? Check out the svn source of R, run configure, do whatever change you want to sort.list, "make", "make check FORCE=FORCE". That should give you an idea how much would break. Additionally, you could try to install all CRAN packages with your modified version and see how many of them break when their examples/demos/&c is run. AFAIK, Brian is doing something like this on his machine. I am sure that if you ask nicely he will share his scripts with you. If this sounds too time consuming, you might just want to unpack the sources and grep for "sort.list" on all .R files; I am sure you know how to use find and grep to do this. > > Also, until reading Patrick Burns' "The R Inferno" I was not aware > > of sort.list. That function had not registered with me since I > > hardly used it. > > which hints that "potentially will break a lot (?) of existing code" > is a rather unlikely event. Only for code that I wrote; other people's need and knowledge of R may vary. > > And I also have no need of calling sort() on lists. For em a > > lists is a flexible enough data structure such that defining a > > sort() command for them makes no sense; it could only work in very > > specific circumstances. > > > > i don't understand the first part: "flexible enough data structure > such that defining a sort() command for them makes no sense" makes no > sense. lists are very flexible structure whose component must not be of equal type. So how do you want to compare components? How to you compare a vector of numbers to a vector of character strings? Or a list of lists? Or should the sorting be on the length of the components? Or their names? Or should sort(myList) sort each component of myList? But for that case we have already lapply(myList, sort). > as to "it could only work in very specific circumstances" -- no, it > would work for any list whatsoever, provided the user has a correctly > implemented comparator. for example, i'd like to sort a list of > vectors by the vectors' length -- is this a very exotic idea? No, if that is what you want. And I guess it is one way of sorting a list. The question is what should be the default way? > > BTW, as I mentioned once before, you might want to consider to lose > > these chips on your shoulders. > > > > berwin, it's been a tradition on this list to discourage people from > commenting on the design and implementation of r whenever they think > it's wrong. I am not aware of any such tradition and I subscribed to R-help on 15 April 1998. The point is rather that by commenting only one will not achieve much, in particular if the comments look more like complaints and the same comments are done again and again (along with dragging up previous comments or comments received on previous comments). R is open source. Check out the svn version, fix what you consider needs fixing, submit a patch, convince R core that the patch fixes a real problem/is an improvement/does not break too much. Then you have a better chance in achieving something. Alternatively, if it turns out that something that bugs you cannot be changed without breaking too much existing code, start from scratch that with a better design. Apparently the GAP project (http://www.gap-system.org/) is doing something like this, as someone closely associated with that project once told me. While developing a version of GAP they collect information on how to improve the design, data structures &c; then, at some point, they start to write the next version from scratch. > >> scary! it's much preferred to confuse new users. > > > > I usually learn a lot when I get confused about some issues/concept. > > Confusion for
Re: [Rd] [R] Semantics of sequences in R
On Mon, 23 Feb 2009 13:27:08 +0100 Wacek Kusnierczyk wrote: > Berwin A Turlach wrote: > > > > >> can you give one concrete example, and suggest how to estimate how > >> much old code would involve the same issue? > >> > > > > Check out the svn source of R, run configure, do whatever change you > > want to sort.list, "make", "make check FORCE=FORCE". That should > > give you an idea how much would break. > > > > it's not just making changes to sort.list, berwin. sort.list calls > .Internal order, and this one would have to be modified in order to > accommodate for the additional comparator argument. [...] Well, you could start of with an R only implementation and then start to move things to compiled code as needed for efficiency > > Additionally, you could try to install all CRAN packages with your > > modified version and see how many of them break when their > > examples/demos/&c is run. > > > > that's not a good benchmark; this are third-party stuff, and where > people are willing to rely on poor design they should be prepared to > suffer. [...] I do not believe that those developers are relying on poor design. Rather, they rely on things to work as documented (and how they are used for them to work) and that the behaviour is not gratuitously changed just because it is considered bad design by some. > [...] > judging from your question, you couldn't possibly see sorting routines > in other languages. Quite likely, or the other languages that I regularly use (C, Fortran) have even more primitive sorting facilities. [...] > > No, if that is what you want. And I guess it is one way of sorting > > a list. The question is what should be the default way? > > one possible answer is: none. (i have already given this answer > previously, if you read carefully it's still there). sort.list > *should* demand an additional comparator argument. at least, it > should demand it if the argument to be sorted is a list, rather than > a non-list vector (if you still need to use sort.list on non-lists). So when are you sending your patch to implement this facility? [...] > > The point is rather that by commenting only one will not achieve > > much, in particular if the comments look more like complaints and > > the same comments are done again and again (along with dragging up > > previous comments or comments received on previous comments). > > > > again and again because you seem to be immune to critique. You obviously do not know me. > open you mind, and it will suffice complain just once. besides, i am > certainly *not* just complaining. i am providing concrete arguments, > examples, and suggestions. you're being unreasonably unfair. I gladly admit that I am not reading every thread in which you are active, so these comments might have been based on a biased a sample. [...] > > R is open source. Check out the svn version, fix what you consider > > needs fixing, submit a patch, convince R core that the patch fixes a > > real problem/is an improvement/does not break too much. Then you > > have a better chance in achieving something. > > no, berwin. this is a serious bug in thinking. people should be > allowed -- *encouraged* -- to discuss the design *before* they even > attempt to write patches. And what makes you believe this is not the case? I have seen over the years e-mails to R-devel along the lines "I am thinking of a change along [lots of details and reasoning for the change]; would patches that implement this be accepted?" and these e-mails were discussed more often than not. However, in the end, the only people who can commit changes to the R code are the members of R-core, thus they will have the final word of design issues (and, as I assume, they discuss, among other things, design issues on the private mailing list of R-core member). But you can discuss this issues before writing a patch. > writing one patch which will never be considered -- well, never > responded to -- is about enough to stop people from sending patches. While it is unfortunate if this happens, and such persons might just be too thin-skinned, worse can happen; e.g. being flamed for sending in a patch that is considered not to address any problems and with a sloppy description of what it tries to address (happened to me). Yes, patches are ignored; patches are gratefully acknowledged and applied; patches are completely re-written and still attributed to the provider of the patch... That does not mean that I stop sending in a patch if I feel it is warranted... And I am sure that if you had sent an e-mail to r-devel pointing out that the binary operator &
Re: [Rd] [R] Semantics of sequences in R
On Mon, 23 Feb 2009 20:27:23 +0100 Wacek Kusnierczyk wrote: > Berwin A Turlach wrote: > >> [...] > >> judging from your question, you couldn't possibly see sorting > >> routines in other languages. > >> > > > > Quite likely, or the other languages that I regularly use (C, > > Fortran) have even more primitive sorting facilities. > > > > i apologize, [...] Apology accepted. [...] > >>> No, if that is what you want. And I guess it is one way of > >>> sorting a list. The question is what should be the default > >>> way? > >> one possible answer is: none. (i have already given this answer > >> previously, if you read carefully it's still there). sort.list > >> *should* demand an additional comparator argument. at least, it > >> should demand it if the argument to be sorted is a list, rather > >> than a non-list vector (if you still need to use sort.list on > >> non-lists). > > > > So when are you sending your patch to implement this facility? > > as i said, you seem to have a severe bug in thinking about > collaborative development. > > i am sending *no* patch for this. the issue has to be first discussed > on the design level, and only then, if accepted, should anyone -- me, > for example -- make an attempt to implement it. tell me you want to > listen to what i have to say, and we can discuss. I could tell you that I will listen and we can discuss this until the cows come home. This will not change one iota since neither of us have the power to implement changes in R. You keep barking up the wrong tree. So far I have seen only one posting of an R-core member in this thread (but perhaps he has started further discussion on the R-core mailing list to which we are not privy), but if you want to have discussion and acceptance before you do anything, you have to get R core involved. Since for the kind of work for which I am using R a facility for sorting lists is not crucial, I am rather indifferent about whether such a facility should exist and, if so, how it should be designed. > telling me i have a chip on my shoulder is rather unhelpful. Well, then stop acting as if you are running around with chips on your shoulders. Behaving in such a manner is rather counter productive in the R community (at least from my experience/observation). The same with publicly stating that you do certain things with the purpose of annoying certain persons. I am just pointing out that your behaviour is counter productive but it is really up to you on whether you change or want to continue in your ways. There is a nice German proverb that sums all this up "wie man in den Wald reinruft so schallt es heraus". Unfortunately, an equivalent English proverb does not exist, but perhaps the Norwegians have something similar > > > > >>> R is open source. Check out the svn version, fix what you > >>> consider needs fixing, submit a patch, convince R core that the > >>> patch fixes a real problem/is an improvement/does not break too > >>> much. Then you have a better chance in achieving something. > >>> > >> no, berwin. this is a serious bug in thinking. people should be > >> allowed -- *encouraged* -- to discuss the design *before* they even > >> attempt to write patches. > >> > > > > And what makes you believe this is not the case? I have seen over > > the years e-mails to R-devel along the lines "I am thinking of a > > change along [lots of details and reasoning for the change]; would > > patches that implement this be accepted?" and these e-mails were > > discussed more often than not. However, in the end, the only > > people who can commit changes to the R code are the members of > > R-core, thus they will have the final word of design issues (and, > > as I assume, they discuss, among other things, design issues on the > > private mailing list of R-core member). But you can discuss this > > issues before writing a patch. > > how many such mails have you seen? A few over the years, but the more R progresses/matures the less of such e-mail happens. > i've been on r-devel for six months, and haven't seen many. Well, six month is a rather narrow sampling window > on the other hand, i have seen quite a few responses that were > bashing a user for reporting a non-existent bug or submitting an > annoying patch. In didactic terms those are "negative motivations/reinforcements"; opinion differ on how effective they are to reach certain learning outcomes. > > And I am sure that if you had sent an e-mail to r-devel pointin
Re: [Rd] [R] Semantics of sequences in R
On Tue, 24 Feb 2009 09:39:51 +0100
Wacek Kusnierczyk wrote:
> Berwin A Turlach wrote:
[...]
> why not read some fortunes?
I am well aware of those fortunes and maybe you missed the one:
> fortune("Watson")
Getting flamed for asking dumb questions on a public mailing list is
all part of growing up and being a man/woman.
-- Michael Watson (in a discussion on whether answers on R-help
should be more polite)
R-help (December 2004)
I am actually wondering where the corresponding fortunes from December
2005, December 2006, December 2007 and December 2009 are since they
started of be produced on an annual basis.
[...]
> >> on the other hand, i have seen quite a few responses that were
> >> bashing a user for reporting a non-existent bug or submitting an
> >> annoying patch.
> >>
> >
> > In didactic terms those are "negative motivations/reinforcements";
> > opinion differ on how effective they are to reach certain learning
> > outcomes.
> >
>
> ah, so what's the difference between the way i pinpoint design flaws
> and the way r gurus respond to people, so that i am running with a
> chip on my shoulder, and they are being 'negatively
> motivating/reinforcing' in didactic terms? [...]
Your goal is, presumably, that you want to have the design flaws
fixed/discussed/&c. The goal of the R gurus is to avoid having to
waste their time on unproductive issues because people do not read
documentation/behave contrary to how they are asked to behave/&c.
To reach your goal, the controversial approach is counter productive.
To reach their goal, the controversial approach can be quite effective.
[...]
> >> it has been fixed immediately by martin.
> >>
> >
> > Yes, and, again, you could not help yourself telling the developers
> > what you think they should do, could you?
>
> was this really running with a chip:
Look up what "running with a chip on your shoulder means" and reflect
on the occasions in which I suggested to you that you give the
impression of doing so. On this occasion nobody said that you were
running around with a chip on your shoulder.
> "shouldn't the tests have captured it? i think you should have a check
> for every feature following from the docs."
>
> to which marting responded "yes, we should"
But he also made it clear that it would be unlikely that he or any
other R-core member would write those tests and that this would
probably be left to you; with any contribution being welcome. Consider
yourself lucky that this exchange was with Martin, other members of R
core might have communicated a similar message in quite another way.
That exchange is very much confirming my understanding of the culture
of the R community.
> > As I try to tell you, that
> > is not the way it works. R comes already with extensive tests that
> > are run with "make check". If you think some are missing, you
> > could send a script and propose that they are included. But
> > telling others that they should write such tests is unlikely to
> > make it happen.
>
> haven't done the thing.
Come on, read your own quote above: "Shouldn't the tests have captured
this? I think you should have a check for every feature following from
the docs", If this is not "telling others that they should write such
test", then what is?
Cheers,
Berwin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Semantics of sequences in R
G'day Dimitris, On Tue, 24 Feb 2009 11:19:15 +0100 Dimitris Rizopoulos wrote: > in my opinion the point of the whole discussion could be summarized > by the question, what is a design flaw? This is totally subjective, > and it happens almost everywhere in life. [...] Beautifully summarised and I completely agree. Not surprisingly, others don't. [...] > To close I'd like to share with you a Greek saying (maybe also a > saying in other parts of the world) that goes, for every rule there > is an exception. [...] As far as I know, the same saying exist in English. It definitely exist in German. Actually, in German it is "every rule has its exception including this rule". In German there is one grammar rule that does not have an exception. At least there used to be one; I am not really sure whether that rule survived the recent reform of the German grammar rules. Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug (PR#13570)
G'day Peter, On Thu, 05 Mar 2009 09:09:27 +0100 Peter Dalgaard wrote: > rha...@stat.purdue.edu wrote: > > <> > > > > This is a CRITICAL bug!!! I have verified it in R 2.8.1 for mac > > and for windows. The problem is with loess degree=0 smoothing. > > For example, try the following: > > > > x <- 1:100 > > y <- rnorm(100) > > plot(x, y) > > lines(predict(loess(y ~ x, degree=0, span=0.5))) > > > > This is obviously wrong. > > Obvious? How? I don't see anything particularly odd (on Linux). Neither did I on linux; but the OP mentioned mac and windows. On windows, on running that code, the lines() command added a lot of vertical lines; most spanning the complete window but some only part. Executing the code a second time (or in steps) gave sensible results. My guess would be that some memory is not correctly allocated or initialised. Or is it something like an object with storage mode "integer" being passed to a double? But then, why doesn't it show on linux? Happy bug hunting. If my guess is correct, then I have no idea how to track down such things under windows. Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] surprising behaviour of names<-
On Wed, 11 Mar 2009 20:31:18 +0100 Wacek Kusnierczyk wrote: > Simon Urbanek wrote: > > > > On Mar 11, 2009, at 10:52 , Simon Urbanek wrote: > > > >> Wacek, > >> > >> Peter gave you a full answer explaining it very well. If you really > >> want to be able to trace each instance yourself, you have to learn > >> far more about R internals than you apparently know (and Peter > >> hinted at that). Internally x=1 an x=c(1) are slightly different > >> in that the former has NAMED(x) = 2 whereas the latter has > >> NAMED(x) = 0 which is what causes the difference in behavior as > >> Peter explained. The reason is that c(1) creates a copy of the 1 > >> (which is a constant [=unmutable] thus requiring a copy) and the > >> new copy has no other references and thus can be modified and > >> hence NAMED(x) = 0. > >> > > > > Errata: to be precise replace NAMED(x) = 0 with NAMED(x) = 1 above > > -- since NAMED(c(1)) = 0 and once it's assigned to x it becomes > > NAMED(x) = 1 -- this is just a detail on how things work with > > assignment, the explanation above is still correct since > > duplication happens conditional on NAMED == 2. > > i guess this is what every user needs to know to understand the > behaviour one can observe on the surface? Nope, only users who prefer to write '+'(1,2) instead of 1+2, or 'names<-'(x, 'foo') instead of names(x)='foo'. Attempting to change the name attribute of x via 'names<-'(x, 'foo') looks to me as if one relies on a side effect of the function 'names<-'; which, in my book would be a bad thing. I.e. relying on side effects of a function, or writing functions with side effects which are then called for their side-effects; this, of course, excludes functions like plot() :) I never had the need to call 'names<-'() directly and cannot foresee circumstances in which I would do so. Plenty of users, including me, are happy using the latter forms and, hence, never have to bother with understanding these implementation details or have to bother about them. Your mileage obviously varies, but that is when you have to learn about these internal details. If you call functions because of their side-effects, you better learn what the side-effects are exactly. Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] surprising behaviour of names<-
On Wed, 11 Mar 2009 20:29:14 +0100 Wacek Kusnierczyk wrote: > Simon Urbanek wrote: > > Wacek, > > > > Peter gave you a full answer explaining it very well. If you really > > want to be able to trace each instance yourself, you have to learn > > far more about R internals than you apparently know (and Peter > > hinted at that). Internally x=1 an x=c(1) are slightly different in > > that the former has NAMED(x) = 2 whereas the latter has NAMED(x) = > > 0 which is what causes the difference in behavior as Peter > > explained. The reason is that c(1) creates a copy of the 1 (which > > is a constant [=unmutable] thus requiring a copy) and the new copy > > has no other references and thus can be modified and hence NAMED(x) > > = 0. > > > simon, thanks for the explanation, it's now as clear as i might > expect. > > now i'm concerned with what you say: that to understand something > visible to the user one needs to "learn far more about R internals > than one apparently knows". your response suggests that to use r > without confusion one needs to know the internals, Simon can probably speak for himself, but according to my reading he has not suggested anything similar to what you suggest he suggested. :) > and this would be a really bad thing to say.. No problems, since he did not say anything vaguely similar to what you suggest he said. Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] surprising behaviour of names<-
On Thu, 12 Mar 2009 10:05:36 +0100
Wacek Kusnierczyk wrote:
> well, as far as i remember, it has been said on this list that in r
> the infix syntax is equivalent to the prefix syntax, [...]
Whoever said that must have been at that moment not as precise as he or
she could have been. Also, R does not behave according to what people
say on this list (which is good, because some times people they wrong
things on this list) but according to how it is documented to do; at
least that is what people on this list (and others) say. :)
And the R Language manual (ignoring for the moment that it is a draft
and all that), clearly states that
names(x) <- c("a","b")
is equivalent to
'*tmp*' <- x
x <- "names<-"('*tmp*', value=c("a","b"))
[...]
> well, i can imagine a user using the prefix 'names<-' precisely under
> the assumption that it will perform functionally;
You mean
y <- 'names<-'(x, "foo")
instead of
y <- x
names(y) <- "foo"
?
Fair enough. But I would still prefer the latter version this it is
(for me) easier to read and to decipher the intention of the code.
> i.e., 'names<-'(x, 'foo') will always produce a copy of x with the
> new names, and never change the x.
I am not sure whether R ever behaved in that way, but as Peter pointed
out, this would be quite undesirable from a memory management and
performance point of view. Image that every time you modify a (name)
component of a large object a new copy of that object is created.
> cheers, and thanks for the discussion.
You are welcome.
Cheers,
Berwin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] surprising behaviour of names<-
On Thu, 12 Mar 2009 10:53:19 +0100
Wacek Kusnierczyk wrote:
> well, ?'names<-' says:
>
> "
> Value:
> For 'names<-', the updated object.
> "
>
> which is only partially correct, in that the value will sometimes be
> an updated *copy* of the object.
But since R supposedly uses call-by-value (though we know how to
circumvent that, don't we?) wouldn't you always expect that a copy of
the object is returned?
> > And the R Language manual (ignoring for the moment that it is a
> > draft and all that),
>
> since we must...
>
> > clearly states that
> >
> > names(x) <- c("a","b")
> >
> > is equivalent to
> >
> > '*tmp*' <- x
> > x <- "names<-"('*tmp*', value=c("a","b"))
> >
>
> ... and?
This seems to suggest that in this case the infix and prefix syntax
is not equivalent as it does not say that
names(x) <- c("a","b")
is equivalent to
x <- "names<-"(x, value=c("a","b"))
and I was commenting on the claim that the infix syntax is equivalent
to the prefix syntax.
> does this say anything about what 'names<-'(...) actually
> returns? updated *tmp*, or a copy of it?
Since R uses pass-by-value, you would expect the latter, wouldn't
you? If you entertain the idea that 'names<-' updates *tmp* and
returns the updated *tmp*, then you believe that 'names<-' behaves in a
non-standard way and should take appropriate care.
And the fact that a variable *tmp* is used hints to the fact that
'names<-' might have side-effect. If 'names<-' has side effects,
then it might not be well defined with what value x ends up with if
one executes:
x <- 'names<-'(x, value=c("a","b"))
This is similar to the discussion what value i should have in the
following C snippet:
i = 0;
i += i++;
[..]
> > I am not sure whether R ever behaved in that way, but as Peter
> > pointed out, this would be quite undesirable from a memory
> > management and performance point of view.
>
> why? you can still use the infix names<- with destructive semantics
> to avoid copying.
I guess that would require a rewrite (or extension) of the parser. To
me, Section 10.1.2 of the Language Definition manual suggests that once
an expression is parsed, you cannot distinguish any more whether
'names<-' was called using infix syntax or prefix syntax.
Thus, I guess you want to start a discussion with R Core whether it is
worthwhile to change the parser such that it keeps track on whether a
function was used with infix notation or prefix notation and to
provide for most (all?) assignment operators implementations that use
destructive semantics if the infix version was used and always copy if
the prefix notation is used.
Cheers,
Berwin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] surprising behaviour of names<-
On Thu, 12 Mar 2009 15:21:50 +0100
Wacek Kusnierczyk wrote:
[...]
> >>> And the R Language manual (ignoring for the moment that it is a
> >>> draft and all that),
> >>>
> >> since we must...
> >>
> >>
> >>> clearly states that
> >>>
> >>> names(x) <- c("a","b")
> >>>
> >>> is equivalent to
> >>>
> >>> '*tmp*' <- x
> >>> x <- "names<-"('*tmp*', value=c("a","b"))
> >>>
> >>>
> >> ... and?
> >>
> >
> > This seems to suggest
>
> seems to suggest? is not the purpose of documentation to clearly,
> ideally beyond any doubt, specify what is to be specified?
The R Language Definition manual is still a draft. :)
> > that in this case the infix and prefix syntax
> > is not equivalent as it does not say that
> >
>
> are you suggesting fortune telling from what the docs do *not* say?
My experience is that sometimes you have to realise what is not
stated. I remember a discussion with somebody who asked why he could
not run, on windows, R CMD INSTALL on a *.zip file. I pointed out to
him that the documentation states that you can run R CMD INSTALL on
*.tar.gz or *.tgz files and, thus, there should be no expectation that
it can be run on *.zip file.
YMMV, but when I read a passage like this in R documentation, I start
to wonder why it is stated that
names(x) <- c("a","b")
is equivalent to
*tmp* <- x
x <- "names<-"('*tmp*', value=c("a","b"))
and the simpler construct
x <- "names<-"(x, value=c("a", "b"))
is not used. There must be a reason, nobody likes to type
unnecessarily long code. And, after thinking about this for a while,
the penny might drop.
[...]
> >> does this say anything about what 'names<-'(...) actually
> >> returns? updated *tmp*, or a copy of it?
> >>
> >
> > Since R uses pass-by-value,
>
> since? it doesn't!
For all practical purposes it is as long as standard evaluation is
used. One just have to be aware that some functions evaluate their
arguments in a non-standard way.
[...]
> > If you entertain the idea that 'names<-' updates *tmp* and
> > returns the updated *tmp*, then you believe that 'names<-' behaves
> > in a non-standard way and should take appropriate care.
>
> i got lost in your argumentation. [..]
I was commenting on "does this say anything about what 'names<-'(...)
actually returns? updated *tmp*, or a copy of it?"
As I said, if you entertain the idea that 'names<-' returns an updated
*tmp*, then you believe that 'names<-' behaves in a non-standard way
and appropriate care has to be taken.
> > And the fact that a variable *tmp* is used hints to the fact that
> > 'names<-' might have side-effect.
>
> are you suggesting fortune telling from the fact that a variable *tmp*
> is used?
Nothing to do with fortune telling. One reads the manual, one wonders
why is this construct used instead of an apparently much more simple
one, one reflects and investigates, one realises why the given
construct is stated as the equivalent: because "names<-" has
side-effects.
> > This is similar to the discussion what value i should have in the
> > following C snippet:
> > i = 0;
> > i += i++;
> >
>
> nonsense, it's a *completely* different issue. here you touch the
> issue of the order of evaluation, and not of whether an object is
> copied or modified; above, the inverse is true.
Sorry, there was a typo above. The second statement should have been
i = i++;
Then on some abstract level they are the same; an object appears on the
left hand side of an assignment but is also modified in the expression
assigned to it. So what value should it end up with?
> >> why? you can still use the infix names<- with destructive
> >> semantics to avoid copying.
> >>
> >
> > I guess that would require a rewrite (or extension) of the parser.
> > To me, Section 10.1.2 of the Language Definition manual suggests
> > that once an expression is parsed, you cannot distinguish any more
> > whether 'names<-' was called using infix syntax or prefix syntax.
> >
>
> but this must be nonsense, since:
>
> x = 1
> 'names<-'(x, 'foo')
> names(x)
> # NULL
>
> x = 1
> names(x) <- 'foo'
> names(x)
> # "foo"
>
> clearly, there is not only syntactic difference here. but it might be
> that 10.1.2 does not suggest anything like what you say.
Please tell me how this example contradicts my reading of 10.1.2 that
the expressions
'names<-'(x, 'foo')
and
names(x) <- 'foo'
once they are parsed, produce exactly the same parse tree and that it
becomes impossible to tell from the parse tree whether originally the
infix syntax or the prefix syntax was used. In fact, the last sentence
in section 10.1.2 strongly suggests to me that the parse tree stores
all function calls as if prefix notation was used. But it is probably
my English again.
> > Thus, I guess you want to start a discussion with R Core whether it
> > is worthwhile to change t
Re: [Rd] surprising behaviour of names<-
On Thu, 12 Mar 2009 21:26:15 +0100
Wacek Kusnierczyk wrote:
> > YMMV, but when I read a passage like this in R documentation, I
> > start to wonder why it is stated that
> > names(x) <- c("a","b")
> > is equivalent to
> > *tmp* <- x
> > x <- "names<-"('*tmp*', value=c("a","b"))
> > and the simpler construct
> > x <- "names<-"(x, value=c("a", "b"))
> > is not used. There must be a reason,
>
> got an explanation: because it probably is as drafty as the
> aforementioned document.
Your grasp of what "draft manual" means in the context of R
documentation seems to be as tenuous as the grasp of intelligent
design/creationist proponents on what it means in science to label a
body of knowledge a "(scientific) theory". :)
[...]
> but it is possible to send an argument to a function that makes an
> assignment to the argument, and yet the assignment is made to the
> original, not to a copy:
>
> foo = function(arg) arg$foo = foo
>
> e = new.env()
> foo(e)
> e$foo
>
> are you sure this is pass by value?
But that is what environments are for, aren't they? And it is
documented behaviour. Read section 2.1.10 ("Environments") in the R
Language Definition, in particular the last paragraph:
Unlike most other R objects, environments are not copied when
passed to functions or used in assignments. Thus, if you assign the
same environment to several symbols and change one, the others will
change too. In particular, assigning attributes to an environment can
lead to surprises.
[..]
> and actually, in the example we discuss, 'names<-' does *not* return
> an updated *tmp*, so there's even less to entertain.
How do you know? Are you sure? Have you by now studied what goes on
under the hood?
> for fun and more guesswork, the example could have been:
>
> x = x
> x = 'names<-'(x, value=c('a', 'b'))
But it is manifestly not written that way in the manual; and for good
reasons since 'names<-' might have side effects which invokes in the
last line undefined behaviour. Just as in the equivalent C snippet
that I mentioned.
> for your interest in well written documentation, ?names says that the
> argument x is 'an r object', and nowhere does it say that environment
> is not an r object. it also says what the value of 'names<-' applied
> to pairlists is. the following error message is doubly surprising:
>
> e = new.env()
> 'names<-'(e, 'foo')
> # Error: names() applied to a non-vector
But names are implemented by assigning a "name" attribute to the
object; as you should know. And the above documentation suggests that
it is not a good idea to assign attributed to environments. So why
would you expect this to work?
> firstly, because it would seem that there's nothing wrong in applying
> names to an environment; from ?'$':
>
> "
> x$name
>
> name: A literal character string or a name (possibly backtick
> quoted). For extraction, this is normally (see under
> 'Environments') partially matched to the 'names' of the
> object.
> "
I fail to see the relevance of this.
> secondly, because, as ?names says, names can be applied to pairlists,
Yes, but it does not say that names can be applied to environment.
And it explicitly says that the "default methods get and set the
'"name"' attribute of..." and (other) documentation warns you about
setting attributes on environments.
> which are not vectors, and the following does not give an error as
> above:
>
> p = pairlist()
> is.vector(p)
> # FALSE
> names(p)
> # names successfully applied to a non-vector
>
> assure me this is not a mess, but a well-documented design feature.
It is documented, if it is well-documented depends on your definition
of "well-documented". :)
> ... and one wonders why r man pages have to be read in O(e^n) time.
I believe patches to documentation are also welcome; and perhaps more
readily accepted than patches to code.
[...]
> >>> I guess that would require a rewrite (or extension) of the parser.
> >>> To me, Section 10.1.2 of the Language Definition manual suggests
> >>> that once an expression is parsed, you cannot distinguish any more
> >>> whether 'names<-' was called using infix syntax or prefix syntax.
> >>>
> >>>
> >> but this must be nonsense, since:
> >>
> >> x = 1
> >> 'names<-'(x, 'foo')
> >> names(x)
> >> # NULL
> >>
> >> x = 1
> >> names(x) <- 'foo'
> >> names(x)
> >> # "foo"
> >>
> >> clearly, there is not only syntactic difference here. but it
> >> might be that 10.1.2 does not suggest anything like what you say.
> >>
> >
> > Please tell me how this example contradicts my reading of 10.1.2
> > that the expressions
> > 'names<-'(x, 'foo')
> > and
> > names(x) <- 'foo'
> > once they are parsed, produce exactly the same parse tree and that
> > it becomes impossible to tell from the parse tree whether
> > originally the infix syntax or
Re: [Rd] surprising behaviour of names<-
On Fri, 13 Mar 2009 11:43:55 +0100
Wacek Kusnierczyk wrote:
> Berwin A Turlach wrote:
>
> > And it is documented behaviour.
>
> sure!
Glad to see that we agree on this.
> > Read section 2.1.10 ("Environments") in the R
> > Language Definition,
>
> haven't objected to that. i object to your 'r uses pass by value',
> which is only partially correct.
Well, I used qualifiers and did not stated it categorically.
> >> and actually, in the example we discuss, 'names<-' does *not*
> >> return an updated *tmp*, so there's even less to entertain.
> >>
> >
> > How do you know? Are you sure? Have you by now studied what goes
> > on under the hood?
>
> yes, a bit. but in this example, it's enough to look into *tmp* to
> see that it hasn't got the names added, and since x does have names,
> names<- must have returned a copy of *tmp* rather than *tmp* changed:
>
> x = 1
> tmp = x
> x = 'names<-'(tmp, 'foo')
> names(tmp)
> # NULL
Indeed, if you type these two commands on the command line, then it is
not surprising that a copy of tmp is returned since you create a
temporary object that ends up in the symbol table and persist after the
commands are finished.
Obviously, assuming that R really executes
*tmp* <- x
x <- "names<-"('*tmp*', value=c("a","b"))
under the hood, in the C code, then *tmp* does not end up in the symbol
table and does not persist beyond the execution of
names(x) <- c("a","b")
This looks to me as one of the situations where a value of 1 is used
for the named field of some of the objects involves so that a copy can
be avoided. That's why I asked whether you looked under the hood.
> you suggested that "One reads the manual, (...) one reflects and
> investigates, ..."
Indeed, and I am not giving up hope that one day you will master this
art.
> -- had you done it, you wouldn't have asked the question.
Sorry, I forgot that you have a tendency to interpret statements
extremely verbatim and with little reference to the context in which
they are made. I will try to be more explicit in future.
> >> for fun and more guesswork, the example could have been:
> >>
> >> x = x
> >> x = 'names<-'(x, value=c('a', 'b'))
> >>
> >
> > But it is manifestly not written that way in the manual; and for
> > good reasons since 'names<-' might have side effects which invokes
> > in the last line undefined behaviour. Just as in the equivalent C
> > snippet that I mentioned.
>
> i just can't get it why the manual does not manifestly explain what
> 'names<-' does, and leaves you doing the guesswork you suggest.
As I said before, patched to documentation are also welcome.
Best wishes,
Berwin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
