Как писать быстрые программы

[Yadryara]

Dmitriy40 в сообщении #1721770 писал(а):

Подразумевалось что в этом интервале есть одна цепочка. Т.е. мат.ожидание интервала, не количества цепочек.

В каком, в этом интервале? Вот я указал интервал: $0-61\#$. Понятно же какая нижняя граница, а какая верхняя?

А у вас, как понимаю, указана только какая-то одна граница, а вторая не указана. Предположу, что речь идёт об интервале: $0-1e28$ Так? И в нём ожидается ровно 1 цепочка?

Dmitriy40 в сообщении #1721770 писал(а):

Откуда Вы это знали?! Как получили цифру 11 месяцев?

Потому что я уже довольно долго гонял программу и сделал вывод о линейности временных затрат. Так что если я за месяц проверил 1/11 интервала, то нечего и мудрить — на весь интервал уйдёт 11 месяцев. Я об этом уже рассказывал. Даже больше месяца потратил — где-то в феврале-марте прошлого года.

Dmitriy40 в сообщении #1721770 писал(а):

Сколько центральных 15-к для этого нашли и за какое время?

Ну где-то полторы-две сотни и нашёл. Это несущественно вроде. Прогнозы по HL1 уже были нами ранее многократно проверены и я доверял этой оценке. Кстати, она блестяще подтвердилась: было найдено 1147 кортежей.

Dmitriy40 в сообщении #1721770 писал(а):

Что-то в своих примерах Вы с ног на голову всё перевернули.

Не заметил такого. Или имеете в виду что есть разные способы счёта? Да, конечно есть, и я уже сколько-то лет говорю, что неплохо для надёжности считать разными способами.

Dmitriy40 в сообщении #1721770 писал(а):

Сначала говорили для оценки времени нужна средняя скорость нахождения кортежей (с чем я и стал спорить),

А зачем с этим спорить? По известной средней скорости разве нельзя оценить затраты времени на нахождение того или иного количества кортежей ?

Dmitriy40 в сообщении #1721770 писал(а):

теперь оказывается всё наоборот, среднюю скорость вычисляете как известное непонятно откуда время делить на мат.ожидание количества кортежей.

Нет, это вы перевернули. У меня время как было в знаменателе, так и остаётся:

средняя скорость равна
мат.ожидание количества кортежей в интервале разделить на ожидаемое время проверки того же самого интервала

Dmitriy40 в сообщении #1721770 писал(а):

из мат.ожидания количества кортежей (1 кортеж на интервал 1e28) и неизвестной средней скорости нахождения кортежей (ни один ещё не найден) получите ожидаемое время.

Ожидаемое время чего? Среднее время нахождения одного кортежа? Это время очевидно будет равно времени проверки этого интервала. Проверили этот интервал и в среднем нашли один кортеж.

Dmitriy40 в сообщении #1721770 писал(а):

Yadryara в сообщении #1721768 писал(а):

Нет конечно, если известны тенденции, то можно экстраполировать их, учтя найденные ранее скорости.

Не работает. Или слишком грубо.

Работает. Вот что вы сами сказали:

Dmitriy40 в сообщении #1646941 писал(а):

Вот теперь в него верю.

А слишком грубо или не слишком, это станет ясно когда я попытаюсь экстраполировать. А до этого ещё далеко.

[Dmitriy40]

Yadryara
Эта тема заявлена про ускорение работы программ.
Вот у меня есть программа P1.
После попытки её оптимизации получаю программу P2.
Чтобы выяснить какая быстрее (чтобы найти искомый кортеж побыстрее) запускаю обе на 1 час:
P1 работает 1 час и находит 0 кортежей;
P2 работает 1 час и находит 0 кортежей.
Вычисляю скорости Вашим методом: v(P1)=0/1=0, v(P2)=0/1=0 - одинаковые?! А как же оптимизация?
Вопрос: ну и какая из них быстрее и выгоднее и какую использовать?
И нет, они не одинаковы, они очень и очень разные.
Хотя считают один и тот же паттерн с одним и тем же мат.ожиданием в одном и том же интервале. Только P1 будет обрабатывать этот интервал 1 год, а P2 17 лет. Вот такая "оптимизация".
Ну и как мне по Вашему методу понять какую использовать?

[Yadryara]

Dmitriy40 в сообщении #1721779 писал(а):

Вычисляю скорости Вашим методом: v(P1)=0/1=0, v(P2)=0/1=0 - одинаковые?!

