Пентадекатлон мечты

[Dmitriy40]

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

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

Чего тут комментировать, я ж даже не вижу по какому паттерну и кто её запускал.

Так я же внятно сказал:

Я видел несколько сравнений тут в теме, но сходу не понял что с чем сравнивали. Было даже что-то про мои предыдущие программы, которые были с ошибкой. Соответственно так и не понял что конкретно мне прокомментировать. Может быть Вы сформулируете вопрос чётко и обозримо?
А до логов Демиса я так ещё и не добрался, всё некогда было.

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

Зачем же бросать в тех частых случаях, когда Ваши программы явно быстрее??

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

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

Ну а версия "с хотя бы одним перебором" ведь скоро появится. Причём Вы ведь свои новые версии тестите на 64 AVX2 компе. И Маруся как раз такой комп. И уже почти свободна. Занято только 3 потока. Ведь можно уже и на ней запускать те или иные тесты?

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

Huz в сообщении #1569683 писал(а):

Please could you email me the log file for one or both of these runs?
It may be that optimal -g varies for different patterns, but when I tested this for other cases in the past it seemed similar for most patterns. I found -g16 by testing with b1630.

Of course I will send it by mail, no question.
But when the third test, c-g16, is completed, I think it will be still tomorrow morning. Current status:

-g16:
305 3^2.5 2 131^2 2^2.3 7^2 2.5^2 3.11^2 2^5 17^2 2.3^2 5: 8272145 / 23350471 (47542.47s)
305 3^2.5 2 131^2 2^2.3 7^2 2.5^2 3.11^2 2^5 5268560303^2 2.3^2 5 (48138.73s)
305 3^2.5 2 137^2 2^2.3 7^2 2.5^2 3.11^2 2^5 3664592759^2 2.3^2 5 (48733.43s)
305 3^2.5 2 139^2 2^2.3 7^2 2.5^2 3.11^2 2^5 2133535777^2 2.3^2 5 (49327.27s)
-g3 for compare:
305 3^2.5 2 137^2 2^2.3 7^2 2.5^2 3.11^2 2^5 2297621071^2 2.3^2 5 (44669.15s)
305 3^2.5 2 139^2 2^2.3 7^2 2.5^2 3.11^2 2^5 853402493^2 2.3^2 5 (45265.78s)

It can be seen that the loss was almost leveled.

And yes, the value of -g should almost certainly depend on the parameters of the pattern (LCM). It is possible to set it the same for all patterns, but not quite optimal. However, I won't say anything for sure, I haven't watched how you use it to estimate time (to switch from linear to recursive iterate).

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

Я Вам больше скажу, имеет смысл уточнять скорость работы даже для перебора, который длится меньше секунды.

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

-- 11.11.2022, 15:15 --

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

[Yadryara]

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

Соответственно так и не понял что конкретно мне прокомментировать. Может быть Вы сформулируете вопрос чётко и обозримо?

Да, см. ниже.

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

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

Не хотите ли Вы сказать, что программа Hugo имеет доказательную силу?

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

Но ведь Вы помните что работать оно будет только у Вас и у Демиса и всё? Потому что только вы двое разобрались с компиляцией моих исходников.

Разобрались мы, разберутся и другие, ежели пожелают. Здесь не вижу особой проблемы. Раньше-то у нас были миллионы паттернов, а сейчас всего 1 тысяча.

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

Нет, нету такого смысла. Оно полностью выполнится быстрее чем писать тест.

Не согласен. Я против категоричных формулировок. В данном случае Евгения: "Вообще нет никакого смысла." Сразу два таких слова: "Вообще" и "никакого". А ведь нередко смысл находится.

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

Евгений мне не ответил, а Вы, когда считали по прогам Hugo, получили хоть одну цепочку для сравнения?

[Dmitriy40]

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

Не хотите ли Вы сказать, что программа Hugo имеет доказательную силу?

Нет, не хочу. Я его код не смотрел (да в общем и не собираюсь, чукча в моём лице не читатель, а писатель, своих прог ). Соответственно любые мои утверждения такого рода были бы основаны на чужих словах.

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

Евгений мне не ответил, а Вы, когда считали по прогам Hugo, получили хоть одну цепочку для сравнения?

