Отправлено: 25.10.16 13:00. Заголовок: След в истории
Итак, начинаем новый проект по поиску делителей.
Идею подсказал наш администратор команды Алексей.
Смысл проекта: найти в каждом миллионе хотя бы 1 делитель.
Преамбула: На текущий момент найдено уже 16 243 делителя в разных миллионах.
В нулевом миллионе был найден есм-делитель - 855527, также было найдено 2 делителя в 5-м миллионе, далее будем искать последовательно в каждом миллионе, как минимум, по одному делителю.
Продолжительность проекта: до 31 декабря 2017 года (прогнозное значение).
Отправлено: 26.10.16 12:43. Заголовок: Организация работы
Насколько я понял, поиск будет вестись в тех миллионах, где наша команда ещё не нашла ни одного делителя. Предлагается вести в этой теме список миллионов, требующих рассмотрения, и постепенно исключать (вычёркивать) их по мере нахождения делителей. При этом указывать кто, когда и каким способом нашёл делитель.
Убрали строчку 930-х миллионов, теперь копаем 921-й миллион, там грызли неплохо, причем выгружали только задания с найденными делителями, вот пришлось до 73-го бита углубится...
Мне кажется, что лучше было бы не удалять заполненные строчки, а менять цвет фона и в "миллионе" ставить не крестик а экспоненту у которой найден делитель.
Осталось найти делители в 359 миллионах, как видите, проект уже подошел к двум третям.
Начинаются самые трудоемкие расчеты, так как битность возрастает, что увеличивает время обсчета каждой экспоненты и, следовательно, сокращают количество проверяемых кандидатов за день.
Дорогие друзья - все, все, все ! Поздравляю каждого из вас с наступившим Простым 2017 годом !!!
И так как 2017 имеет вид 4K+1, где K=504 в данном случае, то по одной из золотых теорем времён Гаусса и даже Ферма существуют такие целые m, n, что 2017 = m^2 + n^2
Тому, кто их найдёт, будет весь год сопутствовать удача :-)! Я нашёл :-).
Отправлено: 15.01.17 21:13. Заголовок: 875-й миллион
В процессе поиска делителей дошел до 875-го миллиона. Как его назвать - странный, подозрительный, невероятный, фантастический? Как там искать НОВЫЕ делители?
vasyannyasha - тут каждый сам для себя решает. Ведь 2-й делитель - тоже результат, хоть и не столь значительный. Некоторые миллионы просчитаны уже настолько высоко, что поиск обещает быть весьма продолжительным. Я за себя думаю подстраховаться в проблемных миллионах: сначала найду 2-й или более делитель (помечу его звездочкой в таблице), а уж потом буду искать 1-й.
Отправлено: 23.05.17 09:31. Заголовок: Нужно вручную создат..
Нужно вручную создать задания из экспонент с уже найденными маленькими делителями, указать более широкий диапазон проверки бит, а в файле mfaktc.ini поставить значение StopAfterFactor=0 чтобы он не прерывал проверку экспоненты после 1-го найденного делителя.
Отправлено: 21.09.17 12:25. Заголовок: Есть подозрение, что..
Есть подозрение, что 0-й миллион плотно просеян ECM-ками, и мелких делителей там почти не осталось. Попробуйте считать сразу полосой 65-72 бита, вдруг повезет быстрее!
Table - njrfn "Второй круг" почти заканчивается, но будет все медленнее и медленнее... Очередной делитель: 37169983 2021-01-23 Factor: 34758198916866402622031 / TF: 74-75*
Отправлено: 16.02.25 02:44. Заголовок: Сорри за прошлое соо..
Сорри за прошлое сообщение, хотел проверить, прежде чем писать текст. Решил тоже занять подобным развлечением. Без каких либо обещаний себе, что доделаю. Как пойдет. Если забью, то забью. Но пока делаю. И к чему пишу тут - скорее что сделал себе html'ку, чтобы автоматом табличка заполнялась: https://nstorm.ru/1FM Хотя смотрю активности тут очень мало, может кому пригодится. Можно утащить себе - соб-но весь код с браузера просмотреть можно, всё в одной HTML + еще есть файлик php, там банально кешер запросов к mersenne.ca. Его вышлю, если надо кому, но в самом простом виде там в 3 строчки написать можно (у меня чуть сложнее вариант с проверкой даты обновлений и сжатием локального кеша JSON'ов). А в простом виде, можно использовать и с моего сайта. Нужно в параметре 'u' передать свой userid, как его показывает mersenne.ca - сходить на https://www.mersenne.ca/user_recent_factors.php, вбить свой ник и перейти по ссылке. Потом смотрим адрес (URL), в конце будет userid: https://www.mersenne.ca/user_recent_factors.php?u=NNNN Вот часть "?u=NNNN" взять и подставить после моей ссылки. Чтобы получилось https://nstorm.ru/1FM?u=NNNN. Только NNNN ес-но должны быть цифры. Если что-то неправильно - будет открываться страничка с моими результатами. Если правильно, то другая. В самом низу пишет ник, кого загрузило. Например для [b]njrfn[/b] (раз уж вы тут последнюю активность проявляли ;) ссылка: https://nstorm.ru/1FM?u=292 Смотреть в первую очередь ориентировал на комп, не телефон. При наведении мышкой на экспоненту, всплывает инфа о найденном делителе.
Ограничения: 1) данные берутся с mersenne.ca, они отстают на сутки всегда. Так что за текущий день результатов не будет видно. Даже несмотря на то, что внизу будет актуальная дата и время - это время создания JSON'а, а не инфы в базе. Скрипт кеш обновляет если он старше 2 часов или начался новый день в часовом поясе по Гринвичу (GMT) - когда соб-но у mersenne.ca обновляются данные и появляется следующий день; 2) если в одном диапазоне (клетке) было найдено несколько делителей, показывается экспонента только последнего найденного всегда. В каком порядке выдает mersenne.ca - берется 1ое (самое новое) вхождение и всё. 3) если делителей найдено было больше 10000 всего - данные заполнятся только из последних 10000, сколько за раз может выдать mersenne.ca (не заморачивался с "многостраничной" загрузкой, т.к. больше 10000 - редкость большая, но есть такие аккаунты из старых видимо, когда можно было пахать поле TF низкой битности.
Отправлено: 02.03.25 03:21. Заголовок: Еще оставлю от себя ..
Еще оставлю от себя условия, которые я себе поставил: - В диапазонах, которые еще не полностью покрыты PRP или LL тестами - в 1ую очередь брать экспоненты без известных делителей и оных тестов. Т.е. которые еще потенциально могут быть простыми числами Мерсенна. Т.к. исключение оных экспонент, путем нахождения делителей нужны проекту и несут пользу. - В диапазонах, где уже всё проверено тестами PRP/LL - стараться хотя выбирать в первую очередь экспоненты еще без известных делителей. Хотя бы как финальное подтверждение проведенных тестов будет. За редкими исключенями. Иногда придерживаться этих условий слишком сложно. К примеру, в диапазоне 875-го миллиона сейчас все экспоненты без известных делителей TF-ом уже покрыты аж до 80го бита. TF после 80го бита, и P-1, тем более ECM в этом диапазоне слишком долгие. Поэтому тут поискал уже среди экспонент с известными делителями, но нашел новые, "большей битности". Наверное можно было бы поискать P-1 с небольшими границами B1-B2. Но результаты с границами, меньше рекомендованных, потом могу затруднить выборку из базы экспонент по критерию "без P-1 тестов", хотя он и будет мало показательным, в случае ненахождения делителя. Поэтому не стал подобное делать.
Alex_soldier, доброго дня! Домашний комп - AMD Ryzen 7 7700X / 64 Gb / RTX4090. Но частенько, пользуясь случаем "провести нагрузочное тестирование", подключаю по работе серверы на какое то время. Соб-но и задача стресс-теста по сути выполняется, и польза в проект. Конфигурации разные, но конечно же мощнее. Также тестирую иногда всякие облачные сервисы на предоставляемых бесплатных тестовых периодах аналогично запускаю.
Отправлено: 02.03.25 21:39. Заголовок: PS: Если о результат..
PS: Если о результатах идет речь про GHz-days накопленных, то тут имеет место некорректное начисление очков за ECM в больших диапазонах (B1-B2). Известный "баг", на mersenneforum писали за него. Я в кач-ве другой цели пытаюсь найти большой делитель среди малых значений экспонент без известных делителей (M1619, к примеру). За ECM с B1=2400000000 (который актуален сейчас для данной экспоненты) и на несколько порядков больший B2 начисляется слишком много очков GHz-days, которые не соответствуют затраченному времени. При наличии 64 Гб ОЗУ и определенных настройках mprime, чтобы на 2ую стадию дополнительные ядра включались, чтобы больше памяти на словарь 1ой стадии выделялось и т.д. тюнится так, что домашний комп проверяет примерно 1 кривую в час на потоке и в параллель (т.к. 1ая стадия использует только 1 ядро всё-равно и немного памяти). А начисляется за неё ~50000 очков, что явный перебор. Так что очки эти не показательны выходят. Обнаружил сначала сам, хотел сообщить, но потом увидел посты на форуме о том, что проблема известна.
Отправлено: 07.03.25 05:16. Заголовок: njrfn, писали, что е..
njrfn, писали, что если найдется более подходящая формула для вычисления очков по спорным моментам и её станут применять, то старые очки пересчитают по ней. Но это уже несколько лет на уровне "поговорили и хватит" висит. Никому особо нет дела до этого пока. Более актуальна сейчас активность в борьбе с троллями-читерами, которые отправляют фейковые результаты ради очков. Мешая при этом проекту, внося в базу некорректные записи. Их пока "рукаим ловят", но софт хотят доработать, чтобы добавить проверок на валидность результатов.
Отправлено: 07.03.25 10:26. Заголовок: фейковые результаты
Т.е. человек посылает результаты будто он, например, протестировал интервал от 70 бита до 71, а на самом деле ничего не проверял. Тем самым этот интервал не будет протестирован другими пользователями, а в нем мог оказаться делитель. Таким образом наносится ущерб проекту. Это единственное, что мне приходит в голову. Как с этим можно бороться? Безусловно это недопустимо.
Отправлено: 07.03.25 12:16. Заголовок: njrfn, да, именно об..
njrfn, да, именно об этом речь. Как решать - ну в идеале как с PRP тестами и proof'ами для них. Тут уже математика в деле - "функция" на выходе должна давать еще одно значение, которое а) можно получить только проделав основную работу (т.е. вычислить основной результат "функции" условно), б) для него существует некая "проверочная" функция, которая выполняется за время значительно меньшее, чем прямая функция. При этом позволяет подтвердить или опровергнуть то, что данное значение было получено в результате расчетов прямой функции с заданными параметрами (экспонента, биты, и т.д.). Как найти такую функцию - тут это глубины математики и анализ свойств основной функции. Мне это не под силу, но для PRP нашли вариант, и для TF было предложение давно еще, которое даже на 80% реализовали. Я могу свести до примитивов, исключительно в кач-ве примера - если при TF мы в итоге проверяем остаток от деления экспоненты на простые числа из битового диапазона, то теперь говорится, что помимо результата NF в случае ненахождения делителя, нужно приложить остатки от деления. Или какую-то часть, но заранее не сообщается какая именно. И далее мы проверяем выборочно их - нам достаточно проверить лишь небольшую часть. Если есть хоть одно несовпадаение - значит перед нами жулик. Так ес-но в силу многих причин не получится, это грубый условный пример.
В реальности используются свойства оригинальных операций или специальные алгоритмы из серии "proof of work", "Доказательство с нулевым разглашением" и т.д.
У меня 777 из 1000 диапазонов закрыты на данный момент. Остались почти только те, которые TFом уже нерезонно закрывать, дальше будет долго. Совсем недавно нашел довольно-таки большой делитель, рекордный для меня пока что: Factor: 397224541489857773535839822506398070553767 (42 digits / 138.189 bits) Found on 2025-03-31 19:26:23 with PM1.
[Worker #1] [Mar 31 22:26:21] P-1 found a factor in stage #2, B1=1500000, B2=10055987760. [Worker #1] [Mar 31 22:26:21] M12797639 has a factor: 397224541489857773535839822506398070553767 (P-1, B1=1500000, B2=10055987760) [Comm window] [Mar 31 22:26:21] Sending result to server: UID: nstorm/NStorm-NEW, M12797639 has a factor: 397224541489857773535839822506398070553767 (P-1, B1=1500000, B2=10055987760)
Возможно это самый большой делитель, найденный командой. Во всяком случае из того, что бегло нашел среди последних делителей за неименением фильтра по команде. Ближайший был 389514580666837390177419959938748510237569 у ZZ_Vitaly_Matin, найденный в 207967. Хотя в общем зачете даже на 1ую страницу самых больших делителей не попадает.
Отправлено: 16.05.25 21:53. Заголовок: njrfn пишет: для че..
njrfn пишет:
цитата:
для чего Вы повторяете уже найденные делители.
есть еще один умник который перепроверяет найденные делители и + еще 1 по удачливости. но чаще тотже делитель который были найдены еще год назад или даже 5 лет назад. столько работы видеокарты в пустую... мог бы и ненайденные перепроверять.
есть еще один умник который перепроверяет найденные делители и + еще 1 по удачливости. но чаще тотже делитель который были найдены еще год назад или даже 5 лет назад. столько работы видеокарты в пустую... мог бы и ненайденные перепроверять.
Тфу как грубо. Может для начала стоило бы узнать для чего это? Или тему хотя бы перечитать, возможно тогда стало бы понятно, что я знаю что и для чего я делаю. Ваш невежественный комментарий далек от реальности.
njrfn пишет:
цитата:
NStorm, для чего Вы повторяете уже найденные делители. Какой в этом смысл?
Проект Джеймса (его сайт - mersenne.ca и он активно помогает с развитием mersenne.org, админя его в т.ч.): https://www.mersenne.ca/tfri/ Его цель - перепроверка диапазонов TF, которые были проверены не до конца. Если в mfaktc стоял StopAfterFactor=2, он обраывает поиски сразу после нахождения делителя. Т.е. диапазон до конца остается непроверенным, такое в базе еще со сноской под * показывается. Ну и есно с некоторой вероятностью в диапазоне может быть больше 1го делителя. Поэтому Джеймс попросил помочь с добиваением незавершенных диапазонов до конца. А сделать это можно не имея checkpoint-файла оригинального поиска, только проверив диапазон полностью сначала. Что ес-но каждый раз будет приводить к обнаружению повторно тех делителей, на которых прошлый юзер соб-но остановился. Но также иногда открывались и дополнительные делители. Соб-но из таблички справа (по ссылке выше) видно, что я 142 новых нашел, а кто-то гораздо больше. В общем смысл был в том, чтобы откликнуться на просьбу Джеймса с закрытием этих диапазонов
цитата:
В 24-ой версии mfactc реализован контрольный "довесок" к просчитанному результату. Теперь не будут жульничать.
Не факт. Остановить это может только совсем не умееющих в программирование или ленивых. Детали не расскажу, но поверьте, как человеку активно участвовавшему в выпуске этой и последующих версий (на гитхабе проекта можно увидеть мои коммитты в проект). Хотя у меня давно вертится идея, как сделать хоть как-то проверяемые пруфы. Но до реализации мне пока не хватает времени. PS: Все новые версии собираются какое-то время автоматически на гитхабе, я как раз реализовал эту фичу: https://github.com/primesearch/mfaktc/releases В последней сборке 0.24.0-beta.5, кстати, включил больше оптимизаций компилятора. У меня с ними работает на 1-2% быстрее. Немного, с другой стороны чем бы не повод обновиться. 0.24.0-beta.4 по моему опыту вполне себе стабильна была для постоянного использования, beta.5 пока тоже не показывает проблем.
Отправлено: 23.06.25 03:38. Заголовок: Кстати, раз уж зашел..
Кстати, раз уж зашел сюда: 4 дня назад я закрыл все миллионные диапазоны, найдя в каждом из них хоть один новый делитель: https://nstorm.ru/1FM/ Часть последних диапазонов закрывал уже в т.ч. поисками среди чисел, ранее уже имевших найденные делители. Как и предполагал изначально, в пройденных волной первичных проверок (меньше тех чисел, среди который сейчас идет фронт поисков простых чисел Мерсенна) среди чисел без найденных делителей вовсе стало слишком долго (и, откровенно бессмысленно) искать нынче. Поэтому там поискал новые делители уже и среди числе, где 1 и более делителей уже были известны. Меньше чем пол года заняло, не помню точно, с какого момента именно этим "челленджем" решил заняться.
Отправлено: 23.06.25 03:54. Заголовок: PS: Ради исключитель..
PS: Ради исключительно развлечения и "разминки мозгов" я в первую очередь выбирал кандидатов с "красивыми номерами". Примерно как телефонные номера легкозапоминающиеся сейчас продают операторы, где много повторяющихся цифр или комбинаций цифр. Так примерно у меня отбирал скрипт, который я набросал. Какой-то конкретный алгоритм не выбирал, серьезно к этому делу не подходил, т.к. результат какой-то гарантированный на выходе не требовался. Поэтому просто интуитивно набросал скрипты - одни скачивали с разных ссылок mersenne.org и mersenne.ca подборки подходящих экспонент в нужных диапазонах, другие среди этих списков считали "вес красивости" каждого числа, который за идущие подряд цифры увеличивал вес экспоненциально, а за просто повторяющиеся (не подряд) емнип тоже, но с уменьшающим коэф. Ну и соотв. дальше просто закидывал задания начиная с тех, у которых этот "вес" больше всего получался. Еще были скрипты, которые при нахождения делителя в диапазоне, автоматически убирали все дальнейшие задания в этом диапазоне и вычеркивая весь диапазон из других кандидатов на еще не добавленные задания.
Все даты в формате GMT
3 час. Активность сегодня: 4
Права: смайлы да, картинки да, шрифты нет, голосования нет
аватары да, автозамена ссылок вкл, премодерация откл, правка нет