I have some questions about understanding the code.
i notice that line188：labels[:num_pos] = pos_gt_labels
The above three lines of code indeed shuffle the order of the labels. For example, if the label sequence is [1, 1, 0, 1, 0, 0] before the operation, after executing these lines, the labels will become [1, 1, 1, 0, 0, 0]. This means that the positive labels are moved to the front of the list.
In subsequent loss calculation operations, the proposals are selected based on the labels. However, if you understand that the proposal order still corresponds to [1, 1, 0, 1, 0, 0], then the correct values to consider would be the 0th, 1st, and 3rd proposals. But if you use the updated labels [1, 1, 1, 0, 0, 0], you would end up considering the 0th, 1st, and 2nd proposals instead. This could indeed lead to a mismatch between the ground truth and the predicted results.
If preserving the original proposal order is important for your specific use case, you may need to modify the code accordingly to ensure that the proposal order remains consistent with the original label order during the loss calculation process.
What's the feature?
I have some questions about understanding the code. i notice that line188：labels[:num_pos] = pos_gt_labels
The above three lines of code indeed shuffle the order of the labels. For example, if the label sequence is [1, 1, 0, 1, 0, 0] before the operation, after executing these lines, the labels will become [1, 1, 1, 0, 0, 0]. This means that the positive labels are moved to the front of the list.
In subsequent loss calculation operations, the proposals are selected based on the labels. However, if you understand that the proposal order still corresponds to [1, 1, 0, 1, 0, 0], then the correct values to consider would be the 0th, 1st, and 3rd proposals. But if you use the updated labels [1, 1, 1, 0, 0, 0], you would end up considering the 0th, 1st, and 2nd proposals instead. This could indeed lead to a mismatch between the ground truth and the predicted results.
If preserving the original proposal order is important for your specific use case, you may need to modify the code accordingly to ensure that the proposal order remains consistent with the original label order during the loss calculation process.
为了方便你理解，下述是上述内容对应中文：上述三行代码将label的顺序打乱了。例如在操作前label顺序是[1,1,0,1,0,0]，该行命令执行后label变为[1,1,1,0,0,0]”也就是这行代码将positive label 置于list前。 后续的loss计算操作，是根据label来选取pred的，如果按照更新后的label：[1,1,1,0,0,0]取值，此时取得是第0，1，2个，然而我理解的正确的取值应该是按照[1,1,0,1,0,0]，应该是第0，1，3个。 上述这几行代码是否会导致gt和pred的对应关系混乱？ 最后非常感谢作者提供的代码
Any other context?
No response