Мне помнится я видел его ответ на такой вопрос. Или то был сам Hugo? Вот этого не помню.
Ответ простой: как можно их получить если программа Hugo их не выдаёт в принципе? О чём Hugo прямо сказал:

Huz в сообщении #1569241 писал(а):

It would not be possible to get that information from my code without substantial changes, and those changes would make it much slower. At each level of the code, it is designed to reject specific chains of length 11 as early and as quickly as possible.
This is why I said before that changing my code to handle overlaps would need a complete rewrite.

На этом я посчитал данный вопрос закрытым.
Можно ли их получать хотя бы в режиме отладки (-debug или какой там у него ключ) или насильно туда это добавить (ведь на скорость в этом случае уже плевать) - вопрос, но имеющий мало смысла: надо очень и очень внимательно разбираться чем именно отличаются release и debug версии, для этого надо прекрасно разбираться в стандарте языка С (чем например я не похвастаюсь) и используемом компиляторе, либо сверять получаемый асм код и тогда соответственно неплохо знать асм. Потому что очень легко может получиться что в режиме отладки будут выдавать совсем не те цепочки (будут лишние или пропущенные) что проверяются в нормальном режиме (именно для этого надо или знать стандарт или сверять асм код). Не потому что где-то ошибся (хотя вообще говоря это именно ошибка программиста), а потому что компилятор слишком умный и может выкинуть такие фортели, которые и в страшном сне не привидятся (если сразу не знаешь про такую возможность, т.е. стандарт языка С). Обладает ли Hugo необходимой квалификацией - спрашивайте его сами, я не ставлю перед собой задачу доказательства правильности его кода, мне простите своих заморочек хватает (а компилятор асма таких фортелей не выкидывает, да и я же в отладчике прохожу код при подозрении на ошибки, руками сверяя все вычисления в программе).

PS. О планах разработки моей ожидаемой программы.
Буквально только что пришла в голову мысль как близко к реальности оценивать потребное время для смены режимов перебора, сразу на конкретном компе и конкретном паттерне, это одномоментно решает 90% моих проблем с запуском вложенных переборов. Буду проверять насколько она реальна и полезна.
Но в ближайшие дни точно не сделаю, не надейтесь, мне платы ещё паять и паять, а в "перекурах" такие вещи не делаются.

[Yadryara]

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

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

Не хотите ли Вы сказать, что программа Hugo имеет доказательную силу?