Это не мой метод, это самый обычный, классический метод вычисления скорости, когда время стоит в знаменателе. Понятно же, что для данного случая для сравнения скоростей он неприменим. Я же ведь именно поэтому беру более короткие цепочки, потому что для них в числителе далеко не ноль.

О чём тут вы спрашиваете? Разве это с самого начала не было понятно??

А у вас-то время почему в числителе? Вот в этом утверждении:

Dmitriy40 в сообщении #1721770 писал(а):

среднюю скорость вычисляете как известное непонятно откуда время делить на мат.ожидание количества кортежей.

Подчёркивание моё. Это ложь. Я так не вычисляю. Я не время делю, а делю на время.

Dmitriy40 в сообщении #1721779 писал(а):

Вопрос: ну и какая из них быстрее и выгоднее и какую использовать?

Для того чтобы ответить на этот вопрос, нужно, например, в качестве одного из методов тестировать их на более коротких цепочках.

Dmitriy40 в сообщении #1721779 писал(а):

Ну и как мне по Вашему методу понять какую использовать?

Так я же только что написал:

Yadryara в сообщении #1721777 писал(а):

А слишком грубо или не слишком, это станет ясно когда я попытаюсь экстраполировать. А до этого ещё далеко.

Я ещё D(96, 8) не закончил считать. А впереди ещё D(96, 9), D(96, 10) и так далее.

[Dmitriy40]

Yadryara в сообщении #1721788 писал(а):

Для того чтобы ответить на этот вопрос, нужно, например, в качестве одного из методов тестировать их на более коротких цепочках.

А на более коротких кортежах их скорости перебора (и соответственно выдачи кортежей) становятся одинаковыми. Из-за слишком частого пролёта кортежей до медленных финальных проверок, которые и ограничивают скорости обеих программ и которые не оптимизировались и остались одинаковыми в обеих. Довольно частая ситуация вообще-то, когда оптимизируется лишь часть программы, а не вся целиком.
Так как же выбрать одну из двух программ? Какая из них оптимальнее? Дала эффект оптимизация или ну её нафиг? Ваш метод (измерение/оценка средней скорости выдачи кортежей) ответа не даёт.

Yadryara в сообщении #1721788 писал(а):

Понятно же, что для данного случая для сравнения скоростей он неприменим.

А между тем это самый практически интересный случай - поиск неизвестного пока кортежа!
И если измерять скорость именно перебора кандидатов - тогда скорость вполне измерима и позволяет сравнивать разные версии программ, даже для разных паттернов! Даже если кортежей при этом не находится ни одного.
О чём Вам и говорю, что этот метод сравнения (скорости не выдачи кортежей, а перебора кандидатов) более универсален. И при наличии оценок мат.ожидания легко пересчитывается в ожидаемое время или среднюю скорость выдачи кортежей. Но наоборот не всегда! И как раз в самом интересном случае (поиск неизвестного кортежа) - обратно не пересчитывается! Потому что в числителе 0 и скорости всех вариантов программ оказываются равными (нулевыми), что не позволяет сделать вывод какая быстрее и выгоднее.
И поэтому речь всегда шла именно про скорость перебора, а не выдачи кортежей. Ваше желание оценивать последнюю для ненайденных кортежей непонятно и не позволяет для них сравнивать скорости разных вариантов программ и соответственно выполнять оптимизацию скорости их поиска. А для накопления статистики уже известных кортежей да, можно и так.

-- 08.04.2026, 13:03 --

Dmitriy40 в сообщении #1721807 писал(а):

А для накопления статистики уже известных кортежей да, можно и так.

Только смысла нет - скорость перебора кандидатов и скорость выдачи кортежей монотонно связаны, чем выше первая, тем выше вторая (и наоборот). Потому можно всегда оптимизировать первую как более просто измеримую, это даст эффект и для второй.

[wrest]

Dmitriy40 в сообщении #1721807 писал(а):

Только смысла нет - скорость перебора кандидатов и скорость выдачи кортежей монотонно связаны, чем выше первая, тем выше вторая (и наоборот).

Если только в процессе оптимизаци мы не решили дропать слишком уж много лишнего, считая какие-то случаи настолько невероятным, что не стоит и проверять. Например кубы

