Да, фейковые новости — та ещё проблема.
А ещё есть "шокирующие открытия", которые гонят в эфир с канала "RenTV". И насколько искажённое представление о науке получат люди, в поле зрения которых попадает этот канал?
В общем, зомбируют нас со всех сторон...

Дааа, бывают руководители, которым "выгоден" гадюшник. Они думают, будто выглядят на их фоне лучше и "авторитетнее". Белее и пушистее. Видел такого. И поговорку "свита делает короля" при нём лучше не произносить :)
Знаком и с таким коллективом, где женщины все как на подбор. Зато в мужской половине — окопался адский гадюшник, с ядром из 2-х психопатов.

О, кстати, вижу что я ошибся при оценке авторского алгоритма просеивания. Там же из-за инициализации массива будет асимптотика не O(n), а O(max(n,m)). Можно упростить до O(m), если во входных данных нет повторений, т.е. n<=m.

А хэш-таблицы не стоит выбрасывать из рассмотрения. И вот почему — алгоритм просеивания (хоть авторский, хоть оптимизированный) рассчитан только на работу со множеством целых чисел!
А что если множество состоит из других объектов? Да, к этому случаю возможно адаптировать просеивание, если назначить каждому объекту какой-то числовой (порядковый!) индекс. Для этого нужно определить порядок объектов во множестве — т.е. выполнить сортировку множества перед просеиванием. И сортировка эта будет стоить минимум O(m*log m), ухудшая асимптотику всего алгоритма.
Правда, если планируется выполнять алгоритм просеивания много раз на различных входных данных (но на одном и том же множестве объектов), то повторять сортировку множества не нужно — и получаем довольно быстрый алгоритм с предварительным расчётом.

Да, Вы правы.
После Вашего комментария, я понял идею оптимизированного алгоритма просеивания.
(тяжело понимать автора — у него вроде как берётся массив в размере множества; а Вы объясняете с оптимизацией по дополнительной памяти до размера входных данных)

Hash таблицы хороши если мы пытаемся найти значение которое точно есть, или то которого нет.

Так нам это и нужно!
Делаем в два прохода по набору исходных данных.
Проход 1 — запихиваем всё в хэш-таблицу.
Проход 2 — для каждого значения x в исходном наборе данных проверяем наличие в хэш-таблице значения, равного x+1. Если x+1 не найдено — значит, это потенциальное решение задачи.
Конечным результатом будет минимум между всеми отсутствующими в хэш-таблице x+1. Дополнительно надо проверить минимальное и максимальное значения в исходных данных (на любом из проходов).

P.S.:
Таким алгоритмом решается целый класс задач.
Вот ещё один пример: "найти в массиве все пары чисел, сумма которых равна числу m".

Ужасный пост.
О проблемах с O-нотацией уже сказали, не буду повторять.
Скажу лучше про затраты памяти. То, что некоторые быстрые алгоритмы требуют дополнительной памяти — это приемлемо. Как говорится, "за всё надо платить", за скорость в том числе. (и наоборот — за экономию памяти алгоритмы, как правило, платят скоростью)
Стёб же над "математиками" — совершенно неуместен.

Лучше было бы не ругать алгоритмы за скорость или память, а дать сравнительную характеристику, и пусть каждый выбирает вариант по своей задаче.

Примерно так:

1. Тривиальное решение ("в лоб") — не требует дополнительной памяти, но является квадратичным — O(n^2). Впрочем, производительность приемлема на крошечных множествах.
2. Решение, основанное на сортировке — работает с асимптотикой используемого алгоритма сортировки, т.е. не быстрее чем O(n*log_n). Алгоритм не зависит от размерности рассматриваемого множества.
3. Просеивание — работает с асимптотикой O(n), но требует дополнительной памяти O(m), где m — размерность множества. Память O(m) серьёзно ограничивает применимость алгоритма на практике, тем не менее — где-то и он может пригодиться.

P.S.:
Вижу алгоритм, работающий за O(n), с дополнительной памятью тоже O(n).
(использовать хэш-таблицу)

Ммм, а не могло оно произойти от русского слова "блуд"?
Вот тут попадание по смыслу очень даже.

Думаю, Вы правы.
Но меня вчера так выбесил манипулятивный характер публикации… Не смог пройти мимо речевого ляпа. И до кучи прицепился к нему тоже.

А хотя, я понял кому эта публикация предназначена.
Она не для нас, простых исполнителей. И не для конечных пользователей продукта. Она — для начальства, которому принимать решение о переходе на импортозамещённый продукт.
А что, похлопали глазками насчёт "лёгкости" и безболезненности перехода, умалили и обесценили трудности простых пользователей и программистов (ага, чтобы их "нытьё" начальство и слушать не хотело), и дело в шляпе!

А в энергетике много специальной терминологии, и весь документ из-за этого выглядит красным – Р7 воспринимает эти слова как ошибочные. И это жутко раздражает. Если честно мы вообще не понимаем, в чем тут проблема.

Бешено аплодирую! Действительно, ну какие тут проблемы? Подумаешь, глаза кровью текут — зато же ж импортзамещение. Гос.показуха — всё, люди — ничто!