Нет, не хочу.
Я его код не смотрел (да в общем и не собираюсь,

Тогда почему Вы советовали предпочесть его код Вашему, даже если Ваш в разы быстрее ??

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

Ответ простой: как можно их получить если программа Hugo их не выдаёт в принципе? О чём Hugo прямо сказал:

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

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

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

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

Никто не торопит, вроде

[Huz]

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

Huz
Can I suggest a purely cosmetic change?
At least under windows, change the title of the console window to the current progress of the account, for example in the format "b1850-19", that is, the pattern number and the iterated number at the highest level of recursion. And change the title no more than once a second. I don't know how it is under *unix, I think exactly the same by calling the OS function, but under windows there is definitely the corresponding winapi function.
It is very convenient to monitor the progress of the calculation, especially when there are several of them at the same time.

Ah, I found this back - I thought it was in my email somewhere.

I'm interested in implementing this, but it is not obvious to me what information it is useful to show: half the time, "the iterated number at the highest level of recursion" changes fast enough that it is effectively a random number.

It might be better to show the primes at the first few levels of recursion that are not fixed by the pattern, I will experiment.

It looks like both Windows and Unix support VT100 escape sequences to control this.

(later) This is now implemented via commit 9896fe3e.

Add the option "-v" to enable it. It will update the window title and icon (shown when minimized) once a second, showing the current batch number and the first few non-fixed primes being iterated. On completion, it will update the title to "done".

This should become available with the next release build.

[Dmitriy40]

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

Hugo с тех пор уже переделывал код.

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

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

Тогда почему Вы советовали предпочесть его код Вашему, даже если Ваш в разы быстрее ??

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

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

Я не говорил что его код не имеет доказательной силы, не надо пожалуйста приписывать мне некорректные утверждения, я говорил что не могу утверждать что его код имеет или не имеет доказательной силы. Я не знаю. Потому оба утверждения с моей стороны, и "имеет", и "не имеет" - необоснованны (но и не обязательно ложны).
Считать лучше более медленным вариантом (его программой) потому что ради доказательности (а не просто поиска меньшей цепочки!) лучше использовать более надёжный код. Не 100% надёжный, я не знаю так ли это, но он точно более надёжный, этому много признаков. Считать же более быстрым и менее надёжным кодом можно, но не ради доказательства минимальности, а ради поиска меньших цепочек, только в этом случае меньшая надёжность роли не играет, результат легко проверяется другими средствами (разложением чисел цепочки). Но я вслед за Hugo считаю что вероятность найти меньшую цепочку довольно мала (насколько именно разумеется оценить невозможно). И каждый сам выбирает какую задачу ему интереснее решать, поиск меньшей с почти гарантированными шансами на неуспех (т.е. моими программами), или доказывать минимальность известной (или другой найденной) программой Hugo.
Простите, но у меня ощущение что Вы снова лезете в какие-то дебри или излишние формальности (не буду говорить придирки), ловите на каких-то якобы противоречиях (что меня, что Евгения), зачем всё это? Что оно добавит пониманию? И чьему? Вашему? ОК, ну так спросите прямо, например почему (т.е. какими мотивами или причинами руководствовался) я рекомендовал то или то, я объясню, а не тыкайте носом мол Вы рекомендуете считать более медленной программой, с ума что ли сошли или это недобросовестная конкуренция. Шучу. Конкуренция конечно недобросовестная, но немного в другом плане, не про неправомерный отказ от более быстрых программ. Сразу и отвечу, не дожидаясь вопроса в каком: не все свои наработки показываю и тем более объясняю как и почему так. И не всегда из-за жлобства, чаще просто долго и муторно объяснять в деталях (а нередко и собеседник не поймёт объясняемого, это не оскорбление, не все хорошо разбираются в устройстве процессоров). Считаю что как автор имею право на некоторое преимущество, тем более оно временное.

EUgeneUS
Как-то у меня нет большого желания заниматься доказательностью своих программ ... Они не для того писались. Разве что ради своего же лучшего понимания почему они работают правильно. И уж тем более у меня ненависть к формализму. Но только излишнему. Методику организации корректных экспериментов (тестов) я как раз вполне уважаю и лишней не считаю (хоть ей и не учили).

Huz в сообщении #1569753 писал(а):

"the iterated number at the highest level of recursion" changes fast enough that it is effectively a random number.

I must have expressed myself badly: I meant the slowest changing number. The one that iterates first.
Simply because this designation is easy to get without adding extra code and without taking up computing time.

Huz в сообщении #1569753 писал(а):

(later) This is now implemented via commit 9896fe3e.
Add the option "-v" to enable it. It will update the window title and icon (shown when minimized) once a second, showing the current batch number and the first few non-fixed primes being iterated. On completion, it will update the title to "done".
This should become available with the next release build.

Great, it looks like this is exactly what I wanted, how the release will be - let's rejoice.

[Huz]

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

Huz в сообщении #1569683 писал(а):

Please could you email me the log file for one or both of these runs?
It may be that optimal -g varies for different patterns, but when I tested this for other cases in the past it seemed similar for most patterns. I found -g16 by testing with b1630.

Of course I will send it by mail, no question.

Thank you, but this is no longer needed.

With b1630 (lcm 42688800, 5 prime places, 6 non-prime) best value was -g16.
With b1632 (lcm 3880800, 5 prime, 6 non-prime) best value was also -g16.
With b1850 (lcm 42688800, 6 prime, 5 non-prime) best value was between -g7 and -g8.

So as a first approximation, I suggest to use -g16 when there are 5 prime places and -g8 when there are 6 prime places, ignoring the LCM. I will try to get more data points, but I don't have an efficient way to do this, it is quite time-consuming.

When I have a more complete set of values, I will publish the recommended value (somehow) for every pattern.

To check on terminology, when you talk about "checked places", I think you are talking about the number of places where the remaining factor is not prime, and that you therefore check in PARI - so b1850 has 5 checked places, and b1630 has 6 checked places. Is that correct?

[Dmitriy40]

Huz в сообщении #1569770 писал(а):

To check on terminology, when you talk about "checked places", I think you are talking about the number of places where the remaining factor is not prime, and that you therefore check in PARI - so b1850 has 5 checked places, and b1630 has 6 checked places. Is that correct?

No, I'm not quite sure I understand your interpretation. I (we are in this topic) call the places to be checked those where, in fact, there are already 6 divisors and only one unknown prime in the first degree remains to be found. This can be both initially in the pattern, and after substituting the square of a prime number when iterating over the latter. And I often shorten "to be checked" only to "checked", it's exactly the same thing in this context. And these are not the places where the squares of prime numbers will iterate. In b1850 there are 6 checked places, in b1630 there are 5, i.e. we are talking exactly the opposite.
So these places were named because they are the only ones my program can check, called from PARI to speed up the search (in PARI it is too slow).
The bundle of asm+PARI is used because asm is fast, and PARI has already implemented work with long numbers and a good check of numbers for prime (including very large ones) and CRT. It all started with pure PARI code, an external program on asm to speed up the search was added later. As a result, my program checks the numbers for prime only in a limited way, but at once all the "checked" in the pattern, passes the likely candidates for solutions to PARI, and PARI already checks them that all numbers are indeed prime (and give exactly 12 divisors) and outputs the result. In fact, my program acts as a fast filter that receives an input interval of natural numbers $i=a...b$ from the formula $n=n_0+im$ ($n_0,m$ gives from CRT) and leaves only those numbers $i$ that probably give a solution that is already being fully rechecking by a slow PARI. There are hundreds or thousands of times fewer such candidates than all $i$, so the slowness of PARI does not affect the final search speed as much.

-- 11.11.2022, 23:51 --

Just to add, my program checks all numbers in pattern with 6 divisors are not divisible by prime numbers up to the threshold specified during compilation (usually we take 2^12=4096, it is the best speed in tests) and such $i$ return to PARI (or actually anywhere, it is just a vector of numbers in text form) for the final recheck. And of course, the more numbers from pattern can be checked in my program, the earlier exactly unsuitable candidates are discarded and the faster $i$ search goes, that's why for my programs it is important how many such numbers in pattern and the more the better (up to 7 or 8, further speed is not increasing, but filtering is improving, which reduces the work of PARI on their recheck).

-- 12.11.2022, 00:06 --

Huz
If the word "checked" for places where we are looking for the remaining prime number in the first degree is too obscure, then suggest another option, I do not speak English too well.

[Huz]

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

Huz в сообщении #1569770 писал(а):

To check on terminology, when you talk about "checked places", I think you are talking about the number of places where the remaining factor is not prime, and that you therefore check in PARI - so b1850 has 5 checked places, and b1630 has 6 checked places. Is that correct?

In b1850 there are 6 checked places, in b1630 there are 5, i.e. we are talking exactly the opposite.

Ah ok, so checked in the assembler, not checked by PARI.

Цитата:

If the word "checked" for places where we are looking for the remaining prime number in the first degree is too obscure, then suggest another option, I do not speak English too well.

The word is fine, I just misunderstood which part of the code was doing the checking. :)