Я как-то разговаривал с ИИ, на тему как нам сократить использование ispseudoprime(), так оно мне сказало, что типа если мелкие множители (до 2^20 например) уже убрали, а число (остаток-частное) всё ещё большое, то оно почти наверняка составное и не надо его на простоту проверять, т.к. ответ с хорошей вероятностью известен: составное. Когда я показал ИИ реально найденную D(48,21) то ИИ быстро дал заднюю и больше не настаивал, что большие числа проверять на простоту не надо

[Dmitriy40]

wrest в сообщении #1721809 писал(а):

число (остаток-частное) всё ещё большое, то оно почти наверняка составное и не надо его на простоту проверять, т.к. ответ с хорошей вероятностью известен: составное.

И это правда: произвольное число из 45+ цифр составное с вероятностью выше 99% ($1-\frac{1}{\ln x}$).
Соответственно все 20 чисел простые с вероятностью меньше $0.01^{20}=10^{-40}$. Потому и приходится кортежи искать среди более чем 1e40 чисел (не кандидатов в переборе, а натуральных чисел). Но такая оценка слишком грубая, например для 19-252 она ошибочна на 10 порядков.
И да, вот такие ничтожные вероятности мы и ловим. Так что проверять таки нужно, даже маленькие вероятности. Но ради скорости можно отбросить ещё на порядки меньшие (кубы и высшие степени).

-- 08.04.2026, 16:43 --

wrest в сообщении #1721809 писал(а):

Если только в процессе оптимизаци мы не решили дропать слишком уж много лишнего, считая какие-то случаи настолько невероятным, что не стоит и проверять.

Сначала хотел написать "линейно связаны", но из-за вот таких случаев (и случайности времени разложения на простые множители) решил ослабить до монотонности, которая сохраняется в любом случае (не бывает такого что повысили скорость перебора и из-за этого упала скорость выходных кортежей).

[wrest]

Dmitriy40 в сообщении #1721810 писал(а):

не бывает такого что повысили скорость перебора и из-за этого упала скорость выходных кортежей

Как раз может быть, если в целях повышения скорости перебора решили дропать что-то, вероятность чего попадания на выход оценили неверно.

[Yadryara]

Dmitriy40 в сообщении #1721807 писал(а):

Так как же выбрать одну из двух программ? Какая из них оптимальнее? Дала эффект оптимизация или ну её нафиг?

Вы опять не читаете что я пишу?

Для того чтобы ответить на этот вопрос, нужно отследить тенденции и на их основе сделать экстраполяции.

Dmitriy40 в сообщении #1721807 писал(а):

Ваш метод (измерение/оценка средней скорости выдачи кортежей) ответа не даёт.

А для того чтобы отследить тенденции и сделать экстраполяции, нужно собрать статистику. А для того чтобы собрать статистику, нужно время. Вы забыли что в кортежной теме мы собирали статистику не один месяц?

Так что мой метод пока ответа не даёт.

wrest в сообщении #1721812 писал(а):

Как раз может быть, если в целях повышения скорости перебора решили дропать что-то, вероятность чего попадания на выход оценили неверно.

Конечно. Рад что вы это понимаете. У меня пока довольно хорошая фильтрация и в той статистике, что я показывал, это не было заметно. Я ведь показываю далеко не всё что считаю, а только самое лучшее. Но вот могу специально показать и такой вариант, полученный при одной из настроек параметров программы:

2^   Остаток   Старт     Комплектов       Счёт     Найдено      Время       Скорость
      по 729  полосы      посчитано        e21     D(96,6)     секунд    D(96,6)/час

9        243      11     3! * 1!  6      0 — 1         585       1537           1370
10       243      11     3! * 1!  6      0 — 1         586       1272           1658
11       243      11     3! * 1!  6      0 — 1         587       1083           1951
12       243      11     3! * 1!  6      0 — 1         587        975           2167
13       243      11     3! * 1!  6      0 — 1         587        891           2372 best
14       243      11     3! * 1!  6      0 — 1         587        921           2294
15       243      11     3! * 1!  6      0 — 1         587       1102           1918

Видите: не всегда находились именно 587 цепочек.

[Yadryara]

Ну вот вроде закончил с D(96,8). Интересное кино: серия с одни простым не просто не сдалась, она ещё и укрепила свои позиции:

Серия            2^     Комплектов       Счёт     Найдено      Время       Скорость
                         посчитано    от 0 до     D(96,8)     секунд    D(96,8)/час

0-0-7-1-0-3!     14      2! * 5!  8       1e30         171        872            706
0-0-7-1-0-3!     15      2! * 5!  6       1e30         127        609            751
0-0-7-1-0-3!     16      2! * 5!  6       1e30         127        608            752 best
0-0-7-1-0-3!     17      2! * 5!  5       1e30         105        508            744

0-0-8-0-0-3!     14      2! * 6! 20       1e31         154        468           1185
0-0-8-0-0-3!     15      2! * 6! 20       1e31         154        432           1283
0-0-8-0-0-3!     16      2! * 6! 20       1e31         154        432           1283
0-0-8-0-0-3!     17      2! * 6! 11       1e31          87        236           1327 best
0-0-8-0-0-3!     18      2! * 6!  6       1e31          50        157           1147

0-1-7-0-0-3!     15      2!*6!*1 10       1e33         128        333           1384
0-1-7-0-0-3!     16      2!*6!*1 10       1e33         128        313           1472
0-1-7-0-0-3!     17      2!*6!*1  8       1e33         102        249           1475 best
0-1-7-0-0-3!     18      2!*6!*1  7       1e33          93        244           1372

1-0-7-0-0-3!     16   2!*6!*1*1 130       1e34         112        241           1673
1-0-7-0-0-3!     17   2!*6!*1*1 130       1e34         112        240           1680 best
1-0-7-0-0-3!     18   2!*6!*1*1 130       1e34         112        256           1575

И это даже несмотря на то, что интервал самый большой по сравнению с другими сериями. Вот что две доп. фильтрации животворящие делают.

[Dmitriy40]

Yadryara в сообщении #1721843 писал(а):

Для того чтобы ответить на этот вопрос, нужно отследить тенденции и на их основе сделать экстраполяции.

Зачем? Есть две программы поиска одного конкретного паттерна, их можно запустить на разумное время и набрать статистику и сравнить какая быстрее. Ваш метод (по скорости выдачи кортежей) - не может (требуются какие-то оценки по другим паттернам).
А сравнение скорости перебора кандидатов - может. Даже без единого найденного в процессе измерений кортежа.
Плюс при наличии дополнительных знаний (например мат.ожидания) скорость перебора кандидатов пересчитывается в скорость выдачи кортежей.
Т.е. для практической задачи сравнения качества оптимизации Ваш метод не подходит, а по скорости перебора подходит.
Ну и всё на этом, вопрос закрыт.

Yadryara в сообщении #1721843 писал(а):

Видите: не всегда находились именно 587 цепочек.

А почему это не считается ошибкой?! На одном и том же интервале разными методами фильтрации находится разное количество цепочек - явно же бред, количество кортежей на интервале объективно и не зависит от метода фильтрации.
Или Вы как всегда замалчиваете важные моменты типа того что проверки идут не до конца и считаются не кортежи, а какие-то приближения к ним?

[Yadryara]

Dmitriy40 в сообщении #1721911 писал(а):

Зачем?

Странный вопрос. Затем чтобы сделать прогноз.

Dmitriy40 в сообщении #1721911 писал(а):

Есть две программы поиска одного конкретного паттерна, их можно запустить на разумное время и набрать статистику и сравнить какая быстрее.

Ну так я именно этим сейчас и занимаюсь.

Dmitriy40 в сообщении #1721911 писал(а):

Ваш метод (по скорости выдачи кортежей) - не может (требуются какие-то оценки по другим паттернам).

Что именно мой метод не может?

Совершенно верно, имея результаты по различным сериям паттернов и различным цепочкам можно делать какие-то выводы. Например, вот здесь я собрал пока максимальную скорость счёта:

Кортеж          Серия      2^      Комплектов       Счёт     Найдено      Время       Скорость
                                    посчитано    от 0 до     D(96, )     секунд   кортежей/час
D(96,6)   0-1-5-0-0-2!     15   3!*4!*1    24       1e25         292         57          18442
D(96,7)   0-1-6-0-0-3!     16   2!*5!*1    48       1e27         100         51           7059
D(96,8)   1-0-7-0-0-3!     17   2!*6!*1*1 130       1e34         112        240           1680

Можно ли по этим данным сделать прогноз по D(96,9)? Или совсем ничего невозможно сказать?

Dmitriy40 в сообщении #1721911 писал(а):

Т.е. для практической задачи сравнения качества оптимизации Ваш метод не подходит,

А как вы определили что не подходит? Вы же наоборот сказали:

