Пока в nums нет дупликатов и found — это просто про умножение (а не про, например, взятие по модулю) это свойство (не больше одного совпадения во внутреннем цикле) не зависит от констант (и их можно произвольно менять).
Но да, если оставлять так, то нужно внимательно следить за условием (для произвольного условия good(num, i, 25) этот код не подходит).
Формально, можно и так оставить: может быть не больше одного совпадения во внутреннем цикле, а после первого внутреннего цикла, изменившего значение, нас выкинет из внешнего.
Что не отменяет того, что так писать, конечно, не стоит.
Так концептуально не получится — питон же не строго типизированный.
Например следующую функцию перенести в язык, где нету option/maybe (в каком-нибудь виде) невозможно по концептуальным причинам.
От порядка следования, конечно, результат меняется (при D=2 можно увеличивать первую «30», а можно последнюю).
Но порядок следования в моем коде сохраняется — Rust автоматически выводит порядок для пар, если есть порядок на каждой из компонент (естественным образом: сначала по первой компоненте, а если есть равенство, то по второй). В результате, мне достаточно определить порядок на дробях. А когда я сортирую пару из дроби и индекса, под капотом используется то самое сравнение, которое Вы реализовали явно (а у меня оно вывелось из явного порядка на дробях и стандартного на usize).
Написал собственную сортировку дробей на коленке, которая сравнивает дроби, а не их целые части (как это было сделано в референсе). Вроде, сравнивать дроби правильнее: первая строчка, например, должна быть с четвертой единичкой, а не с первой.
(Там весь код был, я просто ссылку поменял на рабочую).
А вот функции — уже не строго типизированные (на чем и игра в этом примере).
Пока в nums нет дупликатов и found — это просто про умножение (а не про, например, взятие по модулю) это свойство (не больше одного совпадения во внутреннем цикле) не зависит от констант (и их можно произвольно менять).
Но да, если оставлять так, то нужно внимательно следить за условием (для произвольного условия good(num, i, 25) этот код не подходит).
Что не отменяет того, что так писать, конечно, не стоит.
Например следующую функцию перенести в язык, где нету option/maybe (в каком-нибудь виде) невозможно по концептуальным причинам.
Например: (1, 10) < (2, 5) < (2, 7)
play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=10eceaf01064d7be6f37194093bf93d2
Фокус в вот этой имплементации: doc.rust-lang.org/std/cmp/trait.Ord.html#impl-Ord-61
Если есть порядок на первом и втором элементе пары, то появляется порядок на парах (по которому я и сортирую).
От порядка следования, конечно, результат меняется (при D=2 можно увеличивать первую «30», а можно последнюю).
Но порядок следования в моем коде сохраняется — Rust автоматически выводит порядок для пар, если есть порядок на каждой из компонент (естественным образом: сначала по первой компоненте, а если есть равенство, то по второй). В результате, мне достаточно определить порядок на дробях. А когда я сортирую пару из дроби и индекса, под капотом используется то самое сравнение, которое Вы реализовали явно (а у меня оно вывелось из явного порядка на дробях и стандартного на usize).
play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=466e2f5667ac1d9484bdbe5c99e65cb5
Написал собственную сортировку дробей на коленке, которая сравнивает дроби, а не их целые части (как это было сделано в референсе). Вроде, сравнивать дроби правильнее: первая строчка, например, должна быть с четвертой единичкой, а не с первой.