[Dmitriy40]

Huz в сообщении #1569791 писал(а):

I just misunderstood which part of the code was doing the checking. :)

Both. Asm is fast and not too accurate, PARI is slow in double-checking all the candidates issued from asm. By candidates I mean chains with pseudoprime numbers found in "checked" places, not guaranteed to be prime, but only not divisible by the first few prime numbers (up to 4096). All these numbers in PARI are rechecked if they are prime, and if so, already without any pseudo (except that ispseudoprime() in PARI does not guarantee that the numbers really are prime, but no examples of errors are known) and only then the chain from the candidate becomes a solution.
This allows asm program to work only with not too big integers ($i$ from formula, neither $m$ nor $n_0$ nor $n=n_0+im$ appear anywhere in asm program, only 64bits $i$ and limits of its check), and in checking divisibility in general in arithmetic by module (corresponding prime number). Which lays well on SSE/AVX calculation technology and allows to handle 8-16 residues from dividing of pattern numbers by prime numbers at once.
64 bits of $i$ is not always enough, but the programs were written for the limited search problem $D(12,15)$ (not minimal, any), and there $m=4.4\cdot10^{26}$ and this range $i$ was supposed to be enough for good. Moreover, it is unreal to check it all the same, it is years and years of counting in many threads. By then I would have thought of something else.

