Если вы про терминологию, то "по неубыванию" - более корректное выражение, чем "по возрастанию" (хотя и более неуклюжее), и часто используется в профессиональной литературе.
К данным стажировкам надо готовится отдельно, чуть ли ни как к FAANG/MAMAA. Там и алгоритмы, и специфическая подача задач, нацеленных на то, чтоб вас запутать. Типо «сортировка по неубыванию» и прочий бред.
Сегодня в топе не менее кликбейтные "У животных есть личности. И это ставит науку в тупик", "ChatGPT провалил тест на ручник" (эта вообще не соответствует содержимому, просто мнение одного анонимуса). Конкурировать с такими по-честному невозможно. Если бы эта статья содержала в названии "SystemVerilog", ее бы прочитало 15 человек и она бы набрала +2.
Не уверен, что правильно вас понял, но попробую ответить. Да, в теории очень здорово писать send_super_secret(email : VerifiedEmailAddress) и сама система типов будет гарантировать нам, что письма будут отправляться только верифицированным адресам. Во многих случаях это очень уместно и элегантно. Особенно если тип почты не нужно менять динамически. Но здесь мы начинаем подмешивать бизнес-логику. Например, нам может понадобиться разрешать отправку верифицированным адресам, но только тем, которые были активны в последний месяц лунного календаря. Завтра требования могут ослабнуть, и необходимо будет отправлять не только верифицированным, но и бывшим премиум-пользователям. Я к тому, что в send_super_secret вероятно добавятся различные условия и желательно предусмотреть возможность их появления заранее. (Возможно здесь помогут контракты, но я не силен в этом)
Пусть у нас будет второй тип с именем VerifiedEmailAddress. Если хотите, он даже может наследовать от EmailAddress
Понимаю, что это всего лишь пример, но тут классическая ловушка наследования. Мало того, что свойство Verified относится скорее к аккаунту, а не к адресу, так еще через пару итераций у нас будет что-то вроде:
VerifiedEmailAddress
VerifiedPersonalEmailAddress
VerifiedBusinessEmailAddress
NonVerifiedEmailAddress
NonVerifiedPersonalEmailAddress
NonVerifiedBusinessEmailAddress
А потом в эту иерархию понадобиться впихнуть IsActiveEmailAddress, IsSubscribedEmailAddress. Здесь, как мне кажется, более уместна композиция (псевдокод):
class Account:
email : EmailAddress
is_verified : bool,
type : {Personal, Business},
is_active : bool,
is_subscribed : bool
Это с точки зрения программиста, у которого в распоряжении одномерные массивы, но необходима структура данных, имеющая схожий с многомерными массивами интерфейс.
Если вы про терминологию, то "по неубыванию" - более корректное выражение, чем "по возрастанию" (хотя и более неуклюжее), и часто используется в профессиональной литературе.
Я не понял почему вы называете сортировку бредом
Магазин приложений Xiaomi - GetApps (а не Mi Store), и там уже давно есть указанные приложения
Тогда еще Dyson Sphere Program, Infinifactory, Shapez
Сегодня в топе не менее кликбейтные "У животных есть личности. И это ставит науку в тупик", "ChatGPT провалил тест на ручник" (эта вообще не соответствует содержимому, просто мнение одного анонимуса). Конкурировать с такими по-честному невозможно. Если бы эта статья содержала в названии "SystemVerilog", ее бы прочитало 15 человек и она бы набрала +2.
Существуют ли вариации с разновидовыми клетками? Например, модели хищник-жертва?
Более того, оценка O(n100) для пузырьковой сортировки — тоже корректна. Можно оценить точнее как Θ(n2) для худшего случая
Спасибо, раньше этой фичи не было
Obsidian ещё хуже для базы знаний, как мне кажется. Не люблю править в одном окне, смотреть в другом. Если бы не было картинок, то ещё ладно.
Кто-нибудь пользуется LogSeq?
Здорово, спасибо! Теория подтверждается
Во, я ждал такой коммент, спасибо! Можете сказать в двух словах, как именно вы искали?
Спасибо! Да, на картины ушло больше всего времени :)
Не уверен, что правильно вас понял, но попробую ответить. Да, в теории очень здорово писать send_super_secret(email : VerifiedEmailAddress) и сама система типов будет гарантировать нам, что письма будут отправляться только верифицированным адресам. Во многих случаях это очень уместно и элегантно. Особенно если тип почты не нужно менять динамически. Но здесь мы начинаем подмешивать бизнес-логику. Например, нам может понадобиться разрешать отправку верифицированным адресам, но только тем, которые были активны в последний месяц лунного календаря. Завтра требования могут ослабнуть, и необходимо будет отправлять не только верифицированным, но и бывшим премиум-пользователям. Я к тому, что в send_super_secret вероятно добавятся различные условия и желательно предусмотреть возможность их появления заранее. (Возможно здесь помогут контракты, но я не силен в этом)
Понимаю, что это всего лишь пример, но тут классическая ловушка наследования. Мало того, что свойство Verified относится скорее к аккаунту, а не к адресу, так еще через пару итераций у нас будет что-то вроде:
VerifiedEmailAddress
VerifiedPersonalEmailAddress
VerifiedBusinessEmailAddress
NonVerifiedEmailAddress
NonVerifiedPersonalEmailAddress
NonVerifiedBusinessEmailAddress
А потом в эту иерархию понадобиться впихнуть IsActiveEmailAddress, IsSubscribedEmailAddress. Здесь, как мне кажется, более уместна композиция (псевдокод):
Спасибо, буду писать тогда :)
Это с точки зрения программиста, у которого в распоряжении одномерные массивы, но необходима структура данных, имеющая схожий с многомерными массивами интерфейс.
Также упрощается и становится более интуитивной реализация многомерных массивов:
@Exosphere, к какой номинации подходят статьи про алгоритмы? Меня, в частности, интересует JPEG
Через onnxruntime на Питоне. Планирую попробовать эту либу на C++