Hello Shengwei!



 ShengweiAn:

What confuses me, is why the indices are not in the original order by default (when not sorting the values).


I wouldn’t consider this a bug, per se, because torch.topk()
doesn’t make any promises about the order it returns (when
sorted = False).
I do think this could be a legitimate feature request.  There is
value in having a known return order, and the original order
(which corresponds to sorted indices) would seem to be the
natural choice.
I don’t know what the topk() code looks like, so I don’t know
how hard it would be to do, but if it weren’t too hard, and didn’t
significantly degrade the performance, I would think that having
topk() return the original (sorted-indices) order would be a
worthwhile improvement.  (I also think that for sorted = True
sets of indices for which the values are equal should have
the order of the indices within the set retained.)
(On the other hand, there are undoubtedly more important
bug fixes / feature requests out there in the queue.)
(By analogy, one might compare merge sort and heapsort.
Marge sort is a stable sort, that is, when values test equal, they
are returned in their original order, while heapsort is not stable,
but can have performance advantages.  If there were no loss
in performance, it would make sense to always use the stable
sort.)
Best.
K. Frank