[Yadryara]

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

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

Вы имеете в виду, что я приписывал Вам какие-то некорректные утверждения? Какие же?

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

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

А я говорил. Уточню свои слова. Тут работает стандартная презумпция.

Не доказано, что код Hugo имеет доказательную силу.

А то что не доказано, не может иметь доказательной силы.

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

Увижу доказательство, могу изменить мнение.

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

Считать лучше более медленным вариантом (его программой) потому что ради доказательности (а не просто поиска меньшей цепочки!) лучше использовать более надёжный код. Не 100% надёжный, я не знаю так ли это, но он точно более надёжный, этому много признаков.

Болд мой. Каковы же эти признаки, что он точно более надёжный ?

Я как раз наоборот пока считаю Ваш код более надёжным. По той простой причине, что он выдаёт множество цепочек и по этим цепочкам его можно тщательно проверить.

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

Простите, но у меня ощущение что Вы снова лезете в какие-то дебри или излишние формальности (не буду говорить придирки), ловите на каких-то якобы противоречиях (что меня, что Евгения), зачем всё это?

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

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

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

И уж тем более у меня ненависть к формализму. Но только излишнему.

То-то и оно, что ещё нужно определить какой формализм излишен, а какой нет.

[Dmitriy40]

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

Вы имеете в виду, что я приписывал Вам какие-то некорректные утверждения? Какие же?

Вот это:

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

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

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

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

Каковы же эти признаки, что он точно более надёжный ?

Стандартные в области программирования: а) открытость исходного кода (возможность его независимой проверки любому желающему); б) использование систем контроля версий (видны все доработки); в) один и тот же код выдаёт много разных результатов (цепочки другой длины) и не выдаёт лишних; г) не помню где Hugo это говорил или намекал, но ощущение что он проводит какие-то более-менее формальные тесты для каждого релиза (например точно видел про сравнение внутренних счётчиков); д) впрочем уже достаточно.
Ко мне ограниченно применим лишь пункт в. Мой код проверить на отсутствие лишних решений весьма затруднительно, я это изредка делаю (в особо запутанных случаях подозрения на ошибку), но далеко не каждый раз. Потому что мне это и не особо нужно, всё лишнее отсеется в PARI, а задачи не пропустить возможное решение вообще не ставилось, только найти любое. И ситуации когда разные версии находят разные цепочки и по этому признаку их корректность не сравнить (без детального разбора каждой различающейся цепочки, выше в теме немало таких примеров) — обычна и детальный разбор производится не всегда, что-то находят и ладно, поставленную задачу решают.

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

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

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

-- 12.11.2022, 12:23 --

Утром завершился тест версии Hugo 20221109 с ключом -g16, она оказалась несущественно медленнее её же с ключом -g3:

001 pcoul(12 11) -f11 -g16 -x9887353188984012120346 -b1850 *RT*
367 coul(12, 11): recurse 35340867700, walk 35340898395, walkc 64708339994 (112114.00s)
vs
001 pcoul(12 11) -f11 -g3 -x9887353188984012120346 -b1850 *RT*
367 coul(12, 11): recurse 13885499262, walk 13885504131, walkc 129303981142 (100465.27s)

Hugo выше сказал что считает оптимальным -g8, но такой тест ещё на сутки запускать уже не буду, разница в 11.6% меня устраивает.

[Yadryara]

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

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

Вы имеете в виду, что я приписывал Вам какие-то некорректные утверждения? Какие же?

Вот это:

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

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

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

Можно понять, да. Мы нередко друг друга неправильно понимаем. Но где я именно приписываю Вам эти слова ?

