Comments 29
Так тройка встречается чаще всего, вот и ответ.
Где именно встречается? В генераторе случайных чисел? О чем вообще речь? Метод пристального взгляда?
А, Вы решили, что первые восемь строчек месть задача? Оригинально. Но это совсем не так, это просто фрагмент, какой-то срез. Не знаю, зачем все понимать в худших трактовках? Тем более, что дальше по тексту видно, чтотданнвх куда больше, да и не в этом вообще суть.
По привычке экономить память, использую битовые данные, например, для задания выборочной обработки деталей в групповой оснастке на станке с ЧПУ. Куда проще хранить маску в одной переменной, а в подпрограмме делать сравнения с номером текущей системы координат, чем использовать кучу переменных, как флаги и вычислять в подпрограмме номер флага для проверки.
В программировании микроконтроллеров и вообще цифровой электронике отдельные биты используются везде и всюду. И я считаю это очень правильным подходом, которым следовало бы оперировать везде, т.к. обработка, передача и хранение данных, закодированных таким образом может осуществляться гораздо дешевле во всех смыслах этого слова. И если программисты серверных и десктопных приложений на это не способны и везде городят какие-то огромные конструкции из кучи абстракций, то за что же им тогда платят такие огромные деньги?
Но ведь именно для этой задачи, в которой надо просто выделить наиболее часто втречающийся элемент выборки, использование бинарной арифметики -- это абстракция, причем неочевидная и строящаяся на предположнении о том, что анализируемые данные вписываются в байт или слово. Эффективность этого решения (на Питоне) будет заметной только для миллионов подобных анкет, а подднржка этой абстрации при небольшом изменении методов опроса (добавлении веса, например) приведет к существенному перестроению и логики и используемых данных. Так что абстракции в программировании неизбежны, и больше платят за те, которые делают работу програмииста более предметно-ориентированной.
обработка битов медленнее обработки байтов. Так что нет, это не быстрее. А платят разработчикам серверных и прочих приложений за качественный код, который потом можно редактировать, а не копаться в битах и разбираться почему после изменения sizeof структурки всё упало
тут вроде как тема DS затрагивается. у разработчиков ПО другие приоритеты и другие задачи. Работа с битами может быть такой же быстрой -- логическое И/ИЛИ над словом и маской -- примерно такая же операция в конвейере ALU. Но даже не в этом суть. Еще раз повторю, задача -- как предложение посмотреть вокруг себя. Допускаю, что тем, кто на ассемблере не писал, все это кажется странным и ненужным...
Кстати, насколько давно доводилось видеть качественный код приложения? Не какой-либо отдельной функции отдельного разработчика, а именно приложения? Какого-нибудь?
Вопрос по входным данным. Каждый голосующий подает бюллетень с массивом ответов. Что значит позиция ответа? По мнению голосующего: те ответы, что стоят в начале массива более предпочтительны, чем те что в конце; или равнозначны?
задача самая простая -- равнозначны.
можно считать, что это голосование за паб для отмечания корп. нового года :)
С пабами всё совсем не просто. В этом я на прошлой неделе устроил дебош и меня туда теперь не пускают. А в том пиво разбавляют. А в третьем - скользкие ступеньки, но не все об этом знают, потому что зимой ещё не заходили туда.
Все неважно.
С новогодними пабами все предельно просто -- наступает точка невозврата.
В определенный момент остается два варианта -- либо прекращаем строить сложные модели, есть друг другу мозг и хватаем то, что еще пока осталось, либо просто никуда не идем.
И это замечательно, поскольку без внешнего меча очень часто все превращается в бесконечную жвачку.
И в гига и в пета и в зеттабайтах найдется место битам. Возьмем к примеру современные СУБД, хотя бы MS SQL. Есть поле (для простоты) типа tinyint. Может хранить значения 0...255. Надеюсь ясно, что это 8 бит. Но! при условии что оно объявлено как NOT NULL. Значит NULL - это 256-е значение. Но вот в 8 бит (в байт) оно уже не помещается. Нужен хотя бы еще один бит, котроый был бы признаком того, что в этом поле - NULL. Но при этом введение такого бита напрочь сломает всё выравнивание данных по границе байтов.
Поэтому (в MSSQL, и скорее всего в большинстве СУБД) NULL-ы хранят отдельно от данных (но недалеко), в "bitmap"-ах. То есть в массиве бит, каждый из которых говорит о том, NULL или не-NULL в соответствующем ему значению в "реальной" таблице.
И любая операция над полем, допускающим NULL (даже тупо сравнение, т.к. NULL не равен ничему, включая NULL), помимо обращения к данным основной таблицы обязательно требует обращение к этому bitmap-у. И это не самая простая операция.
Так что при проектировании схемы БД - везде где только можно - объявляйте поля как NOT NULL.
Биты рулят.
О! Не думал, что кто-нибудь вспомнит "Быстрые мысли".
А почему бы и нет? Послевоенные книги по естественным наукам очень хорошо читать. Экстренное воспитание тысяч инженеров было жизненно необходимо. Материал подавали без всяких "очевидно" и небрежностей. Четко, ясно, доходчивым языком.
И справочники весьма качественные. Кстати, и книги по радиоэлектронике тоже хороши. Пусть на лампах, но принципы на пальцах показывают.
Кто думает, что память на ферритовых кольцах в прошлом? Можно заглянуть в военную технику, чтобы понять что это заблуждение.
Только сейчас увидел, что моё решение из чата стало примером для "типичного выпускника DS курсов"))
Так приходит слава. Спасибо, Илья)
О бедном бите замолвите слово