Так в том-то и дело, что приведённые задачи требуют определённый математический багаж знаний, без которого умение думать не поможет. И у меня именно от этого небольшой диссонанс. Формула Герона проскакивает в нескольких предметах типичного математического/программистского бакалавриата - а это плюс-минус и есть ЦА экзаменов ШАД.
А вообще статья хорошая. Даже по пределам можно рассматривать такую задачу как самую простую "утешительную".
Если с первого взгляда математик (старшекурсник!) тут не увидит формулу Герона, то нафига он такой нужен? Ну а доказательство можно как по т. Вейерштрасса, так и тупо по определению предела вывести. В допзадачах предел тоже с какой-то паралимпиады, если учесть ЦА.
Не понимаю я зачем Scratch. Мне сыну даже в 7 лет проще было объяснить Python, чем всю вот эту свистопляску с кубиками. Когда он потом столкнулся со scratch, то освоил его мгновенно, но жаловался, что делать в нём что-либо очень неудобно.
А еще у них там только в тюрячке особого режима Азкабан десятки (если не сотни) магов сидят - это для оценок в 5-10 тыс населения чертовски много. А еще достаточно много гоблинов (музыкантов и банкиров) - возможно именно они рулят ДКП. А еще нет регулярной армии.
В подавляющем большинстве ОС именно такая модель безопасности: настройки программ - это данные пользователя, программы запускаемые пользователем могут беспрепятственно работать с файлами (данными) этого пользователя. Исторически именно браузерам первым, правда, пришлось изолировать код, получаемый из интернета (потому что запуск такого кода фактически их главная задача), но сам браузер вполне себе имеет доступ по умолчанию к всем данным пользователя. Если от такой модели припекает, то можно посмотреть следующие альтернативы:
Запускать ПО (браузер, например) в ВМ или в контейнере. Так и ПО не будет видеть окружение и большинство программ не получает простого доступа к данным этого ПО
Смотреть в сторону экзотических ОС (типа Qubes OS), в которых этот принцип внедрен в архитектуру системы.
Мне больше резануло "вызывает функцию инверсного синуса". Не то чтобы это неправильно, но привычнее называть эту функцию арксинусом. Инверсными обычно называют функции обратные к гиперболическим, потому что приставка "арк" (угол, дуга) становится некорректной.
И удивило, что в статье не упомянуты Б3-34, МК-61, МК-52 - это же классика позднесоветского троллинга одноклассников и однокурсников:
Ну про 12 и 16 мегабайт это больше маркетинг - реально работать было очень больно. На 32 - я еще поверю, что можно было что-то делать. Например, запустить блокнот и диспетчер задач (хаха). На 64 МБ можно было запустить Access 97, SQL Server Enterprise manager (божечки, модальные окна редактирования хранимок с пропорциональным шрифтом - это не забыть) и Query Analyzer. В принципе, можно даже BOL было открыть одновременно. Не скажу, что комфортно, но возможно. На тех же 64 МБ можно было запустить мааааленький контроллер домена - пользователей на 20. Но только больше ничего нельзя было в этом случае туда больше ставить (дисковые чтения становились некешируемыми). На 128-256 можно было поднять SQL Server 6.5, 7.0 или 2000.
Но вашего вопроса "почему то, что шустро работало 28 лет назад на 16 мегабайтах сегодня требует на два-три порядка больше памяти" это не отменяет. И даже ответ понятен. Во-первых, шустро оно не работало. Диски были медленными. Память была медленной (SIMM еще). Процессоры были медленными и 32-битными. Интернет был только в сказках. Во-вторых, было меньше "прослоек", "фреймворков" и "уровней виртуализации". Это честный обмен - эти штуки сильно облегчают разработку ПО, но съедают много памяти и сколько-то производительности. В-третьих, программы стали больше. Несоизмеримо больше. В воспоминаниях может и притупилось, но если вы возьмете СУБД 1997 года (ну тот же SQL Server 7.0, про 6.5 без слёз вообще сложно вспоминать), и попробуете его поднять в виртуалке (есть сложности, но вполне возможно), то удивитесь тому, насколько много относительно небольших неудобств, которые как раз и побеждались усложнением ПО. Ну а в большом объёме, к сожалению, больше мусора. Обычно этот мусор остаётся именно потому что с ним бороться дороже, чем оставить. Память-то подешевела.
В "плоском" варианте, когда просто вкладки сверху, это, действительно, сомнительная практика. Но какой-нибудь Sideberry с древовидным отображением вкладок слева и регулярным бэкапом сессии - что же плохого? У меня прямо сейчас 2070 вкладок, раскиданы примерно по 20 древовидным панелям. В двух самых больших панелях 676 и 581 вкладка. Это больше среднего (есть временная причина), пора прибрать немного - я стараюсь держаться в 1000 вкладок, чтобы tab counter правильно работал. Естественно, переоткрытие сессии и бэкапы сессий настроены и работают. В среднем раз в год примерно что-то корявое происходит из-за чего бэкап пригождается.
Если нужно именно десятичную запись, то лучше (проще) реализовать длинную арифметику самому. Потому что в Python (как и в Java/C#/JS и других популярных решениях) длинные числа хранятся по основанию 2 (технически - по основанию 2**32, но это неважно). И число 5 ** 9500000000 в таком виде займёт порядка 2,6 ГБ - что, кстати, само по себе может стать проблемой (Java и C# откажутся работать с такими в принципе, Python, насколько я знаю - сможет). Но после вычисления его еще надо вывести, а вот тут надо будет делить много раз на 10**n. В нынешнем Python по умолчанию ограничение 4300 цифр на такое преобразование. Но я бы и не пытался - деление в таких числах противная операция. Если так припекло посчитать такую необычную операцию, то проще самому реализовать арифметику с основанием степени 10 (10**9, например - отличный выбор). Сложение "столбиком", умножение "столбиком" (для небольших чисел) и умножение Карацубы (для чисел больше 10**100) - задача на пару вечеров. Зато преобразование в десятичную запись линейное по времени и константа по дополнительной памяти.
PS: но я таки, как и предыдущие комментаторы замечу, что мне сложно представить задачу в которой это понадобилось бы.
С одной стороны - да, по умолчанию и почти всегда лучше скучный и понятный код с минимумом WTF/KLOC. С другой стороны - наши процессоры уже лет 10 не растут в скорости однопотока, GPU и SIMD проковыривают путь крайне медленно (SIMD на x86 - 30 лет, GPGPU - 20), с многопоточным масштабированием тоже всё не просто, скорость памяти типа "растёт", но с огромным количеством оговорок (растёт максимальная пропускная способность, но не задержка, а пропускная способность растёт только для длинной последовательной серии операций или для нескольких каналов) .
Хотя о чём это я? В статье разбирается конкретно DBeaver - это пользовательское приложение на Java, если в нём и важны такие оптимизации, то явно не там, где они есть на самом деле. Несмотря на моё искреннее уважение к этому инструменту, большие объёмы данных его заставляют задуматься (в его оправдание - DataGrip тупит еще больше на той же Java). Приведённые в статье примеры явно не из построчной логики обработки. И ладно бы он был не быстрый, но стабильный, так ведь нет - есть куча мелких странных раздражающих багов. Получается, что тот, кто выбирает скорость в ущерб качеству, не получит ни качества ни скорости.
Без чёткого определения, что такое "дефицит кадров", и без методики того, как его измеряли или планируют измерять, все подобные статьи имеют нулевую или отрицательную ценность.
Конкретно в этом офисе был свитч. Точнее там из-за неразберихи купили и свитч и хаб, но поставили, конечно, свитч, а хаб договорились вернуть (почему помню - там пришлось менять счета, СФ, перекидывать часть железа из следующего счета и т.д.)
Так в том-то и дело, что приведённые задачи требуют определённый математический багаж знаний, без которого умение думать не поможет. И у меня именно от этого небольшой диссонанс. Формула Герона проскакивает в нескольких предметах типичного математического/программистского бакалавриата - а это плюс-минус и есть ЦА экзаменов ШАД.
А вообще статья хорошая. Даже по пределам можно рассматривать такую задачу как самую простую "утешительную".
Если с первого взгляда математик (старшекурсник!) тут не увидит формулу Герона, то нафига он такой нужен? Ну а доказательство можно как по т. Вейерштрасса, так и тупо по определению предела вывести.
В допзадачах предел тоже с какой-то паралимпиады, если учесть ЦА.
Не понимаю я зачем Scratch. Мне сыну даже в 7 лет проще было объяснить Python, чем всю вот эту свистопляску с кубиками. Когда он потом столкнулся со scratch, то освоил его мгновенно, но жаловался, что делать в нём что-либо очень неудобно.
А еще у них там только в тюрячке особого режима Азкабан десятки (если не сотни) магов сидят - это для оценок в 5-10 тыс населения чертовски много. А еще достаточно много гоблинов (музыкантов и банкиров) - возможно именно они рулят ДКП. А еще нет регулярной армии.
В подавляющем большинстве ОС именно такая модель безопасности: настройки программ - это данные пользователя, программы запускаемые пользователем могут беспрепятственно работать с файлами (данными) этого пользователя.
Исторически именно браузерам первым, правда, пришлось изолировать код, получаемый из интернета (потому что запуск такого кода фактически их главная задача), но сам браузер вполне себе имеет доступ по умолчанию к всем данным пользователя.
Если от такой модели припекает, то можно посмотреть следующие альтернативы:
Запускать ПО (браузер, например) в ВМ или в контейнере. Так и ПО не будет видеть окружение и большинство программ не получает простого доступа к данным этого ПО
Смотреть в сторону экзотических ОС (типа Qubes OS), в которых этот принцип внедрен в архитектуру системы.
Мне больше резануло "вызывает функцию инверсного синуса". Не то чтобы это неправильно, но привычнее называть эту функцию арксинусом. Инверсными обычно называют функции обратные к гиперболическим, потому что приставка "арк" (угол, дуга) становится некорректной.
И удивило, что в статье не упомянуты Б3-34, МК-61, МК-52 - это же классика позднесоветского троллинга одноклассников и однокурсников:
Дай калькулятор посчитать.
Возьми, но ты на нём не посчитаешь.
С чего бы! Ой... а где "равно"?
"Не бывает полностью корректных парсеров. Бывают недоисследованные."
Ну про 12 и 16 мегабайт это больше маркетинг - реально работать было очень больно.
На 32 - я еще поверю, что можно было что-то делать. Например, запустить блокнот и диспетчер задач (хаха).
На 64 МБ можно было запустить Access 97, SQL Server Enterprise manager (божечки, модальные окна редактирования хранимок с пропорциональным шрифтом - это не забыть) и Query Analyzer. В принципе, можно даже BOL было открыть одновременно. Не скажу, что комфортно, но возможно.
На тех же 64 МБ можно было запустить мааааленький контроллер домена - пользователей на 20. Но только больше ничего нельзя было в этом случае туда больше ставить (дисковые чтения становились некешируемыми).
На 128-256 можно было поднять SQL Server 6.5, 7.0 или 2000.
Но вашего вопроса "почему то, что шустро работало 28 лет назад
на 16 мегабайтахсегодня требует на два-три порядка больше памяти" это не отменяет.И даже ответ понятен.
Во-первых, шустро оно не работало. Диски были медленными. Память была медленной (SIMM еще). Процессоры были медленными и 32-битными. Интернет был только в сказках.
Во-вторых, было меньше "прослоек", "фреймворков" и "уровней виртуализации". Это честный обмен - эти штуки сильно облегчают разработку ПО, но съедают много памяти и сколько-то производительности.
В-третьих, программы стали больше. Несоизмеримо больше. В воспоминаниях может и притупилось, но если вы возьмете СУБД 1997 года (ну тот же SQL Server 7.0, про 6.5 без слёз вообще сложно вспоминать), и попробуете его поднять в виртуалке (есть сложности, но вполне возможно), то удивитесь тому, насколько много относительно небольших неудобств, которые как раз и побеждались усложнением ПО.
Ну а в большом объёме, к сожалению, больше мусора. Обычно этот мусор остаётся именно потому что с ним бороться дороже, чем оставить. Память-то подешевела.
В "плоском" варианте, когда просто вкладки сверху, это, действительно, сомнительная практика. Но какой-нибудь Sideberry с древовидным отображением вкладок слева и регулярным бэкапом сессии - что же плохого? У меня прямо сейчас 2070 вкладок, раскиданы примерно по 20 древовидным панелям. В двух самых больших панелях 676 и 581 вкладка. Это больше среднего (есть временная причина), пора прибрать немного - я стараюсь держаться в 1000 вкладок, чтобы tab counter правильно работал.
Естественно, переоткрытие сессии и бэкапы сессий настроены и работают. В среднем раз в год примерно что-то корявое происходит из-за чего бэкап пригождается.
Я только на втором абзаце подумал "А не @Milfgard ли это?"
Интересно, как оно будет, если рядом будет более мощный передатчик (не такой же, это в статье было) на похожей частоте.
Затейливо. Замечу, что Arch по умолчанию для initramfs использует mkinitcpio, и использование dracut в arch нетипично, хотя и неплохо описано.
Пусть и перевод, но всё равно монументально (читал все части).
Если нужно именно десятичную запись, то лучше (проще) реализовать длинную арифметику самому. Потому что в Python (как и в Java/C#/JS и других популярных решениях) длинные числа хранятся по основанию 2 (технически - по основанию 2**32, но это неважно). И число 5 ** 9500000000 в таком виде займёт порядка 2,6 ГБ - что, кстати, само по себе может стать проблемой (Java и C# откажутся работать с такими в принципе, Python, насколько я знаю - сможет). Но после вычисления его еще надо вывести, а вот тут надо будет делить много раз на 10**n. В нынешнем Python по умолчанию ограничение 4300 цифр на такое преобразование. Но я бы и не пытался - деление в таких числах противная операция.
Если так припекло посчитать такую необычную операцию, то проще самому реализовать арифметику с основанием степени 10 (10**9, например - отличный выбор). Сложение "столбиком", умножение "столбиком" (для небольших чисел) и умножение Карацубы (для чисел больше 10**100) - задача на пару вечеров. Зато преобразование в десятичную запись линейное по времени и константа по дополнительной памяти.
PS: но я таки, как и предыдущие комментаторы замечу, что мне сложно представить задачу в которой это понадобилось бы.
С одной стороны - да, по умолчанию и почти всегда лучше скучный и понятный код с минимумом WTF/KLOC. С другой стороны - наши процессоры уже лет 10 не растут в скорости однопотока, GPU и SIMD проковыривают путь крайне медленно (SIMD на x86 - 30 лет, GPGPU - 20), с многопоточным масштабированием тоже всё не просто, скорость памяти типа "растёт", но с огромным количеством оговорок (растёт максимальная пропускная способность, но не задержка, а пропускная способность растёт только для длинной последовательной серии операций или для нескольких каналов) .
Хотя о чём это я? В статье разбирается конкретно DBeaver - это пользовательское приложение на Java, если в нём и важны такие оптимизации, то явно не там, где они есть на самом деле. Несмотря на моё искреннее уважение к этому инструменту, большие объёмы данных его заставляют задуматься (в его оправдание - DataGrip тупит еще больше на той же Java). Приведённые в статье примеры явно не из построчной логики обработки. И ладно бы он был не быстрый, но стабильный, так ведь нет - есть куча мелких странных раздражающих багов. Получается, что тот, кто выбирает скорость в ущерб качеству, не получит ни качества ни скорости.
Возможно, что в интерпретаторе с динамической типизацией такие оптимизации не так уж и просто и безопасно реализовать.
Кстати, вот просто взял и проверил. В
powтретий аргумент доступен только для целых чисел.Без чёткого определения, что такое "дефицит кадров", и без методики того, как его измеряли или планируют измерять, все подобные статьи имеют нулевую или отрицательную ценность.
Наверное можно было. Но это же надо было их искать.
Конкретно в этом офисе был свитч. Точнее там из-за неразберихи купили и свитч и хаб, но поставили, конечно, свитч, а хаб договорились вернуть (почему помню - там пришлось менять счета, СФ, перекидывать часть железа из следующего счета и т.д.)