Вы процитировали мои слова. Да, я пока что считаю, что доказательной силы не имеет. Это именно моё мнение, Вам я его не приписывал. Если считаете по-другому, приведите, плиз, ссылку, где я Вам это приписывал.

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

Каковы же эти признаки, что он точно более надёжный ?

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

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

Допустим, что есть такой код и он действительно доступен.

Кто именно его проверял и где об этой проверке можно прочитать?

На всякий случай уточню, что я недостаточно компетентен в Сях и сам проверять не планирую.

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

б) использование систем контроля версий (видны все доработки);

Тот же вопрос: кто именно проверял доработки?

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

в) один и тот же код выдаёт много разных результатов (цепочки другой длины) и не выдаёт лишних;

Имеется в виду, что автор 8-ки, 9-ки и 10-ки тоже Hugo ? Но ведь минимальность этих цепочек не доказана.

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

г) не помню где Hugo это говорил или намекал, но ощущение

Вы не помните где, а мне вот вспомнился анекдот:

"- Хаим, я слышал вы выиграли миллион в лотерею! Это правда?
- Не совсем.
- Что значит не совсем?
- Ну во-первых не миллион, а тысячу. Во-вторых, не в лотерею, а в карты. И в третьих, не выиграл, а проиграл."

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

д) впрочем уже достаточно.

Увы, совершенно недостаточно.

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

Вы же ловите на якобы противоречивых высказываниях (чем считать чем не считать), это суждения, личное мнение, это не объективно.

Но можно ведь постараться быть более объективным. Вы по-прежнему считаете, что для счёта 11-к нужно пользоваться кодом Hugo, а не Вашим?

[Dmitriy40]

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

Имеется в виду, что автор 8-ки, 9-ки и 10-ки тоже Hugo ? Но ведь минимальность этих цепочек не доказана.

Имеется в виду и ещё куча цепочек, других длин и/или с другим количеством делителей, по той же программе.

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

Вы по-прежнему считаете, что для счёта 11-к нужно пользоваться кодом Hugo, а не Вашим?

Это некорректный вопрос. И на него ответа не будет.
Выше неоднократно поясняли что есть две разные задачи: доказательство минимальности и поиск меньшей. И для них можно (и нужно) применять разные подходы и программы.
Да, я по прежнему считаю что для доказательства минимальности лучше пользоваться программой Hugo. Всё выделенное жирным — существенно! И не надо это опускать или заменять на "нужно", это искажает смысл вопроса/ответа. И не надо искать выше где я тоже употребил "нужно", я точно помню что везде лишь советовал, а не заставлял, даже если и сказал "нужно".

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

-- 12.11.2022, 14:57 --

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

[Yadryara]

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

Выше неоднократно поясняли что есть две разные задачи: доказательство минимальности и поиск меньшей. И для них можно (и нужно) применять разные подходы и программы.

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

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

Да, я по прежнему считаю что для доказательства минимальности лучше пользоваться программой Hugo. Всё выделенное жирным — существенно! И не надо это опускать

Вот теперь уже Вы проявили дотошность. Правильно сделали.

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

Я вам даже больше скажу: если Hugo или кто угодно другой что-то там запустил и ничего не нашёл — это ещё не доказывает что меньшего нет.

О чём и речь. Даже если два разных человека на разных компах запустили и то не доказывает.

Тогда если запускал лишь один, то тем более не доказывает. Какая уж тут доказательная сила. Может быть вероятность, что нет ошибок за 99% и перевалит.

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

Всегда возможен случайный сбой в процессоре, памяти (ECC спасает не от всего), диске (аналогично, даже зеркальный RAID не полностью гарантирует надёжность).

Вот именно что таких факторов немало.

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

И это ещё не говоря о том что доказательный код изначально должен писаться несколько по другому, с учётом гарантии надёжности. А это весьма и весьма непросто (и почти всегда увеличивает объём кода и замедляет его).

Вот именно что весьма и весьма непросто. Так что не вижу я пока причин, по которым стоит предпочесть более медленный код. И тот и другой довольно далеки от известных Вам стандартов.

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

Для доказательства нужна вторая проверка, и лучше независимая (на другом компе).

Да. Если Вы заметили, я ещё 8 лет назад спрашивал о независимой проверке в OEIS.