fix incorrect torch version test

[namgyu-youn]

Summary:
PyTorch pre-release/dev versions have a0/dev in their name. Therefore, the right order is the following:

2.4.0 (stable) < 2.5.0.dev / 2.5.0.git < 2.5.0 (stable)

For correct order, this PR applies true order within stable and pre-release/dev.

• fix: torch_version_at_least semantics are incorrect #2722

Test plan: CI

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/ao/2786

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[jerryzh168]

I have some impression that we don't want to do this, but @msaroufim would have more context here

[msaroufim]

seems fine to merge altho we probably want to delete the compare_versions function

[namgyu-youn]

compare_versions & parse_version are unavailable to used here because parse_version only extracts \d+\.\d+\.\d+ (e.g., 2.5.0→[2, 5, 0]). Therefore, we can inject more parsers (e.g., a0, dev) into parse_version, but I am not certain because check_cpu_version & check_xpu_version are chained with them.

[andrewor14]

Hi @namgyu-youn, thanks for fixing this. I think we should actually fix compare_versions and parse_version instead, since they are used in a few different places. I'm actually wondering if we can express the comparisons like this:

# parse_version
2.5.0+cu126 -> [2, 5, 0]
2.5.0 -> [2, 5, 0]
2.5.0a0+git9f17037 -> [2, 5, -1]
2.5.0.dev20240708+cu121 -> [2, 5, -1]
2.4.0 -> [2, 4, 0]

Basically always return a list of 3 numbers, and -1 represents a pre-release. Then we can just compare as follows:

# don't need compare_versions anymore
parse_version(x) >= parse_version(y)

# These are True
[2, 5, -1] < [2, 5, 0]
[2, 5, -1] > [2, 4, 99]

To me this is simpler than the existing compare_versions logic, which I think is a bit unintuitive to understand. What do you think?

[namgyu-youn]

Hi @namgyu-youn, thanks for fixing this. I think we should actually fix compare_versions and parse_version instead, since they are used in a few different places. I'm actually wondering if we can express the comparisons like this:

# parse_version
2.5.0+cu126 -> [2, 5, 0]
2.5.0 -> [2, 5, 0]
2.5.0a0+git9f17037 -> [2, 5, -1]
2.5.0.dev20240708+cu121 -> [2, 5, -1]
2.4.0 -> [2, 4, 0]

Basically always return a list of 3 numbers, and -1 represents a pre-release. Then we can just compare as follows:

# don't need compare_versions anymore
parse_version(x) >= parse_version(y)

# These are True
[2, 5, -1] < [2, 5, 0]
[2, 5, -1] > [2, 4, 99]

To me this is simpler than the existing compare_versions logic, which I think is a bit unintuitive to understand. What do you think?

Sounds good to me. Customized parse_version was just a careful suggestion, and I also agree with -1 for better logic. Let me fix it with co-authoring; thanks again!