То, что по идее ваше, накопленное, должно лежать на счету и работать в фондах, расти потихоньку - тупо выплачено другим пенсионерам. Этих денег больше нет.
Да, это предыдущие настройки, но они отвратительные, как раз потому, что без постоянного роста населения это не работает.
Вспоминается история с чумой в европе. Тогда выкосило двузначное число в процентах от населения. Случилась ужасная трагедия: работников стало не хватать, и им пришлось платить больше, появился средний класс.
Проблема есть только в пенсионных системах, где текущие работники платят пенисию. Кстати, такие системы не везде. Даже в России вводили накопительную часть, пока не прихватизировали ее всю на нужды государства. Во многих государствах пенсионные накопления индивидуальны в основном.
Если популисты геронтофилы все не испортят, эта проблема тоже не велика. В россии пенсии сейчас уже нищенские, ну будут еще меньше, разницы принципиальной нет. Западные пенсионеры не смогут путешествовать, будут вынуждены продать свое жилье в центре города и переехать на окраину в дешевое, но с голоду не умрут.
Вымрут целые отрасли бессмысленной работы (те самые bullshit jobs).
Жилье станет снова доступным, зарплаты вырастут, места в детских садиках перестанут быть адским дефицитом. И люди станут охотнее заводить семьи и детей. Проблема рассосется сама через поколение, если ей не мешать.
Но ей мешают. Пока завозят мигрантов, например, что наоборот только снижает зарплаты и удорожает жилье. Всеми силами сохранят статус кво, который должен поменятся, но от этого будет только режче и больнее переход.
У вас "быстрота" за а счет двух простых оптимизаций:
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.
https://www.kommersant.ru/doc/5706513
То, что по идее ваше, накопленное, должно лежать на счету и работать в фондах, расти потихоньку - тупо выплачено другим пенсионерам. Этих денег больше нет.
Да, это предыдущие настройки, но они отвратительные, как раз потому, что без постоянного роста населения это не работает.
Вспоминается история с чумой в европе. Тогда выкосило двузначное число в процентах от населения. Случилась ужасная трагедия: работников стало не хватать, и им пришлось платить больше, появился средний класс.
Проблема есть только в пенсионных системах, где текущие работники платят пенисию. Кстати, такие системы не везде. Даже в России вводили накопительную часть, пока не прихватизировали ее всю на нужды государства. Во многих государствах пенсионные накопления индивидуальны в основном.
Если популисты геронтофилы все не испортят, эта проблема тоже не велика. В россии пенсии сейчас уже нищенские, ну будут еще меньше, разницы принципиальной нет. Западные пенсионеры не смогут путешествовать, будут вынуждены продать свое жилье в центре города и переехать на окраину в дешевое, но с голоду не умрут.
Вымрут целые отрасли бессмысленной работы (те самые bullshit jobs).
Жилье станет снова доступным, зарплаты вырастут, места в детских садиках перестанут быть адским дефицитом. И люди станут охотнее заводить семьи и детей. Проблема рассосется сама через поколение, если ей не мешать.
Но ей мешают. Пока завозят мигрантов, например, что наоборот только снижает зарплаты и удорожает жилье. Всеми силами сохранят статус кво, который должен поменятся, но от этого будет только режче и больнее переход.
Хороший термин.
У вас "быстрота" за а счет двух простых оптимизаций:
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.