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

[VAL]

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

This was unexpected, after 440 CPU days found a new lower bound for D(48,10)

This is the reason why I'm not trying to find minimal chains. D(48.23) was found faster than your D(48.10)

$M(1408)=7$

3060278483597425530008549154579391746768732459946324087982095788737108148442588152975844860866349052906425781245

И вновь все 7 чисел факторизуются без затруднений (All 7 numbers are factorized quickly).

[EUgeneUS]

VAL в сообщении #1726928 писал(а):

This is the reason why I'm not trying to find minimal chains. D(48.23) was found faster than your D(48.10)

Тут, конечно, зависит от того, что понимается под "440 CPU days"
1. Если это 440 дней работы современного CPU на 24 потока\нити, то, да - это много.
2. А если это 440 дней работы в расчете на один поток\нить, то это сильно меньше, чем мы с Вами потратили на поиск D(48.23).

[VAL]

EUgeneUS в сообщении #1726931 писал(а):

Тут, конечно, зависит от того, что понимается под "440 CPU days"
1. Если это 440 дней работы современного CPU на 24 потока\нити, то, да - это много.
2. А если это 440 дней работы в расчете на один поток\нить, то это сильно меньше, чем мы с Вами потратили на поиск D(48.23).

Согласен.
Но и Вы согласитесь, что цепочки D(48,10) встречаются несколько чаще, чем D(48,23)

-- добавлено через 59 минут --

$M(1568)=7$

1056658972734628470319569543896924117608801592469715975608781269107270671530019899102674811105386547104257828890785626073191586562781245

И вновь все разложения не занимают много времени.

[Huz]

VAL в сообщении #1726928 писал(а):

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

This was unexpected, after 440 CPU days found a new lower bound for D(48,10)

This is the reason why I'm not trying to find minimal chains. D(48.23) was found faster than your D(48.10)

Well, I'm working to find values for the OEIS sequence: for the purposes of the OEIS there is limited value in ever more upper bounds. I'm about 40% of the way through the search space for D(48,10), and the new result (at batch 595451 of 1423740) will speed up the rest of the search substantially (already now at 641196).

I'm just sad I didn't find the better result earlier - the space already searched would probably have been completed in less than 100 days - but I don't know how I could have found it without the exhaustive search.

[VAL]

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

Well, I'm working to find values for the OEIS sequence: for the purposes of the OEIS there is limited value in ever more upper bounds. I'm about 40% of the way through the search space for D(48,10), and the new result (at batch 595451 of 1423740) will speed up the rest of the search substantially (already now at 641196).

I'm just sad I didn't find the better result earlier - the space already searched would probably have been completed in less than 100 days - but I don't know how I could have found it without the exhaustive search.

Good luck in your search!

[Huz]

VAL в сообщении #1726954 писал(а):

Good luck in your search!

Thank you, and you in yours. :)

[EUgeneUS]

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

but I don't know how I could have found it without the exhaustive search.

Using exactly the same method we used to find record-breaking chains—selecting promising batches.
In your case, by ranking the batches from most promising to least promising and searching starting with the most promising.

-- добавлено через 3 минуты --

For example, if, before finding an improvement, batches with large powers (more squares) or with one or more prime numbers among the unknowns were calculated, this is wasted time.

-- добавлено через 5 минут --

EUgeneUS в сообщении #1726988 писал(а):

batches with large powers (more squares)

excluding $2^5$

[VAL]

$M(1232)=7$

n = 8854988368788484335668564655966116008728871612928964942270551038550490985811321390269615310344696189490759475890113210079861096109342581026425781245

n+2 =  7^10 × 37^6 × 27 637451 × 3110 240804 756081 × 295 818630 331096 249166 395079 × 480 484882 738042 713796 553217 542840 102664 994287 952653 445353 142454 579233 710592 650883 (81 digits) 

[Dmitriy40]

VAL
Первое число разложилось:
3895460131248082585082934401926160245051109304087122014120755126507886194291502744221420709079685005760649070362691506576946946037029338067176093 = 7407472450050112956531321126612987422716617947270585822687 х 525882500072170914144437381157827996671888849796402863393112195051521679387879350279939
Потребовалось 6.2 суток, из них 5.6 суток на GNFS.
Мне не понравилось, 145 цифр всё же многовато.

[VAL]

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

VAL
Первое число разложилось:

3895460131248082585082934401926160245051109304087122014120755126507886194291502744221420709079685005760649070362691506576946946037029338067176093 = 7407472450050112956531321126612987422716617947270585822687 х 525882500072170914144437381157827996671888849796402863393112195051521679387879350279939

Спасибо!
Это дает
$M(464)=7$

n = 674678460295239520581275636802165857377801700352017083763814906203453918411686521250399395691114897680042711889439006595160199559535334754234759464486074558743239954784512519836425781245

Разложение $n+6$ см. выше. Остальное раскладывается легко.

Цитата:

Потребовалось 6.2 суток, из них 5.6 суток на GNFS.
Мне не понравилось, 145 цифр всё же многовато.

