При a > b: lim[(a^n + b^n)^(1/n)] = lim[(a^n * (1 + (b/a)^n))^(1/n)] = lim[(a^n)^(1/n)] * lim[exp{ln(1 + (b/a)^n)*1/n}] = lim[a^(n/n)] * exp{lim[ln(1+(b/a)^n)] * lim[1/n]} = a * exp{ln(1 + lim((b/a)^n)) * 0} = a * exp{0 * 0} = a. Здесь lim((b/a)^n) = 0, т.к. b/a < 1.
В обратную сторону при a < b по аналогии.
При a=b технически lim((b/a)^n)=1, и остаётся ln(2), но он всё равно множится на 0.
В общем, неопределённостей не возникает, и мы просто тащим пределы внутрь.
@AskePit тем самым, доминирование формально вылезает в lim[(b/a)^n] или lim[(a/b)^n]. И никакого "доказательство оставим в качестве несложного упражнения читателю" :)
Да, кстати та же история с Питоном, я как-то попробовал там ехать на ООПе, и мне это очень не понравилось из-за того, насколько сбоку с этим self оно там прилеплено. Выхлопа вообще никакого в нём от ООП, только раздражение.
Не, ну если даже на 3.5 кое-что получается, то прикольно.
Но вообще 3.5 это из декабря 2022 где-то. ChatGPT 4 на порядки порядков лучше, и с кодом тоже, конечно же. Месяцы уже используем вдоль и поперёк и для кода, и не для кода. С самого появления в марте 2023. Не панацея, но времени экономит (и денег) ВАГОН. Он такие штуки делает за 20 баксов в месяц, на которые раньше приходилось нанимать целого девопса. И, нет, не пишите им код, который вы быстрее напишите сами. Делайте им вещи, в которых ещё не разбираетесь или не планируете разбираться, он готовит прекрасные болванки и очень быстро (допиливать, понятное дело, самому).
ChatGPT 3.5 популярна разве что у домохозяек, либо у тех кто хочет сам себя убедить в том, что "это всё не работает и мы, прогеры, продолжим квадриллион денег за перекрас кнопки получать".
Какова была первопричина возможности проникновения чужого в аккаунт? Не было первичной авторизации по СМС (до привязки по приложению к скану отпечатка или лицу) или чего-то ещё?
Да, и это всё перечеркнёт преимущества C++ как такового. Компилятор, как правило, на встраивает код там, где идёт вызов именно виртуальных функций; иногда у него получается, но чаще просто нет достаточно контекстной информации. Там, где скорость важна, это критично. А если не важна, так симпатичнее такие конструкты ваять на C# или Java. Было время конечно, в 90-х всё писали плотно на C++, бизнес-приложения, GUI и т.д. Да прошло. И начинаются в C++ извращения типа CRTP и прочего страха, чтобы получить некое подобие полиморфных иерархий без уплаты цены виртуализации функций. Всё это дико ломает IntelliSense даже в 2024, и в общем не стоит того, как мне кажется по прошествии лет.
Я понимаю, что не о C++ речь идёт, а в целом. К тому, что ООП ООПу рознь, в зависимости от конкретной реализации в конкретном языке.
Правда, как только будет введена конвенция в имени метода (начинаем с имени обрабатываемого класса), либо метод помещён в namespace, аргумент становится менее актуальным. Понятно, что приятно видеть листинг методов на объекте класса, но если мы "помним" класс объекта, то ситуация упрощается.
Да, это классная дискуссия! Помню ещё на заре Рунета горячо обсуждали с одним товарищем, чем len(L) лучше L.length() :) Не с вами, правда, Максим (я вас с давности тут читаю). А Питон тогда ещё был не вполне популярен, почти что маргинален. Думаю сейчас об этом и понимаю: действительно в C с этим проще, ведь решение о том, тащить ли метод в класс или сделать его внешним — его принимать не надо, оно уже и так принято.
Я думаю об этом как о проблеме скорее вот в каком ключе. Пусть у нас есть некоторые связанные данные, которые мы будем обрабатывать "поколоночно". На современных векторных архитектурах это типично. Тогда, с подходом "структура как носитель данных", нам несложно организовать структуру с тремя векторами, которые будут хранить точки (x,y,z) поколоночно, и даже сделать ей специальный геттер, чтобы можно было вернуть отдельную точку как тройку (x,y,z) (в C++20 можно красиво сделать), и это всё классно ляжет на компилятор. А вот адепт ООП наверняка сделает класс Point с тремя числами в нём, и далее по списку. Таким образом, ООП определит структуру хранения, которая в данном случае приведёт к худшей производительности. Конечно, можно заморочиться, и подложить под этот Point-класс какие-то хитрые структуры хранения и аллокаторы, абстрагирующие форму хранения от единичного элемента данных, но это будет весьма некрасиво и потребует много усилий на создание и сопровождение. Да и приведёт к обратному эффекту — мы вроде ООП делали, а в итоге изготовили дикий замес всего и сразу. Отказ от чистого ООП, как мне кажется, просто уберёт ненужную абстракцию и сделает всем счастье.
У меня до 11 не было такого. Всегда на новьё пересаживался, начиная с 3.1. Но 11 это просто плевок в сторону адептов этой среды. Сделать интерфейс нарочитым уродом и выбросить кучу привычных микро-взаимодействий, которые там со времен царя Гороха и к которым просто уже мышечная память. Просто уроды, нечего больше и сказать.
Мне вообще вся эта история с виндой-уродом кажется вполне в рамках политической конъюнктуры. "Мы можем сделать нормально, но мы вам СПЕЦИАЛЬНО сделаем урода, и вы ДОЛЖНЫ будете его любить!".
Да :) И где-то рядом ADL (Koenig lookup). Ну вот оно всё такое "не-до", на мой взгляд в С# (сильно позже конечно же) получилось продуманнее. А в С++ конечно всё это достаточно забавно, когда только начинал, пытался найти стройный замысел в хитросплетениях private/protected/public/friend, но с годами настолько это прочувствовал, что понял – а нет этого замысла. Получилось как получилось.
Пишу на С++ последние лет 20, до этого ещё Delphi лет 10. С годами полностью отошёл от ООП в сторону data-driven design. Классы — практически структуры, из методов как правило только декоративные геттеры. Всё остальное — это просто функции с понятными названиями, сигнатурами и операндами-объектами таких вот классов-носителей данных и состояния. Получается, очень легко дышится и чистенько — состояния изолированы в структуры, логика изолирована в функции. Конечно, в C++ всё довольно печально с ООП как таковым, поскольку нет механизма extension methods — это когда вы собираете методы в класс из разных единиц трансляции; из-за этого, обычные функции C++ значительно удобнее методов класса. Но действительно с годами я начал понимать, почему многие мои профессиональные друзья "немного за 50" перешли вообще на чистый С. За мишурой ООП и других парадигм типа шаблонного мета-программирования мы теряем важное — эффективно расходовать время жизни. Оказывается, убрав лишнее (например, перейдя с С++ на С), мы отсекаем ненужное и фокусируемся на чистом результате. Я не хотел бы полностью отказываться от С++, но объективно сократил использование его фич до очень ограниченного подмножества, это очень здорово помогло.
Торт из пельменей. Такой несложно сделать в кастрюле.
Да, не все от него оттолкнулись...
Это низина.
Спасибо за статью, отличная!
При
:
Здесь
, т.к. 
.
В обратную сторону при
по аналогии.
При
технически 
, и остаётся 
, но он всё равно множится на 
.
В общем, неопределённостей не возникает, и мы просто тащим пределы внутрь.
Тем самым, доминирование формально вылезает в
и в 
И никакого "доказательство оставим в качестве несложного упражнения читателю" :)
Да только сейчас понял, что формулы теперь на "плюсике" сидят. Приношу извинения, редактировать уже поздно ?♂️
При a > b: lim[(a^n + b^n)^(1/n)] = lim[(a^n * (1 + (b/a)^n))^(1/n)] = lim[(a^n)^(1/n)] * lim[exp{ln(1 + (b/a)^n)*1/n}] = lim[a^(n/n)] * exp{lim[ln(1+(b/a)^n)] * lim[1/n]} = a * exp{ln(1 + lim((b/a)^n)) * 0} = a * exp{0 * 0} = a. Здесь lim((b/a)^n) = 0, т.к. b/a < 1.
В обратную сторону при a < b по аналогии.
При a=b технически lim((b/a)^n)=1, и остаётся ln(2), но он всё равно множится на 0.
В общем, неопределённостей не возникает, и мы просто тащим пределы внутрь.
@AskePit тем самым, доминирование формально вылезает в lim[(b/a)^n] или lim[(a/b)^n]. И никакого "доказательство оставим в качестве несложного упражнения читателю" :)
Расскажите подробнее
Да, кстати та же история с Питоном, я как-то попробовал там ехать на ООПе, и мне это очень не понравилось из-за того, насколько сбоку с этим self оно там прилеплено. Выхлопа вообще никакого в нём от ООП, только раздражение.
Нам всем нужно вспомнить вот такой мем :)
Не, ну если даже на 3.5 кое-что получается, то прикольно.
Но вообще 3.5 это из декабря 2022 где-то. ChatGPT 4 на порядки порядков лучше, и с кодом тоже, конечно же. Месяцы уже используем вдоль и поперёк и для кода, и не для кода. С самого появления в марте 2023. Не панацея, но времени экономит (и денег) ВАГОН. Он такие штуки делает за 20 баксов в месяц, на которые раньше приходилось нанимать целого девопса. И, нет, не пишите им код, который вы быстрее напишите сами. Делайте им вещи, в которых ещё не разбираетесь или не планируете разбираться, он готовит прекрасные болванки и очень быстро (допиливать, понятное дело, самому).
ChatGPT 3.5 популярна разве что у домохозяек, либо у тех кто хочет сам себя убедить в том, что "это всё не работает и мы, прогеры, продолжим квадриллион денег за перекрас кнопки получать".
Какова была первопричина возможности проникновения чужого в аккаунт? Не было первичной авторизации по СМС (до привязки по приложению к скану отпечатка или лицу) или чего-то ещё?
Хотеть :)
Да, и это всё перечеркнёт преимущества C++ как такового. Компилятор, как правило, на встраивает код там, где идёт вызов именно виртуальных функций; иногда у него получается, но чаще просто нет достаточно контекстной информации. Там, где скорость важна, это критично. А если не важна, так симпатичнее такие конструкты ваять на C# или Java. Было время конечно, в 90-х всё писали плотно на C++, бизнес-приложения, GUI и т.д. Да прошло. И начинаются в C++ извращения типа CRTP и прочего страха, чтобы получить некое подобие полиморфных иерархий без уплаты цены виртуализации функций. Всё это дико ломает IntelliSense даже в 2024, и в общем не стоит того, как мне кажется по прошествии лет.
Я понимаю, что не о C++ речь идёт, а в целом. К тому, что ООП ООПу рознь, в зависимости от конкретной реализации в конкретном языке.
Да! супер!
Пока верится с трудом :) Наплодят кучу другого проблемного ?
Контекст — это на мой взгляд хороший аргумент.
Правда, как только будет введена конвенция в имени метода (начинаем с имени обрабатываемого класса), либо метод помещён в namespace, аргумент становится менее актуальным. Понятно, что приятно видеть листинг методов на объекте класса, но если мы "помним" класс объекта, то ситуация упрощается.
Да, это классная дискуссия! Помню ещё на заре Рунета горячо обсуждали с одним товарищем, чем len(L) лучше L.length() :) Не с вами, правда, Максим (я вас с давности тут читаю). А Питон тогда ещё был не вполне популярен, почти что маргинален. Думаю сейчас об этом и понимаю: действительно в C с этим проще, ведь решение о том, тащить ли метод в класс или сделать его внешним — его принимать не надо, оно уже и так принято.
Я думаю об этом как о проблеме скорее вот в каком ключе. Пусть у нас есть некоторые связанные данные, которые мы будем обрабатывать "поколоночно". На современных векторных архитектурах это типично. Тогда, с подходом "структура как носитель данных", нам несложно организовать структуру с тремя векторами, которые будут хранить точки (x,y,z) поколоночно, и даже сделать ей специальный геттер, чтобы можно было вернуть отдельную точку как тройку (x,y,z) (в C++20 можно красиво сделать), и это всё классно ляжет на компилятор. А вот адепт ООП наверняка сделает класс Point с тремя числами в нём, и далее по списку. Таким образом, ООП определит структуру хранения, которая в данном случае приведёт к худшей производительности. Конечно, можно заморочиться, и подложить под этот Point-класс какие-то хитрые структуры хранения и аллокаторы, абстрагирующие форму хранения от единичного элемента данных, но это будет весьма некрасиво и потребует много усилий на создание и сопровождение. Да и приведёт к обратному эффекту — мы вроде ООП делали, а в итоге изготовили дикий замес всего и сразу. Отказ от чистого ООП, как мне кажется, просто уберёт ненужную абстракцию и сделает всем счастье.
У меня до 11 не было такого. Всегда на новьё пересаживался, начиная с 3.1. Но 11 это просто плевок в сторону адептов этой среды. Сделать интерфейс нарочитым уродом и выбросить кучу привычных микро-взаимодействий, которые там со времен царя Гороха и к которым просто уже мышечная память. Просто уроды, нечего больше и сказать.
Мне вообще вся эта история с виндой-уродом кажется вполне в рамках политической конъюнктуры. "Мы можем сделать нормально, но мы вам СПЕЦИАЛЬНО сделаем урода, и вы ДОЛЖНЫ будете его любить!".
Да :) И где-то рядом ADL (Koenig lookup). Ну вот оно всё такое "не-до", на мой взгляд в С# (сильно позже конечно же) получилось продуманнее. А в С++ конечно всё это достаточно забавно, когда только начинал, пытался найти стройный замысел в хитросплетениях private/protected/public/friend, но с годами настолько это прочувствовал, что понял – а нет этого замысла. Получилось как получилось.
Пишу на С++ последние лет 20, до этого ещё Delphi лет 10. С годами полностью отошёл от ООП в сторону data-driven design. Классы — практически структуры, из методов как правило только декоративные геттеры. Всё остальное — это просто функции с понятными названиями, сигнатурами и операндами-объектами таких вот классов-носителей данных и состояния. Получается, очень легко дышится и чистенько — состояния изолированы в структуры, логика изолирована в функции. Конечно, в C++ всё довольно печально с ООП как таковым, поскольку нет механизма extension methods — это когда вы собираете методы в класс из разных единиц трансляции; из-за этого, обычные функции C++ значительно удобнее методов класса. Но действительно с годами я начал понимать, почему многие мои профессиональные друзья "немного за 50" перешли вообще на чистый С. За мишурой ООП и других парадигм типа шаблонного мета-программирования мы теряем важное — эффективно расходовать время жизни. Оказывается, убрав лишнее (например, перейдя с С++ на С), мы отсекаем ненужное и фокусируемся на чистом результате. Я не хотел бы полностью отказываться от С++, но объективно сократил использование его фич до очень ограниченного подмножества, это очень здорово помогло.