Dmitriy40 в сообщении #1646941 писал(а):

Вот теперь в него верю.

Это было сказано как раз по поводу применения моего метода экстраполяции на основании анализа имеющихся тенденций.

Dmitriy40 в сообщении #1721911 писал(а):

Ну и всё на этом, вопрос закрыт.

Какой вопрос закрыт? Вы уже не первый раз напрасно торопитесь закрыть вопрос. И напрасно. Я недавно привёл пример с подсчётом вероятностей.

Dmitriy40 в сообщении #1721911 писал(а):

Yadryara в сообщении #1721843 писал(а):

Видите: не всегда находились именно 587 цепочек.

А почему это не считается ошибкой?!

Развернутый ответ давать?

Я просто уже не помню почему именно так получилось, но я помню что перепроверял как работает программа. Да, по тому алгоритму, так и должно было быть, поменьше цепочек должно было найтись при маленьком количестве предпростых. Посмотрел конкретную не найденную цепочку.

Dmitriy40 в сообщении #1721911 писал(а):

На одном и том же интервале разными методами фильтрации находится разное количество цепочек - явно же бред,

С вашей стороны бред?

Dmitriy40 в сообщении #1721911 писал(а):

количество кортежей на интервале объективно и не зависит от метода фильтрации.

Общее количество кортежей в интервале не зависит от метода фильтрации.

А количество найденных кортежей — ещё как зависит.

Или может вы не понимаете что программой находятся далеко не все кортежи??

Я же специально написал количество обсчитанных комплектов. Ну вот выше например:

2!*5!*1 48

Вы же видите что здесь нет знака равенства? Если перемножить числа в левой части, то получится 240, а посчитано всего лишь 48.

Ну по другим аспектам видно что далеко не всё считается. Например, я пока применяю только алгоритм Полларда, а не ЕСМ.

Ведь не стоит задача найти все кортежи в интервале, а стоит задача побыстрее найти один-единственный кортеж.

Dmitriy40 в сообщении #1721911 писал(а):

Или Вы как всегда замалчиваете важные моменты типа того что проверки идут не до конца и считаются не кортежи, а какие-то приближения к ним?

Что значит "как всегда замалчиваете" ??? Я как раз подробно объясняю, а вот вы многие мои вопросы пока оставили без ответа.

Dmitriy40 в сообщении #1721911 писал(а):

проверки идут не до конца и считаются не кортежи, а какие-то приближения к ним?

В каком смысле проверки идут не до конца? В определённом смысле конечно не до конца. См. выше.

Но все кортежи именно что полные, непрерывные. Это не приближения. Я же специально спрашивал приводить ли полный список. Вот, кстати, не знаю поместятся ли здесь 587 штук. Нужно показывать или нет?

[Dmitriy40]

wrest в сообщении #1721812 писал(а):

Dmitriy40 в сообщении #1721810 писал(а):

не бывает такого что повысили скорость перебора и из-за этого упала скорость выходных кортежей

Как раз может быть, если в целях повышения скорости перебора решили дропать что-то, вероятность чего попадания на выход оценили неверно.

Поясните пожалуйста свою мысль.
На конкретном примере: есть программа П1, которая перебирает 10млн кандидатов за пусть 10с и выдаёт при этом 10 кортежей. Скорость перебора 1млн/с, скорость кортежей 1шт/с. И есть программа П2, которая перебирает ровно те же 10млн кандидатов за меньшее время t<10с, выдаёт ровно те же 10 кортежей, скорость перебора 10млн/t>1млн/с, но скорость кортежей 10/t<1шт/с при некотором времени работы t. Это как так? Как у одной программы могут быть два разных времени работы (чтобы получить разные скорости при одинаковом числителе с П1)?!
И да, речь именно про кортежи, если оценивать по приближениям, то да, в зависимости от качества фильтрации можно получить другое количество приближений и тогда разным будет и числитель тоже и непонятный мне парадокс исчезает.

-- 09.04.2026, 23:17 --

Yadryara в сообщении #1721938 писал(а):

Что именно мой метод не может?

Который раз повторяю: корректно сравнить скорости двух программ если каждая из них выдала ровно 0 кортежей, даже если за разное время.

Yadryara в сообщении #1721938 писал(а):

Что значит "как всегда замалчиваете" ???