Понял. Принимаю к сведению. И сразу реагирую

452081 502119 354677 086257 355217 309013 441326 249827 221865 736581 082011 653477 399252 075397 845071 324961 018520 712769 272016 579832 610891 (126 digits) = pq?

Интересное наблюдение насчет Alpertron'а. На ноутбуке он в спячку не уходит. В отличие от моего основного компа. Так что, это что-то у меня в настройках изменилось. Но что, Бог весть...

[Huz]

EUgeneUS в сообщении #1726988 писал(а):

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

but I don't know how I could have found it without the exhaustive search.

Using exactly the same method we used to find record-breaking chains—selecting promising batches.
In your case, by ranking the batches from most promising to least promising and searching starting with the most promising.

For example, if, before finding an improvement, batches with large powers (more squares) [excluding $2^5$] or with one or more prime numbers among the unknowns were calculated, this is wasted time.

In some cases I do this manually, in a crude manner guided by intuition. I don't know enough to program it. I don't believe we know a simple metric such as LCM that would be sufficient on its own to provide a useful ordering.

[EUgeneUS]

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

In some cases I do this manually, in a crude manner guided by intuition. I don't know enough to program it. I don't believe we know a simple metric such as LCM that would be sufficient on its own to provide a useful ordering.

This is based on simple principles:
1. The probability of success when checking a single candidate
2. The change in the probability of success as increase the numbers in the chains
3. If we check up to a fixed value, the number of checks in a given pattern/batch

But upon further examination, it turns out that these simple factors depend intricately on many others. And that's sad.

However, approaches have already been developed for assessing the viability of certain batches, at least roughly.
These approaches are unlikely to be programmed into code right now.

The question arises: is it worth spending several weeks on a semi-manual analysis, or is it better to launch a brute force calculation immediately?

For your purposes, the answer to this question depends, among other things, on the probability of improving the existing lower bound.

And the answer to this question depends on how this lower bound was obtained.

Ranking batches makes sense if:
a) the calculation will take a long time (more than 2-3 months, for example)
b) the method for finding the current boundary suggests an improvement of an order of magnitude or more.

Then, yes, you can spend 1-2 weeks evaluating different batch types, programming batch calculation runs in a different order than how pcoul generates them.

-- добавлено через 15 минут --

EUgeneUS в сообщении #1727086 писал(а):

And the answer to this question depends on how this lower bound was obtained.

F.e. I don't know how anyone got the upper bound of D(48.10), which you improved by an order of magnitude.
But after the fact, looking at the batch in which the improvement was found, I can say that yes, the improvement was very likely.

[Huz]

EUgeneUS в сообщении #1727086 писал(а):

F.e. I don't know how anyone got the upper bound of D(48.10), which you improved by an order of magnitude.

Logs suggest that I added it to my database on 2022-02-13. My first commit for 'oul' (onestep-upper-limit) was in January 2022, so my guess is that it was an early result from that precursor of pcoul.

It may even have been the first such result recorded - a commit message from two hours earlier says:

Date:   Sun Feb 13 17:46:16 2022 +0000
    divrep: store partial results

    Mark runs as "partial" if they are not intended as proof that a result
    found is minimal, and record such results as an upper bound on f(n,k).

[EUgeneUS]

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

Logs suggest that I added it to my database on 2022-02-13. My first commit for 'oul' (onestep-upper-limit) was in January 2022, so my guess is that it was an early result from that precursor of pcoul.

It may even have been the first such result recorded - a commit message from two hours earlier says:

Based on this information, it's difficult to estimate the a priori probability of improving the found bound.

But given:
1. My observations of the order in which pcoul generates batches.
2. The assumption that the search was stopped when the upper bound estimate was found.
It can be assumed that not all promising batches were tested.
This means the probability of an order-of-magnitude improvement was not so small.

Based on intuitive estimates, I can say:
1. Vladimir's estimates obtained before 2025 (and most likely later) can very likely be improved by 2-3 orders of magnitude or more.
1.1. Vladimir used promising batches, but not the full range of promising batches. This explains why the numbers were higher than expected.
2. All estimates obtained using Dmitry's accelerators can, with good probability, be improved by 1-2 orders of magnitude.
2.1. Except for D(12, 15), for which an additional search was performed using large prime square substitutions. And the initial estimates have already been improved by a factor of approximately 30 (if memory serves me correctly).
3. All estimates found at the end of 2025 - beginning of 2026 can be improved by 1-2 orders of magnitude.
3.1. These searches involved a large number of promising batches. However, the number of primes inserted into squares was small.

Each improvement will require more time than was spent on finding the corresponding upper estimate.

[VAL]

$M(1216)=7$

n = 1239312462597605675939729693236226691591512347599354966672751943626236978693152761634243581417317512672975918783856977552431996683512519836425781245

 n+4 = 7^18 × 937 × 41863 × 1293 513269 × 12672 633164 657041 × 1183 609402 681783 453600 063107 795673 799252 267574 878728 065472 979965 960341  401664 822041 247155 430485 050499 (100 digits) = pq?