@jjerphan Picking up from PR #18832

According to #18567 (comment), the metric is only valid when 2.0 * n_samples - 3.0 * n_neighbors - 1.0 >= 0. I think this is the valid range of values we should use (see the code of the function. Outside of the range gives result > 1).

In this case, I prefer to error and have this be a bug fix

I agree, an error seems more appropriate

From the referenced paper (Page 4 of the PDF), there is a footnote that states the bounds for n_neighbors:

For clarify we have only included the scaling for neighborhoods of size k < N/2

My bad, actually k < n/2 is stricter than 2n - 3k - 1 > 0, so there's no risk of having the result be > 1. I'm ok with the k < n/2 range.

Hi @Micky774 @thomasjpfan @jeremiedbb , as I mentionned in my comment, I don't think this is the correct way to handle the issue. There is indeed a bug in the code and it's an easy one to fix. On the other hand, trustworthiness doesn't require that n_neighbors be <n_samples/2. I can submit a PR to revert the wrongful (IMO) bugfix and fix the actual bug.

From the original reference paper (Footnote on Page 4 of the PDF), the author is explicit about the requirement:

For clarify we have only included the scaling for neighborhoods of size k < N/2

When running code snippet in #18567 (comment), the inverted index and ranks are:

# inverted index
[[7 4 5 6 2 1 3]
 [2 7 5 4 3 1 6]
 [4 6 7 1 5 2 3]
 [5 6 1 7 3 2 4]
 [2 5 4 6 7 3 1]
 [1 2 3 6 5 7 4]
 [2 6 4 5 1 3 7]]

# ranks
[[ 0 -3 -1 -4 -2]
 [-3  0 -4 -2 -1]
 [-1  0 -3  1 -4]
 [-3 -2 -1 -4  0]
 [-2 -1 -4 -3  1]
 [ 0  1 -2 -4 -1]
 [-4  0 -2 -1 -3]]

which do not overflow with the sum. Furthermore, if running on 64-bit Python, the inverted_index is already int64:

import numpy as np
inverted_index = np.zeros((10, 2), dtype=int)
print(inverted_index.dtype)
# int64

From the original reference paper (Footnote on Page 4 of the PDF), the author is explicit about the requirement:

For clarify we have only included the scaling for neighborhoods of size k < N/2

When running code snippet in #18567 (comment), the inverted index and ranks are:

# inverted index
[[7 4 5 6 2 1 3]
 [2 7 5 4 3 1 6]
 [4 6 7 1 5 2 3]
 [5 6 1 7 3 2 4]
 [2 5 4 6 7 3 1]
 [1 2 3 6 5 7 4]
 [2 6 4 5 1 3 7]]

# ranks
[[ 0 -3 -1 -4 -2]
 [-3  0 -4 -2 -1]
 [-1  0 -3  1 -4]
 [-3 -2 -1 -4  0]
 [-2 -1 -4 -3  1]
 [ 0  1 -2 -4 -1]
 [-4  0 -2 -1 -3]]

which do not overflow with the sum. Furthermore, if running on 64-bit Python, the inverted_index is already int64:

import numpy as np
inverted_index = np.zeros((10, 2), dtype=int)
print(inverted_index.dtype)
# int64

You are actually right @thomasjpfan, k should be <N/2. However, I still have the int32 issue. Running your code snippet returns int32 in my case although using a 64-bit Python interpreter. It seems like this is an issue related to how windows handles the long int type as discussed here. How do we take it from here? Should I open a new issue to further discuss the details or shoud I send a PR directly to force the use of int64?

Should I open a new issue to further discuss the details or shoud I send a PR directly to force the use of int64?

The first step is to open an issue describing the issue with using dtype=int. Since we use dtype=int in other parts of the code base, we may want to change it everywhere so the code behaviors the same on different platforms.