Something definitely looks odd... I certain can't think of a reason why the
behaviour would be keyed to the _size_ of the first argument like this:
> pmatch(as.character(x)[1:100], as.character(x))
[1] 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
[19] 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36
[37] 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54
[55] 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72
[73] 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90
[91] 91 92 93 94 95 96 97 98 99 100> pmatch(as.character(x)[1:101], as.character(x))
[1] 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
[19] 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36
[37] 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 NA NA NA
[55] NA NA 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72
[73] 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90
[91] 91 92 93 94 95 96 97 98 99 100 101> pmatch(as.character(x)[2:102], as.character(x))
[1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
[19] 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37
[37] 38 39 40 41 42 43 44 45 46 47 48 49 50 51 1 NA NA NA
[55] NA 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73
[73] 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91
[91] 92 93 94 95 96 97 98 99 100 101 102> > pmatch(as.character(x)[3:102], as.character(x))
[1] 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
[19] 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38
[37] 39 40 41 42 43 44 45 46 47 48 49 50 51 1 2 54 55 56
[55] 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74
[73] 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92
[91] 93 94 95 96 97 98 99 100 101 102
It's happening in the C code, though, so some poking around is required.
- pd
> On 15 Jun 2026, at 22.14, Duncan Murdoch <murdoch.duncan at
gmail.com> wrote:
>
> I think your example is overly complicated. Wouldn't it be enough to
show one vector that gives a bad result? For example:
>
> x <- c(1:51, 1:51)
> pmatch(x, x)
>
> which gives
>
> [1] 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
19 20 21 22 23 24 25 26 27 28 29
> [30] 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47
48 49 50 51 NA NA NA NA NA 57 58
> [59] 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76
77 78 79 80 81 82 83 84 85 86 87
> [88] 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102
>
> (with the NAs showing up at locations 52 to 56).
>
> I'm not 100% sure that's a bug, since the documentation for pmatch
doesn't discuss what should happen if table (the second argument) contains
duplicates. I think I'd agree with you that you should get 1:102 as the
output, but maybe that was never intended to be supported.
>
> Duncan Murdoch
>
> On 2026-06-15 3:12 p.m., Fran?ois Rousset via R-devel wrote:
>> Dear R-devel list,
>> the following code shows NA's appearing in the result of pmatch()
when
>> comparing a vector to itself when the length of the vector is more than
100.
>> The main specificity of this example is that elements are repeated in
>> the vector which is matched to itself.
>> The results when they do not include any NA (i.e. for argument of
length
>> <=100) are exactly as I expect from the documentation.
>> I see that the source C code uses distinct algorithms whether n_input
<>> 100 || n_target <= 100 or not. Could there by a problem in the
source
>> code for larger values ?
>> The NA's correspond to the first positions of the second replicate
of
>> the integer sequence, e.g. positions 52 to 56 if n=51 in the example
below.
>> But as shown below, the NA's do not appear when the sequence is
reversed
>> before being compared to itself.
>> This was first detected with R 4.5.3 and is reproducible with a
>> just-downloaded, virgin R-devel installation.
>> Thanks in advance for any feedback,
>> F.
>> =====================>> countNAs <- function(n, rev.=FALSE) {
>> seqn <- seq(n)
>> if (rev.) seqn <- rev(seqn)
>> seqn <- rep(seqn,2) # of length 2 n:
NA's
>> appear when 2 n > 100
>> chk <- pmatch(seqn, seqn) # I expect the result to be
>> seq(2*n)
>> sum(is.na(chk))
>> }
>> sapply(1:100, countNAs )
>> sapply(1:100, countNAs , rev.=TRUE)
>> ======================>> Results:
>> > sapply(1:100, countNAs )
>> [1] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> 0 0 0 0 0 0
>> [29] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> 5 5 5 5 5 5
>> [57] 5 5 5 6 6 6 6 6 6 6 6 6 6 7 7 7 7 7 7 7 7 7
>> 7 8 8 8 8 8
>> [85] 8 8 8 8 8 9 9 9 9 9 9 9 9 9 9 10
>> > sapply(1:100, countNAs , rev.=TRUE)
>> [1] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0
>> 0 0 0 0 0 0 0 0 0
>> [43] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0
>> 0 0 0 0 0 0 0 0 0
>> [85] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> > sessionInfo()
>> R Under development (unstable) (2026-06-14 r90150 ucrt)
>> Platform: x86_64-w64-mingw32/x64
>> Running under: Windows 10 x64 (build 19045)
>> Matrix products: default
>> LAPACK version 3.12.1
>> locale:
>> [1] LC_COLLATE=French_France.utf8 LC_CTYPE=French_France.utf8
>> [3] LC_MONETARY=French_France.utf8 LC_NUMERIC=C
>> [5] LC_TIME=French_France.utf8
>> time zone: Europe/Paris
>> tzcode source: internal
>> attached base packages:
>> [1] stats graphics grDevices utils datasets methods base
>> loaded via a namespace (and not attached):
>> [1] compiler_4.7.0 tools_4.7.0
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd.mes at cbs.dk Priv: PDalgd at gmail.com