On 13-07-15 1:02 AM, Justin Talbot wrote:> The pmatch help (see also section 4.3.2 in the R Language Definition)
> claims that pmatch with duplicates.ok=FALSE provides the same
> functionality as R's argument matching algorithm, modulo how empty
> strings are matched.
>
> Here's an undocumented inconsistency between pmatch and R's
argument
> matching algorithm:
>
>> sessionInfo()
> R version 3.0.1 (2013-05-16)
> Platform: x86_64-apple-darwin10.8.0 (64-bit)
>
> locale:
> [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
>> f <- function(abc, ax) 1
>> f(ab=1,a=10)
> Error in f(ab = 1, a = 10) :
> formal argument "abc" matched by multiple actual arguments
>
>> pmatch(c('ab','a'), c('abc', 'ax'),
duplicates.ok=FALSE)
> [1] 1 2
>
> That is, pmatch doesn't consider ambiguous partial matches to be an
> error if the ambiguity is resolved by an earlier partial match.
>
> This leads to an order dependency in pmatch that doesn't happen with
> argument matching:
>
>> pmatch(c('ab','a'), c('abc', 'ax'),
duplicates.ok=FALSE)
> [1] 1 2
>
>> pmatch(c('a','ab'), c('abc', 'ax'),
duplicates.ok=FALSE)
> [1] NA 1
>
> It would be great if this were documented.
Or should it be made consistent? Is there any value in keeping the
current pmatch behaviour different from the argument matching?
>
> At a higher level, is pmatch intended to be the same as the argument
> matching algorithm or is it just supposed to be "close"?
I would take that line in the documentation to say it is intended to be
the same except for empty strings.
Duncan Murdoch