Hello,
I am a new on this list, so I introduce myself very briefly:
my background is applied mathematics, more precisely scientific calculus
applied for modeling metabolic systems, I am author/maintainer of
few packages (Deriv, rmumps, arrApply).
Now, on the subject of this discussion, I must say that I don't really
understand
Peter's argument:
>>> To do it differently, you would have to do something like
>>>
>>> dots <- match.call(expand.dots=FALSE)$...
>>>
>>> and then explicitly evaluate each argument in turn in the caller
>>> frame. This amount of nonstandard evaluation sounds like it would
>>> incur a performance penalty, which could be undesirable.
The first line of the current stopifnot()
n <- length(ll <- list(...))
already evaluates _all_ of the arguments
in the caller frame. So to do the same only
on a part of them (till the first FALSE or NA occurs)
cannot be more penalizing than the current version, right?
I attach here a slightly modified version called stopifnot_new()
which works in accordance with the man page and
where there are only two additional calls: parent.frame() and eval().
I don't think it can be considered as real performance penalty
as the same or bigger amount of (implicit) evaluations was
already done in the current version:
source("stopifnot_new.R")
stopifnot_new(3 == 5, as.integer(2^32), a <- 12)
Error: 3 == 5 is not TRUE
a
Error: object 'a' not found
Best,
Serguei.
Le 15/05/2017 à 10:39, Martin Maechler a écrit :
Hervé Pagès <hpa...@fredhutch.org>
on Wed, 3 May 2017 12:08:26 -0700 writes:
> On 05/03/2017 12:04 PM, Hervé Pagès wrote:
>> Not sure why the performance penalty of nonstandard evaluation would
>> be more of a concern here than for something like switch().
> which is actually a primitive. So it seems that there is at least
> another way to go than 'dots <- match.call(expand.dots=FALSE)$...'
> Thanks, H.
>>
>> If that can't/won't be fixed, what about fixing the man page so it's
>> in sync with the current behavior?
>>
>> Thanks, H.
Being back from vacations,...
I agree that something should be done here, if not to the code than at
least to the man page.
For now, I'd like to look a bit longer into a possible change to the function.
Peter mentioned a NSE way to fix the problem and you mentioned switch().
Originally, stopifnot() was only a few lines of code and meant to be
"self-explaining" by just reading its definition, and I really would like
to not walk too much away from that original idea.
How did you (Herve) think to use switch() here?
>> On 05/03/2017 02:26 AM, peter dalgaard wrote:
>>> The first line of stopifnot is
>>>
>>> n <- length(ll <- list(...))
>>>
>>> which takes ALL arguments and forms a list of them. This implies
>>> evaluation, so explains the effect that you see.
>>>
>>> To do it differently, you would have to do something like
>>>
>>> dots <- match.call(expand.dots=FALSE)$...
>>>
>>> and then explicitly evaluate each argument in turn in the caller
>>> frame. This amount of nonstandard evaluation sounds like it would
>>> incur a performance penalty, which could be undesirable.
>>>
>>> If you want to enforce the order of evaluation, there is always
>>>
>>> stopifnot(A) stopifnot(B)
>>>
>>> -pd
>>>
>>>> On 3 May 2017, at 02:50 , Hervé Pagès <hpa...@fredhutch.org>
>>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> It's surprising that stopifnot() keeps evaluating its arguments
>>>> after it reaches the first one that is not TRUE:
>>>>
>>>> > stopifnot(3 == 5, as.integer(2^32), a <- 12) Error: 3 == 5 is
>>>> not TRUE In addition: Warning message: In stopifnot(3 == 5,
>>>> as.integer(2^32), a <- 12) : NAs introduced by coercion to integer
>>>> range > a [1] 12
>>>>
>>>> The details section in its man page actually suggests that it
>>>> should stop at the first non-TRUE argument:
>>>>
>>>> ‘stopifnot(A, B)’ is conceptually equivalent to
>>>>
>>>> { if(any(is.na(A)) || !all(A)) stop(...); if(any(is.na(B)) ||
>>>> !all(B)) stop(...) }
>>>>
>>>> Best, H.
>>>>
>>>> --
>>>> Hervé Pagès
>>>>
>>>> Program in Computational Biology Division of Public Health
>>>> Sciences Fred Hutchinson Cancer Research Center 1100 Fairview
>>>> Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024
>>>>
>>>> E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax: (206)
>>>> 667-1319
>>>>
>>>> ______________________________________________
>>>> R-devel@r-project.org mailing list
>>>>
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel&d=DwIFaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=JwgKhKD2k-9Kedeh6pqu-A8x6UEV0INrcxcSGVGo3Tg&s=f7IKJIhpRNJMC3rZAkuI6-MTdL3GAKSV2wK0boFN5HY&e=
>>>>
>>>
>>
> -- Hervé Pagès
> Program in Computational Biology Division of Public Health Sciences
> Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N,
> M1-B514 P.O. Box 19024 Seattle, WA 98109-1024
> E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax: (206)
> 667-1319
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
