On 16 Jun 2026, at 11.54, Peter Dalgaard <[email protected]> wrote:
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 <[email protected]> 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
______________________________________________
[email protected] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
[email protected] 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: [email protected] Priv: [email protected]
