У вас "быстрота" за а счет двух простых оптимизаций:
1) Cокращать делители по мере их нахождения.
Идея хорошая, но очевидная и давно всем известная.
Вот, посмотрите например на код тут, в функцию findDivisors.
Это очень простая идея, она уже была изобретена тысячи раз и даже какого-то названия не имеет. Помнится, я ее применял еще лет 20 назад будучи школьником на какой-то олимпиаде.
2) Перебирать отдельно 2, 3 и потом все числа заведомо не делящиеся на 2 и 3, потому что только такие могут быть простыми. Это тоже очевидная и давно известная оптимизация, называющаяся "методом колеса" или "колесной оптимизацией". Можно взять любой набор простых чисел, перемножить их и потом надо рассматривать в качестве кандидатов на простые числа только те, которые заведомо взаимно просты с этим произведением.
Чаще всего эту идею применяют в решете эратосфена.
В наивном разложении на делители ее используют редко, потому что там алгоритм итак относительно быстрый в своей области применения - до корня. Несколько процентов вы этим колесом еще выдавите, но на маленьких числах (как у вас, влезающих в обычные типы) это смысла это несет мало, а код усложняет заметно. А если уж раскладывать длинные (десятки десятичных цифр) числа, то надо расчехлять тяжелую математику и применять что-то поумнее наивного перебора. Например, какие-нибудь эллиптические кривые.
В целом, алгоритм чуть-чуть быстрее стандартной реализации, но для "огромных" составных чисел не применим и ничего нового не привнес.
Edit: Более того, даже та статья на хабре на которую вы в конце ссылаетесь, сначала находит простые делители применяя первую оптимизацию, а потом строит все делители. Это функция prchoosediv там.
Какие проблемы? Когда ввели комплексные числа, уже получается sin(π/2+ln(67 + 8√70)i) = 67
Есть пара тривиальных вопросов в том, что возможных значений у arcsin много, ну так и на вещественных числах там такая же проблема. Только надо ввести дополнительные правила на комплексную часть ответа. Ну и область определения arcsin похоже будет не вся комплексная плоскость, но все вещественные положительные числа там точно есть.
Нет, не покупали. Линукс физически нельзя купить, там все открытое. Даже если МС скупит linux foundation, просто откоют новую организацию, форкнут код и пордолжат дальше работать. А МС останется с копией репозитория, который закрыть она по лицензии не сможет.
У меня есть резонное опасение, что постепенно такая же система будет и на компьютерах: только "сертификат микрософт" позволит запустить на компьютере программу.
Вот тогда вендекапец и настанет буквально в течении месяцев после анноса изменений (даже не их реализации).
Спасибо Габену, теперь и игры почти все на линуксе работают зашибись. Возможность устанавливать что угодно откуда угодно нужна даже обывателям.
Это тот случай, когда решая задачу вообще не правильным методом, вы случайно получили в целом правильный результат. Слава богу, ваше сравнение яблок с бананами хотя бы не поменяло местами питон с другими языками. Однако другие языки перетасовало весьма своевольно.
Люди тоже пишут говнокод. Их называют говнокодерами и гоняют их и насмехаются над ними.
не самый оптимальный метод реализации это не "полный шлак" 🤦♂️
Бенчмарк, который сравнивает разные методы в разных случаях - это полный шлак. Представьте вы тут сравниваете разные автомобили, один вы гоняете по гоночной трассе, а второй по пробке и на основе этого делаете вывод, какой из них и насколько быстрее. Хоть результат и "везде идентичный" и "без ошибок".
Проблема в том, что определить есть ли в статье смысл, или это галлюцинация нейросетки, чем-то слабже полноценного искуственного интеллекта, похоже, никак.
Тут проблема с тем, что пользователи калькуляторов не заваливают хабр мегабайтами мусора, а пользователи нейронок - заваливают. Иначе бы были и автоматические проверки на использование калькуляторов.
И это не для создателей нейронок делается, чтобы они не дай бог не испортили свое детище воровнным с хабра материалом, а для читателей хабра. Если 99.99% статей будет нейрослопом, то читатели все уйдут и хабр можно закрывать, а кто захочет почитать что-то нейронное, всегда сможет с тем же успехом открыть чат бот самостоятельно и попросить его написать статью.
Автоматически сгенерированные тексты можно проверять только автоматически, иначе генератор всегда завалит все ручные фильтры хрючевом.
По поводу описанного тут случая - автору просто не повезло: его уникальный стиль весьма похож на нейрослоп. Статью все-таки опубликовали, так что система работает. Лучше уж некоторый процент авторов будет вынужден писать аппеляции, чем хабр потонет под низкопробным слоем нейрослопа.
Хорошего решения у проблемы нет. Можно еще вводить фильтры по рейтингу, чтобы писать могли только проверенные пользователи с системой рекомендаций, но тогда количество контента сильно упадет. Можно вводить плату за регистрацию и жесткие баны при жалобах на нейрослоп. Но все решения будут по своему плохи.
Разумеется. Мне кажется хорошая аналгия тут - авто. Есть феррари и есть приус. Очевидно же, что феррари быстрее? Да, если вам надо только ездить по пробкам, то приус будет двигаться с той же скоростью, примерно с тем же комфортом, но будет гораздо дешевле.
Но это не отменяет того, что приус - медленный. В любой аналогичной ситуации он будет медленее. Иногда эта медленность не имеет значения, ибо без разницы, там 10мс или 1мс тратится на склейку библиотек. Я и не отрицал вообще право питона на существование, я лишь утверждал, что он медленнее.
Но программа целиком не становится автоматически в 30 раз медленнее: часто основное время уходит на сеть, диск, базу или библиотеки, которые сами написаны на C/C++.
Да, спят все языки одинаково быстро. Но если у вас программа сама что-то делает, то она медленнее, если собственно это действие и не вывести в нативный код.
Да, программу бывает можно писать и на питоне, но как уже писали выше - это лишь обвязка и склейка кусков, написанных на более быстрых языках.
Ну да, так и есть. На C++ там тривиальная ручная реализация BigInt без оптимизаций, которая очевидно уступает вылизанной реализации длинной арифметики в питоне (которая, кстати, написана на С). Так что там не сравнение питона с С++, а сравнение Сишной реализации длинной арифметики в библиотеке питона с кустарной ручной реализацией (ну с примесью самого языка для обвязки, но вообще непонятно, какая там пропорция).
Короче, бенчмарк очень спорный, и никаких выводов по нему делать нельзя.
Как-то странно. При расчете по формуле в 10М операций C++ в 177 раз быстрее CPython. А при подсчете до заданной точности - сравним. В чем дело? Ведь подсчет до заданной точности - это сколько-то заранее фиксированных итераций (хоть число и не записанных явно). Ведь формула одна и та же. Питон в обоих тестах работает примерно одинаковое время, а C++ в 170 раз медленнее. Почему?
Что там такое во втором тесте, чего нет в первом? Криво написанная длинная арифметика без стандартных оптимизаций, которые реализованы в движке длинной арифметики в питоне? Тогда сравнение некорректное. Надо в С++ использовать тоже стандартную вылизанную длинную арифметику вроде libgmp.
Ну вот он медленный там, где есть "тяжeлые части" (например циклы, for). Да, плохой архитектурой и алгоритмами вы замедлите работу в сотни раз, а не в 30, как при использовании питона вместо C++. Но 30 питоновских раз никуда не пропадают даже при выборе правильной архитектуры.
Вынос частей в С++ - это костыль, как раз вызванный абстрактным "Питон медленный". Если бы он не был абстрактно медленным, не нужно было бы ничего никуда выносить.
Ну нет, тут секретные данные спрятаны. Если не разбирать "флешку", то и не узнать, что там на самом деле еще скрытый раздел есть. А запароленый архив видно и он подозрительно большой, а при его запуске какой-то пароль просит. А если его переименовать во что-то еще, то видно будет битый файл.
Хороший термин.
У вас "быстрота" за а счет двух простых оптимизаций:
1) Cокращать делители по мере их нахождения.
Идея хорошая, но очевидная и давно всем известная.
Вот, посмотрите например на код тут, в функцию findDivisors.
Это очень простая идея, она уже была изобретена тысячи раз и даже какого-то названия не имеет. Помнится, я ее применял еще лет 20 назад будучи школьником на какой-то олимпиаде.
2) Перебирать отдельно 2, 3 и потом все числа заведомо не делящиеся на 2 и 3, потому что только такие могут быть простыми. Это тоже очевидная и давно известная оптимизация, называющаяся "методом колеса" или "колесной оптимизацией". Можно взять любой набор простых чисел, перемножить их и потом надо рассматривать в качестве кандидатов на простые числа только те, которые заведомо взаимно просты с этим произведением.
Чаще всего эту идею применяют в решете эратосфена.
В наивном разложении на делители ее используют редко, потому что там алгоритм итак относительно быстрый в своей области применения - до корня. Несколько процентов вы этим колесом еще выдавите, но на маленьких числах (как у вас, влезающих в обычные типы) это смысла это несет мало, а код усложняет заметно. А если уж раскладывать длинные (десятки десятичных цифр) числа, то надо расчехлять тяжелую математику и применять что-то поумнее наивного перебора. Например, какие-нибудь эллиптические кривые.
В целом, алгоритм чуть-чуть быстрее стандартной реализации, но для "огромных" составных чисел не применим и ничего нового не привнес.
Edit: Более того, даже та статья на хабре на которую вы в конце ссылаетесь, сначала находит простые делители применяя первую оптимизацию, а потом строит все делители. Это функция
prchoosedivтам.Это вы про тот текст от DeepSeak выложенный юзером x2v0? Перелогиниться забыли?
Какие проблемы? Когда ввели комплексные числа, уже получается sin(π/2+ln(67 + 8√70)i) = 67
Есть пара тривиальных вопросов в том, что возможных значений у arcsin много, ну так и на вещественных числах там такая же проблема. Только надо ввести дополнительные правила на комплексную часть ответа. Ну и область определения arcsin похоже будет не вся комплексная плоскость, но все вещественные положительные числа там точно есть.
Нет, не покупали. Линукс физически нельзя купить, там все открытое. Даже если МС скупит linux foundation, просто откоют новую организацию, форкнут код и пордолжат дальше работать. А МС останется с копией репозитория, который закрыть она по лицензии не сможет.
Вот тогда вендекапец и настанет буквально в течении месяцев после анноса изменений (даже не их реализации).
Спасибо Габену, теперь и игры почти все на линуксе работают зашибись. Возможность устанавливать что угодно откуда угодно нужна даже обывателям.
Ага. Если бы вам нейронка предложила не число пи считать, а длинные числа перемножать, вы бы вообще могли получить, что питон быстрее си.
Это тот случай, когда решая задачу вообще не правильным методом, вы случайно получили в целом правильный результат. Слава богу, ваше сравнение яблок с бананами хотя бы не поменяло местами питон с другими языками. Однако другие языки перетасовало весьма своевольно.
Люди тоже пишут говнокод. Их называют говнокодерами и гоняют их и насмехаются над ними.
Бенчмарк, который сравнивает разные методы в разных случаях - это полный шлак. Представьте вы тут сравниваете разные автомобили, один вы гоняете по гоночной трассе, а второй по пробке и на основе этого делаете вывод, какой из них и насколько быстрее. Хоть результат и "везде идентичный" и "без ошибок".
Проблема в том, что определить есть ли в статье смысл, или это галлюцинация нейросетки, чем-то слабже полноценного искуственного интеллекта, похоже, никак.
Тут проблема с тем, что пользователи калькуляторов не заваливают хабр мегабайтами мусора, а пользователи нейронок - заваливают. Иначе бы были и автоматические проверки на использование калькуляторов.
И это не для создателей нейронок делается, чтобы они не дай бог не испортили свое детище воровнным с хабра материалом, а для читателей хабра. Если 99.99% статей будет нейрослопом, то читатели все уйдут и хабр можно закрывать, а кто захочет почитать что-то нейронное, всегда сможет с тем же успехом открыть чат бот самостоятельно и попросить его написать статью.
Автоматически сгенерированные тексты можно проверять только автоматически, иначе генератор всегда завалит все ручные фильтры хрючевом.
По поводу описанного тут случая - автору просто не повезло: его уникальный стиль весьма похож на нейрослоп. Статью все-таки опубликовали, так что система работает. Лучше уж некоторый процент авторов будет вынужден писать аппеляции, чем хабр потонет под низкопробным слоем нейрослопа.
Хорошего решения у проблемы нет. Можно еще вводить фильтры по рейтингу, чтобы писать могли только проверенные пользователи с системой рекомендаций, но тогда количество контента сильно упадет. Можно вводить плату за регистрацию и жесткие баны при жалобах на нейрослоп. Но все решения будут по своему плохи.
Извиняюсь. Можно сделать единственный вывод: нейросети могут нагенерить полный шлак, поэтому пользоваться ими в области, где вы не эксперт - нельзя.
Разумеется. Мне кажется хорошая аналгия тут - авто. Есть феррари и есть приус. Очевидно же, что феррари быстрее? Да, если вам надо только ездить по пробкам, то приус будет двигаться с той же скоростью, примерно с тем же комфортом, но будет гораздо дешевле.
Но это не отменяет того, что приус - медленный. В любой аналогичной ситуации он будет медленее. Иногда эта медленность не имеет значения, ибо без разницы, там 10мс или 1мс тратится на склейку библиотек. Я и не отрицал вообще право питона на существование, я лишь утверждал, что он медленнее.
Если питон такой быстрый, то зачем вообще что-то выносить в нативный код?
Да, спят все языки одинаково быстро. Но если у вас программа сама что-то делает, то она медленнее, если собственно это действие и не вывести в нативный код.
Да, программу бывает можно писать и на питоне, но как уже писали выше - это лишь обвязка и склейка кусков, написанных на более быстрых языках.
Ну да, так и есть. На C++ там тривиальная ручная реализация BigInt без оптимизаций, которая очевидно уступает вылизанной реализации длинной арифметики в питоне (которая, кстати, написана на С). Так что там не сравнение питона с С++, а сравнение Сишной реализации длинной арифметики в библиотеке питона с кустарной ручной реализацией (ну с примесью самого языка для обвязки, но вообще непонятно, какая там пропорция).
Короче, бенчмарк очень спорный, и никаких выводов по нему делать нельзя.
В тех сорсах только сортировка, числа по ней вопросов не вызывают. Вычисления Пи там нигде нет.
Как-то странно. При расчете по формуле в 10М операций C++ в 177 раз быстрее CPython. А при подсчете до заданной точности - сравним. В чем дело? Ведь подсчет до заданной точности - это сколько-то заранее фиксированных итераций (хоть число и не записанных явно). Ведь формула одна и та же. Питон в обоих тестах работает примерно одинаковое время, а C++ в 170 раз медленнее. Почему?
Что там такое во втором тесте, чего нет в первом? Криво написанная длинная арифметика без стандартных оптимизаций, которые реализованы в движке длинной арифметики в питоне? Тогда сравнение некорректное. Надо в С++ использовать тоже стандартную вылизанную длинную арифметику вроде libgmp.
Ну вот он медленный там, где есть "тяжeлые части" (например циклы, for). Да, плохой архитектурой и алгоритмами вы замедлите работу в сотни раз, а не в 30, как при использовании питона вместо C++. Но 30 питоновских раз никуда не пропадают даже при выборе правильной архитектуры.
Вынос частей в С++ - это костыль, как раз вызванный абстрактным "Питон медленный". Если бы он не был абстрактно медленным, не нужно было бы ничего никуда выносить.
Ну нет, тут секретные данные спрятаны. Если не разбирать "флешку", то и не узнать, что там на самом деле еще скрытый раздел есть. А запароленый архив видно и он подозрительно большой, а при его запуске какой-то пароль просит. А если его переименовать во что-то еще, то видно будет битый файл.