Все говорят, что пользуются макросами, и ты говори

Ну вы тут грамотно высмеяли тех людей, которые не горят желанием переписывать на JavaScript свои макросы. Аплодирую стоя!
Только вот, стороной обходите вопрос — а что даёте на замену для MS Office VBA? Стесняетесь? Понимаю вас, тут хвастать нечем. API довольно куцый, а документация к нему — и вовсе "дас ис фантастишь!". Вот, наглядный пример: getvalue, getvalue2. Очень информативно, не правда ли? А как старательно все хелпы переведены на родной язык оболва... импортозамещённого отечественного покупателя! И как функционален сам API — тут аж на колени падаю от восхищения!..
Ну а удобной среды для разработки макросов и вовсе нет. Всё, что дали разработчики — это простенькое окошко для ввода текста, с пафосной пародией на Code Completion. Да и та, в любом месте кода выдаёт один и тот же, насквозь бессмысленный, список завершения.
Ну, кто это видел — тот в цирке уже не смеётся...

Еще пользователи поначалу могут упрекать новый продукт в медлительности. Однако факты этого не подтверждают, в целом «Р7-Офис» работает не менее быстро, чем импортный аналог.

А какими способами вы это проверяли? Напишите статью с описанием всех тестов! И тесты должны быть воспроизводимыми — чтобы любой мог их повторить и, наконец, поверить :)

К сожалению, не под любой Linux так можно компилить.
Там поддерживается совсем небольшой набор различных дистрибутивов: Supported Target Platforms

Спасибо за труд! (по созданию этой публикации)
Многабукаф, но осилил легко.
Всё про меня (не удивлён, т.к. давно в курсе)
Впрочем, и кое-что новое по теме для себя узнал

P.S.:
аффтар, пешы исчо!

Интересную Вы тему затронули, но с выводом насчёт "работы по дому" не угадали))
Попробуйте погуглить о том, какие "косметические" средства использовались средневековыми женщинами. Там уксус, соединения свинца, ртути, сурьмы, а также соки ядовитых растений… и много чего ещё, весьма опасного для здоровья и долголетия.

Как вы видите, в наиболее легкодоступной области лучше всего располагать интерактивные элементы, ведущие к монетизации

Спасибо, посмеялся ))

Раньше вроде сюда клали кнопку для наиболее часто используемой возможности (меню/пауза/игровая абилка/назад/подтвердить...), а теперь — "монетизацию".
Я понимаю, что (UX != Usability), но какой-то баланс должен же быть между алчностью и уважением к пользователю

Понравилось.
По-простецки написано, но жизненно...

Если речь идёт о конференции, то разве важно, какого цвета люди в это время ходят на улицах?
На конференции ждут не белых, не чёрных, не красных… а специалистов своего дела.

Кстати, у понятия "специалист" нет ни пола, ни цвета кожи, ни сексуальной ориентации.
Вдумайтесь в это. И перестаньте спекулировать на половых и расовых принадлежностях.

Т.е., условие мы пишем в начале цикла, а по факту проверяется оно в конце?

ИМХО: это будет путать программиста, привыкшего ставить условие там (в начале или конце), где оно должно проверяться.

Раз уж Вы решили дифференцировать циклы по истинности/ложности условия (while/until), то стоит добавить ещё 2 разновидности:
1) loop...while ( условие );
2) loop...until ( условие );
%-)

P.S.:
Замена "this->" на знак $ мне понравилась — приятный сахарок :)
Но выглядит лишним слово "end" после каждого "case" в операторе "switch"...

Забавненько!

Циклы "while" и "until" отличаются только способом обработки условия. И, по всей видимости, оба являются циклом с предусловием (хотя в упомянутом Паскале — цикл "repeat...until" — это цикл с постусловием).
Цикл "for" явно Сишного вида, и значит — тоже цикл с предусловием...

А где же в "новейшем" языке цикл с постусловием?

Спасибо за интересную публикацию!
Зачастую даже в умных книгах авторы не всегда утруждаются подачей вразумительных примеров.
У Вас в тексте просто по диагонали глазами пробежался, и вроде ничего нового… но то, что знал ранее, стало гораздо более понятным, как-то лучше в голове уложилось вместе с полезной рекомендацией ("is-a" / "has-a" для выбора между наследованием и композицией)...

P.S.:
Такой магии бы да побольше…
Пешыте исчо!

Хе-хех… Есть чрезвычайно простой алгоритм для создания "магических квадратов". Никакого перебора в нём вообще нет. Помню, в детстве у меня была детская энциклопедия по математике (от Аванта+), и в ней был описан алгоритм построения ("Меланхолия и магия в квадрате"). Заболев на 2-м курсе воспалением лёгких, лежал в больничке и, помимо решения японских кроссвордов, в тетрадке писал код на паскале, строящий "магические квадраты" заданной размерности. Неплохо развлёкся :)
Впрочем, переборный способ, наверное, неплох для демонстрации многопоточных техник и вычислений на GPU.

Понял Вас.
Прошу простить за скептическое отношение.
Сам микроконтроллеры не программировал, и тонкостей не знал (про отсутствие сдвига на некотором железе), поэтому судил со своей x86-й колокольни :)