Re: [Rd] Petition to set warnPartialMatch* options to TRUE

[Kurt Hornik]

> Therneau, Terry M , Ph D writes:

> Let me give partial assent to Michael's suggestion:  a) have an easy way to
> turn this on and b) add a strong suggestion to do so to the WRE manual.   
> Kurt's example in the email shows how to do (a);  but I just looked in the
> WRE manual and don't see any reference to it, nor any mention from R CMD
> check --help, so I don't know where I would have found out about it.

> I have gotton warnings about partial matches from CRAN  wrt the survival
> package --- I suspect at the benefit of Kurt  --- and though I muttered under
> my breath about it at the time there is no doubt that it was a good idea to
> fix all of them, and I'm glad for the nudge.

> Kurt: does that envionment variable contain the options string itself, or
> does it point to a file containing the options?

The latter: one can use _R_CHECK_EXAMPLES_PROFILE_ to point to a profile
containing e.g.

options(warnPartialMatchArgs = TRUE,
warnPartialMatchAttr = TRUE,
warnPartialMatchDollar = TRUE,
showErrorCalls = TRUE,
showWarnCalls = TRUE)

Best
-k

> I appreciate partial matching when typing code at the terminal so want the
> feature to remain in that context.

> Terry T

> -- 
> Terry M Therneau, PhD
> Department of Quantitative Health Sciences
> Mayo Clinic
> thern...@mayo.edu

> "TERR-ree THUR-noh"

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] max on numeric_version with long components

[Kurt Hornik]

> Kurt Hornik writes:

Should be fixed now.

Best
-k

> Ivan Krylov via R-devel writes:
> Indeed, apparently using which.min/which.max on the string encoding is
> not good enough.  ? which.min says that x can also be

>   an R object for which the internal coercion to ‘double’ works 

> and I guess we found a case where it does not work.

> I'll look into fixing this, but perhaps we should re-open
>  ?

> -k

>> В Sat, 27 Apr 2024 13:56:58 -0500
>> Jonathan Keane  пишет:

>>> In devel:
>>> > max(numeric_version(c("1.0.1.1", "1.0.3.1",  
>>> "1.0.2.1")))
>>> [1] ‘1.0.1.1’
>>> > max(numeric_version(c("1.0.1.1000", "1.0.3.1000",  
>>> "1.0.2.1000")))
>>> [1] ‘1.0.3.1000’

>> Thank you Jon for spotting this!

>> This is an unintended consequence of
>> https://bugs.r-project.org/show_bug.cgi?id=18697.

>> The old behaviour of max() was to call
>> which.max(xtfrm(x)), which first produced a permutation that sorted the
>> entire .encode_numeric_version(x). The new behavioiur is to call
>> which.max directly on .encode_numeric_version(x), which is faster (only
>> O(length(x)) instead of a sort).

>> What do the encoded version strings look like?

>> x <- numeric_version(c(
>> "1.0.1.1", "1.0.3.1", "1.0.2.1"
>> ))
>> # Ignore the attributes
>> (e <- as.vector(.encode_numeric_version(x)))
>> # [1] "101575360400"
>> # [2] "103575360400"
>> # [3] "102575360400"

>> # order(), xtfrm(), sort() all agree that e[2] is the maximum:
>> order(e)
>> # [1] 1 3 2
>> xtfrm(e)
>> # [1] 1 3 2
>> sort(e)
>> # [1] "101575360400"
>> # [2] "102575360400"
>> # [3] "103575360400"

>> # but not which.max:
>> which.max(e)
>> # [1] 1

>> This happens because which.max() converts its argument to double, which
>> loses precision:

>> (n <- as.numeric(e))
>> # [1] 1e+27 1e+27 1e+27
>> identical(n[1], n[2])
>> # [1] TRUE
>> identical(n[3], n[2])
>> # [1] TRUE

>> Will be curious to know if there is a clever way to keep both the O(N)
>> complexity and the full arbitrary precision.

>> -- 
>> Best regards,
>> Ivan

>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel

> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel