Re: [Rd] body(NULL) <- something; ditto formals() -- should not work
> Hervé Pagès
> on Tue, 29 Mar 2016 12:19:12 -0700 writes:
> Hi,
> On 03/07/2016 09:26 AM, Martin Maechler wrote:
>> I'm proposing to signal an error (from R >= 3.3.0) in such
>> examples -- which do "work" in R 3.2.x and earlier :
>>
>>> f <- NULL; body(f) <- quote(sin(a+1)); f
>> function ()
>> sin(a + 1)
>>
>>
> This works because formals() (the getter) works on things that are
> not a function.
>>> g <- NULL; formals(g) <- alist(x = pi, y=); g
>> function (x = pi, y)
>> NULL
>>
>>>
> And this works because body() (the getter) also works on things that
> are not a function.
of course (twice).
>> The proposal is that the underlying C code will signal an error
>> when such replacement functions would create a function out of
>> "something not a function".
> Why modify the C code for this?
My current proposal would change both the C code *and* the following.
> This is how formals() and body() are defined at the moment:
>> formals
> function (fun = sys.function(sys.parent()))
> {
> if (is.character(fun))
> fun <- get(fun, mode = "function", envir = parent.frame())
> .Internal(formals(fun))
> }
>
>
>> body
> function (fun = sys.function(sys.parent()))
> {
> if (is.character(fun))
> fun <- get(fun, mode = "function", envir = parent.frame())
> .Internal(body(fun))
> }
>
>
> Not sure why they are not simply doing fun <- match.fun(fun) but if
> they were, then they would signal an error when called on something
> that is not a function.
Using match.fun() will probably be "the right thing" in the
future.
However, as this has been an unchanged part of R for very many years,
my current proposal would only signal *warnings* for now.
Thank you, Herve, for the reminder about this. Indeed, I *have*
been wanting to commit my proposal to R-devel for a long time
and somehow have always been anxious to produce too many
negative effects with CRAN / Bioconductor packages producing
warning (or errors) after the change and me not having the time
to send e-mails to all the package maintainers.
As I won't have time for that anyway, and as "good package
maintainers" should at least browse, if not read the R-devel
mailing list (;-),
your prompting now makes me commit my proposal (to R-devel only;
*not* R 3.4.0 alpha) and leave the resulting "problems" to the
package maintainers affected.
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] reg-tests-1a fails with r70391
Hi, This may be a `transitional' bug but I am reporting a make check fail with R-devel r70391 in reg-tests-1a.Rout. The tail of reg-tests-1a.Rout.fail is > ## prcomp(tol=1e-6) > x <- matrix(runif(30),ncol=10) > s <- prcomp(x, tol=1e-6) > stopifnot(length(s$sdev) == ncol(s$rotation)) Error: length(s$sdev) == ncol(s$rotation) is not TRUE Execution halted Looking at stats:::prcomp.default(), it appears that s$v is truncated but not s$d (unlike in the code before r70391) for the reduced rank case. h. -- +--- | Hiroyuki Kawakatsu | Business School, Dublin City University | Dublin 9, Ireland. Tel +353 (0)1 700 7496 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] reg-tests-1a fails with r70391
> Hiroyuki Kawakatsu > on Wed, 30 Mar 2016 09:27:16 +0100 writes: > Hi, This may be a `transitional' bug but I am reporting a > make check fail with R-devel r70391 in > reg-tests-1a.Rout. The tail of reg-tests-1a.Rout.fail is >> ## prcomp(tol=1e-6) x <- matrix(runif(30),ncol=10) s <- >> prcomp(x, tol=1e-6) stopifnot(length(s$sdev) == >> ncol(s$rotation)) > Error: length(s$sdev) == ncol(s$rotation) is not TRUE > Execution halted > Looking at stats:::prcomp.default(), it appears that s$v > is truncated but not s$d (unlike in the code before > r70391) for the reduced rank case. Exactly. I had this in the list of changes to be committed in r70391, but not on the computer I did commit. The 'transitional' period (above) has terminated 2 minutes ago. Thank you, Hiroyuki for the reminder. Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] documentation / warning when passing a vector as lower/upper bound in stats::integrate()
> Baptiste Auguie > on Tue, 29 Mar 2016 19:31:02 +1300 writes: > Dear R-dev list, > I wonder if stats::integrate shouldn't warn the user when a numeric vector > of length > 1 is passed as lower or upper bounds. If a vector is passed, > only the first value is used and the others are silently ignored: > integrate(sin, lower=0, upper=pi) > integrate(sin, lower=0:10, upper=pi) > ?integrate doesn't appear to mention explicitly that the function is not > vectorised over those arguments. well, that's not true: Almost the very first text on the help is the description and that already *does* say so : > Description: > Adaptive quadrature of functions of one variable over a finite or > infinite interval. "a .. interval" is singular, ... and then there are 14 examples, all using one interval... *AND* one of them showing that you need to use *integrands* which are vectorized. So to me, it seems pretty bizarre that anyone assumes lower or upper should be allowed to be vectors after reading the help page. R users not reading the help page of a function after having problems or being puzzled about it should not be allowed to post anywhere publicly on the internet ;-) > It's probably not a common mistake, I think so, too !! > consequences in the iterative calculation of multiple integrals. Someone > was puzzled by this today (http://stackoverflow.com/q/36275909/471093) and > it wasn't immediately obvious what had led to incorrect results (and worse, > it could have gone unnoticed). I agree here. Note however that checking for user errors always comes with a small performance penalty and so, programmers traditionally have liked to deal with such problems by keeping the code optimally fast... If I remember the many silly performance comparisons of R with X (notably with 'X' being a compiled language) and all the bad propaganda of "R is slow", when much of that relative slowness is because S and R have always aimed to be safe rather than fast, I am sometimes reluctant to add yet another test for user error.. but of course still agree we should do it. Just think about the issue, next time someone tells you how much faster his C++ / ... code is compared to plain R.. Martin > Best regards, > baptiste __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
