Нет, это вам осталось осознать, что алгоритм работает всегда. А вы ввели меня в заблуждение, говоря, что для RSA требуется простое число. Насколько я понял, это ослабление сформулировано именно по алгоритму Миллера-Рабина. То есть не алгоритм подогнан под требования, а требования под то, что может выдать алгоритм.
Ввиду того, что тестирование простоты больших чисел требует существенных временных затрат, требование простоты получаемого числа часто ослабляют до сильной псевдопростоты по нескольким различным случайным основаниям.
А чего это вдруг я? Ваша тема с RSA, вот и начинайте. У меня есть слово "Если" в начале предложения. Вот если вам так интересно далее продолжать этот бессмысленный спор, ушедший от темы статьи, то начните, найдите алгоритм, где требуется гарантия простоты числа. А потом уже будет моя очередь доказывать свою часть аргументации.
Но простоту числа, необходимую для работы RSA, он всё ещё гарантировать не может
И не должен. Это не его работа. Если алгоритм шифрования требует гарантию простоты числа, то очевидно, там есть алгоритм, который гарантирует простоту числа. А этот алгоритм нужен, чтобы быстро отбрасывать заранее составные числа и не запускать основной в цикле перебора.
Вы не пониаете, о чём я говорю. Я говорю о том, что наша отрасль работает на гарантиях. Код работает на гарантиях. Алгоритмы работают на гарантиях. Вы приводите тест Миллера-Рабина, как алгоритм, не дающего гарантии, а я говорю, что он гарантию даёт. Поэтому он полезен, как классический алгоритм с false positive. Алгоритм, дающий гарантию простоты числа может написать любой школьник (ну может утрирую). Алгоритм ДЁШЕВО отбрасывающий заранее некорректные результаты намного сложней.
Об этом речь. Алгоритм Миллера-Рабина работает не "практически всегда". Он всегда работает.
Вроде умные мысли говорит, но при этом пытается сделать из промпта полноценную замену. Я говорю "промпт", потому что вижу, что этот язык не является полной и исчерпывающей спецификацией, то есть позволяет множественную трактовку, равно как естественный язык. А если является, то как его синтаксис может быть в 5-10 раз короче?
Я не понимаю, как он собирается решать две основные проблемы.
Первая и самая главная: недетерменированость. Из одного и того же "исходника" получаются разные кодовые базы классического языка. Это делает невозможным итеративные улучшения, это делает невозможным багфикс (ну просто потому что сегодня баг есть, завтра нет и наоборот, и всё это с одним и тем же "исходником").
Вторая проблема: контекстное окно. Если раньше, когда вдруг оказывалось, что 640кб не хватает всем для компиляции, то покупалась плашка памяти за $100 и приводились исходники в порядок. Бедные страдали со свопом, но компилировали. А для увеличения контекстного окна вдвое надо построить новый дата-центр, потому что зависимость ну ни разу не линейная. А контекстное окно нужно обязательно, потому что проект планируется перегенерировать полностью и если ваш исправленный промпт не лезет в окно, то в окно пойдёте вы.
Тест Миллера-Рабина гарантирует, что число составное. У него два ответа: "составное" и "не знаю". Давайте заканчивать с софистикой.
Детерминированный алгоритм вполне может выдать число, которое мы посчитаем случайным. Остаток от деления атомов на 10 в песчинке плюс сколько наносекунд кричала чаечка.
Это всё лирика. В один момент детерминизм алгоритмов остаётся технически детерминизмом, но на практике становится случайным. Где-то специально случайность добавляют, усиливают и используют далее в разветвлении алгоритма. Например в ЛЛМ. Которая детерминированная.
Вы же не будете мои слова выдирать из контекста? Мы говорили про разницу в промпте и коде. Выполнение кода детерминировано, промпта - нет.
Там ещё было про гарантии и это была ключевая фраза. "Почти всегда" - это отсутствие гарантии.
Собственно, вам ответили, что вероятностный алгоритм - всё ещё алгоритм. Он делает вывод случайным (в идеале), но сама выдача является детерминированной, потому что является целью алгоритма. Как-то так.
То есть алгоритм шифрования совершенно детерминировано выдаёт случайное число. По хорошему, должна быть какая-то гарантия случайности. Ну там, дисперсии всякие, отклонения и всё такое.
В разработке мы используем одни гарантии, чтобы предоставить другие. Построить сложную систему, которая будет гарантировать конечному пользователю свою работу.
Если хоть одна часть в нижележащих слоях не может гарантировать свою работу, то вся система рушится, как карточный домик.
Гарантия - это всё. Нет гарантии - нет алгоритмов. Нет кода. Нет ПО как класса.
Ну хотите - посмотрите мои комменты 16-17 года. Там этого эм-даш - навалом. Ну пишу я так. Поменял привычку с приходом ЛЛМ, теперь ставлю короткие тире.
В производстве ПО должно быть по другому, потому что код и есть штучный товар. Если проводить аналогию, то код - чертёж, ПО - результат построения по чертежу. Само ПО ничего не стоит, потому что компилятор наштампует его в любом количестве, а вот код - это дорого, очень дорого. Потому что R&D, вот почему.
А ещё потому что код долгоживущий. И чем дольше код живёт, тем больше с него прибыль. И тем сложнее его дорабатывать. А дорабатывать надо, потому что "нужно очень быстро идти, чтобы оставаться на месте". Качество кода - это не прихоть, это суровая необходимость рыночных реалий. Бездумный код может обрушить весь бизнес под тяжестью техдолга. Это не какие-то страшилки, это случается регулярно.
Соглашусь полностью. И добавлю, что декларативные языки, хоть и дают детерминированный результат, но страдают от недетерминированности времени выполнения. Вот это самое "О большое". Именно поэтому существует EXPLAIN, который показывает, что и в каком порядке будет выполняться в конкретно этом случае.
А я соглашусь с тем, что компиляторы C++ пишут бредовый и неоптимальный машинный код, который невозможно поддерживать. Правда тут аж два нюанса. На плюсах разработка сильно проще и быстрее, чем на асме. Процессоры становились сложнее, команд больше а тонкости применения прямо лавиной хлынули, смывая призрачную надежду справиться с этим своей головой. Ассемблер Z80 это вообще не то же самое, что ассемблер x86-64 со всеми avx512 и уровнями кэша.
Второй нюанс в том, что C++ остался детерминированный. Он из одного и того же кода делает один и тот же машинный код. Его поведение полностью предсказуемо. Это снимает необходимость дорабатывать машкод руками.
Ну и статья как раз о том, что на самом деле наша индустрия никогда такого не переживала.
Давайте так. Чтоб уж справедливо было, сначала упомянем, что это разные места. "Don’t expect AGI within the next year" в оригинале это "Не ждите AGI в ближайший год". Без истерик. И да, изначально я писал на русском.
В том месте, где "И не говорите мне, что..." в английской версии выглядит как "But don't tell me...". Истерика на месте, всё в порядке.
А может и не надо так часто? Может лучше качественней?
Наплыв игр на рынке - это тоже не очень хорошо. Игры дешевеют, разрабы демпингуют, борясь за внимание аудитории, студии разоряются. Разве хорошо?
Это ужасно. Меня аж передёрнуло, когда нейросетка поменяла лицо Кеннеди на незнакомое. Нафиг такой "прогресс".
В мою статью подкинули, мопед не мой, передаю эстафету
Нет, это вам осталось осознать, что алгоритм работает всегда. А вы ввели меня в заблуждение, говоря, что для RSA требуется простое число. Насколько я понял, это ослабление сформулировано именно по алгоритму Миллера-Рабина. То есть не алгоритм подогнан под требования, а требования под то, что может выдать алгоритм.
Повторю ещё раз: этот алгоритм работает всегда.
Открыл википедию. Прочитал.
Закрыл.
А чего это вдруг я? Ваша тема с RSA, вот и начинайте. У меня есть слово "Если" в начале предложения. Вот если вам так интересно далее продолжать этот бессмысленный спор, ушедший от темы статьи, то начните, найдите алгоритм, где требуется гарантия простоты числа. А потом уже будет моя очередь доказывать свою часть аргументации.
И не должен. Это не его работа. Если алгоритм шифрования требует гарантию простоты числа, то очевидно, там есть алгоритм, который гарантирует простоту числа. А этот алгоритм нужен, чтобы быстро отбрасывать заранее составные числа и не запускать основной в цикле перебора.
Вы не пониаете, о чём я говорю. Я говорю о том, что наша отрасль работает на гарантиях. Код работает на гарантиях. Алгоритмы работают на гарантиях. Вы приводите тест Миллера-Рабина, как алгоритм, не дающего гарантии, а я говорю, что он гарантию даёт. Поэтому он полезен, как классический алгоритм с false positive. Алгоритм, дающий гарантию простоты числа может написать любой школьник (ну может утрирую). Алгоритм ДЁШЕВО отбрасывающий заранее некорректные результаты намного сложней.
Об этом речь. Алгоритм Миллера-Рабина работает не "практически всегда". Он всегда работает.
Вроде умные мысли говорит, но при этом пытается сделать из промпта полноценную замену. Я говорю "промпт", потому что вижу, что этот язык не является полной и исчерпывающей спецификацией, то есть позволяет множественную трактовку, равно как естественный язык. А если является, то как его синтаксис может быть в 5-10 раз короче?
Я не понимаю, как он собирается решать две основные проблемы.
Первая и самая главная: недетерменированость. Из одного и того же "исходника" получаются разные кодовые базы классического языка. Это делает невозможным итеративные улучшения, это делает невозможным багфикс (ну просто потому что сегодня баг есть, завтра нет и наоборот, и всё это с одним и тем же "исходником").
Вторая проблема: контекстное окно. Если раньше, когда вдруг оказывалось, что 640кб не хватает
всемдля компиляции, то покупалась плашка памяти за $100 и приводились исходники в порядок. Бедные страдали со свопом, но компилировали. А для увеличения контекстного окна вдвое надо построить новый дата-центр, потому что зависимость ну ни разу не линейная. А контекстное окно нужно обязательно, потому что проект планируется перегенерировать полностью и если ваш исправленный промпт не лезет в окно, то в окно пойдёте вы.Тест Миллера-Рабина гарантирует, что число составное. У него два ответа: "составное" и "не знаю". Давайте заканчивать с софистикой.
Детерминированный алгоритм вполне может выдать число, которое мы посчитаем случайным. Остаток от деления атомов на 10 в песчинке плюс сколько наносекунд кричала чаечка.
Это всё лирика. В один момент детерминизм алгоритмов остаётся технически детерминизмом, но на практике становится случайным. Где-то специально случайность добавляют, усиливают и используют далее в разветвлении алгоритма. Например в ЛЛМ. Которая детерминированная.
Вы же не будете мои слова выдирать из контекста? Мы говорили про разницу в промпте и коде. Выполнение кода детерминировано, промпта - нет.
Там ещё было про гарантии и это была ключевая фраза. "Почти всегда" - это отсутствие гарантии.
Собственно, вам ответили, что вероятностный алгоритм - всё ещё алгоритм. Он делает вывод случайным (в идеале), но сама выдача является детерминированной, потому что является целью алгоритма. Как-то так.
То есть алгоритм шифрования совершенно детерминировано выдаёт случайное число. По хорошему, должна быть какая-то гарантия случайности. Ну там, дисперсии всякие, отклонения и всё такое.
А то знаете, бывает всякое
В разработке мы используем одни гарантии, чтобы предоставить другие. Построить сложную систему, которая будет гарантировать конечному пользователю свою работу.
Если хоть одна часть в нижележащих слоях не может гарантировать свою работу, то вся система рушится, как карточный домик.
Гарантия - это всё. Нет гарантии - нет алгоритмов. Нет кода. Нет ПО как класса.
Ну хотите - посмотрите мои комменты 16-17 года. Там этого эм-даш - навалом. Ну пишу я так. Поменял привычку с приходом ЛЛМ, теперь ставлю короткие тире.
Ну может вы видели "Трассу 60"? Там есть музей поддельного искусства... )
Спасибо, исправил. Но рекомендую по ошибкам в следующий раз писать в личку, чтобы не перегружать комментарии.
У меня 30+ лет опыта разработки. И я считаю некорректным использовать как аргумент в свою пользу.
В производстве ПО должно быть по другому, потому что код и есть штучный товар. Если проводить аналогию, то код - чертёж, ПО - результат построения по чертежу. Само ПО ничего не стоит, потому что компилятор наштампует его в любом количестве, а вот код - это дорого, очень дорого. Потому что R&D, вот почему.
А ещё потому что код долгоживущий. И чем дольше код живёт, тем больше с него прибыль. И тем сложнее его дорабатывать. А дорабатывать надо, потому что "нужно очень быстро идти, чтобы оставаться на месте". Качество кода - это не прихоть, это суровая необходимость рыночных реалий. Бездумный код может обрушить весь бизнес под тяжестью техдолга. Это не какие-то страшилки, это случается регулярно.
Соглашусь полностью. И добавлю, что декларативные языки, хоть и дают детерминированный результат, но страдают от недетерминированности времени выполнения. Вот это самое "О большое". Именно поэтому существует EXPLAIN, который показывает, что и в каком порядке будет выполняться в конкретно этом случае.
А я соглашусь с тем, что компиляторы C++ пишут бредовый и неоптимальный машинный код, который невозможно поддерживать. Правда тут аж два нюанса. На плюсах разработка сильно проще и быстрее, чем на асме. Процессоры становились сложнее, команд больше а тонкости применения прямо лавиной хлынули, смывая призрачную надежду справиться с этим своей головой. Ассемблер Z80 это вообще не то же самое, что ассемблер x86-64 со всеми avx512 и уровнями кэша.
Второй нюанс в том, что C++ остался детерминированный. Он из одного и того же кода делает один и тот же машинный код. Его поведение полностью предсказуемо. Это снимает необходимость дорабатывать машкод руками.
Ну и статья как раз о том, что на самом деле наша индустрия никогда такого не переживала.
Давайте так. Чтоб уж справедливо было, сначала упомянем, что это разные места. "Don’t expect AGI within the next year" в оригинале это "Не ждите AGI в ближайший год". Без истерик. И да, изначально я писал на русском.
В том месте, где "И не говорите мне, что..." в английской версии выглядит как "But don't tell me...". Истерика на месте, всё в порядке.