Пока явно не спросил, не видел пояснений к вашим таблицам что находятся не все кортежи, а лишь какая-то часть. Для меня такая фильтрация вообще мало смысла имеет. Ищем или любой один (ну или сколько найдётся пока времени не жалко), или все. Искать лишь часть ... Не понимаю для чего это может пригодиться. Тем более оптимизация такой скорости.

Yadryara в сообщении #1721938 писал(а):

а вот вы многие мои вопросы пока оставили без ответа.

И снова оставлю. Как не имеющие отношения к теме или риторические. К счастью не обязан отвечать на тотально все.

Yadryara в сообщении #1721938 писал(а):

В каком смысле проверки идут не до конца? В определённом смысле конечно не до конца. См. выше.
Но все кортежи именно что полные, непрерывные. Это не приближения.

Этого из ваших таблиц было непонятно. Что часть кортежей может быть пропущена. И видимо каждый раз эта часть может быть и произвольной. Какой тогда имеет смысл скорость кортежей в секунду вообще неясно (если неизвестно сколько их и каких именно пропустил каждый вариант программы). Сравнение мягкого с тёплым и с синим.
Впрочем, ок, тема Ваша, сравнивайте.
А меня полностью устраивает сравнение вариантов программ по скорости перебора кандидатов.

[wrest]

Dmitriy40 в сообщении #1721939 писал(а):

Поясните пожалуйста свою мысль.

Мысль простая. Допустим вы ускоряете перебор в два раза ценой потери половины решений. Тогда скорость нахождения решений не меняется. Если вы ускоряете в два раза но теряете 2/3 решений, то скорость нахождения решений уменьшается. Ну и так далее. Поэтому, если оптимизация подразумевает потерю решений, нужна надёжная оценка сколько теряется.

[Yadryara]

Dmitriy40 в сообщении #1721939 писал(а):

Как не имеющие отношения к теме или риторические.

Снова здоро́во. Я не задаю не имеющих отношения к теме вопросов. И не имею привычки задавать риторические вопросы.

Что можете сказать по поводу D(96,9) ? Можно ли дать какой-то прогноз? Не считая, а только ориентируясь на мои данные.

Dmitriy40 в сообщении #1721939 писал(а):

Пока явно не спросил, не видел пояснений к вашим таблицам что находятся не все кортежи, а лишь какая-то часть.

Ну так поэтому и существует диалог, а не монолог. Если я cразу буду писать очень подробно, то запросто можете упрекнуть что я пишу слишком длинно, как уже было. И меня это неприятно удивило. Потому что это было даже тогда, когда я специально под кат спрятал длинную часть.

Так что да. Где-то слишком мало сказал, где-то слишком много. Для вас это так может выглядеть. Задали вопрос, я ответил, проблем нет. Но на мои вопросы почему-то гораздо меньше ответов по существу.

Я кстати вот не перестаю удивляться что вам непонятно о чём я говорю. Раньше у нас вроде было больше взаимопонимания.

Кстати, я вспомнил почему при $2^9$ нашлось 585 кортежей, а при $2^{10}$ — 586. Я по-прежнему использую алгоритм Полларда, считая что фактор который он определит будет вероятнее всего простым. Вы это не опровергли.

Ну вот это был как раз тот редкий случай, когда фактор найденный алгоритмом Полларда оказался составным, но программа не учитывала такую возможность и правильная цепочка была отброшена.

А почему при $2^{10}$ программа эту цепочку не отбросила? Да потому что то число имело простой фактор, который как раз был больше чем $2^9$ и меньше чем $2^{10}$.

Dmitriy40 в сообщении #1721939 писал(а):

Какой тогда имеет смысл скорость кортежей в секунду вообще неясно (если неизвестно сколько их и каких именно пропустил каждый вариант программы).

Ну вот это и поразительно что вам неясно. Задача стоит: найти один-единственный кортеж. И главный вопрос: с какой скоростью ищутся кортежи? И ответ на этот вопрос как раз и даётся в последнем столбце. И если пропущен 1 или 2, да хоть даже и 100 кортежей из 587, не это главное, а главное: скорость с которой находятся хоть какие-то кортежи.

Потому что нужно найти хотя бы один кортеж. Любой подходящий.

Вы этого не понимаете? А wrest вроде бы понимает. Или нет?

[Dmitriy40]

wrest
А, так Вы тоже оказывается про потерю кортежей ...
Ну тогда согласен, скорость кортежей может меняться в обе стороны.
Тем более не вижу пользы от неё, по сравнению со скоростью перебора.