lenin

Please leave message here to contact me

My LJ is mostly in Russian, but I may comment in English in other people's blogs or in communities when appropriate.

NB: Wherever there is a non-functioning link to zalil.webhop.org, use s87137312.onlinehome.us instead.

Пожалуйста, не надо меня френдить на один-два дня в расчете, что я отвечу взаимностью, а потом отфренживать, если этого не произошло.

Друзьями делаю кого хочу читать (в ответное френжение просто так не играю; журналы, состоящие в основном из нетекстового содержимого, вряд ли зафренжу), проверяю историю изменения друзей раз в пару недель или реже, не нуждаюсь в помещении меня в список друзей, могу в зависимости от обстоятельств комментировать по-английски либо транслитом, на что не обессудьте.

Под замком практически не пишу.
lenin

Я вам один капитализационный вопрос задам, только вы не обижайтесь

Если в США чёрный полицейский застрелит ку-клукс-клановца, или кто там сейчас вместо них, напишут ли в прессе про него the black police officer who fatally shot a White man?

This entry was originally posted at https://spamsink.dreamwidth.org/1210277.html. Please comment there using OpenID.
lenin

Придумал способ делать спойлеры

...не зависящие от движка и не требующие стилей, джаваскрипта и подобного.
Вот такой:

Считаю, что придумал, потому что ни у кого раньше такой не видел.

This entry was originally posted at https://spamsink.dreamwidth.org/1209863.html. Please comment there using OpenID.
lenin

Об одном самонадеянном комментарии

Трюк из предыдущего поста базируется на том, что программа zcat (gunzip), кроме своего собственного формата .gz, умеет разжимать еще и устаревшие форматы compress (.Z), который был основным и самым популярным до распространения gzip, а также предшествоваший ему формат pack (.z).

Этот формат pack был довольно прост. До 1977-78 годов, когда профессор אברהם למפל (родившийся в 1936 году, как и положено еврейскому математику, во Львове) и профессор יעקב זיו (родившийся в 1931 году, сабра), да будут они оба здоровы, изобрели семейство алгоритмов LZ, всё искусство сжатия текстов, отличных от длинных повторов одинаковых символов, недалеко ушло от кода Морзе: чего много - обозначаем более короткой последовательностью нулей и единиц вместо точек и тире, чего мало - обозначаем более длинной. В алгоритмические детали (префиксные коды, отличия кодировки Хаффмена от Шеннона-Фано) вдаваться не будем.

Благодаря тому, что создателю программы была поставлена задача сжимать только файлы (а не потоки байтов), сжиматель работает в два прохода - сначала собирает статистику по символам и строит таблицу, а потом читает файл ещё раз и выдаёт его сжатый вид. Из-за этого в начале сжатого файла есть таблица соответствия символов кодам, в которой можно устроить почти произвольную перетасовку символов, в частности ROT13.

А теперь по существу темы поста. Для простоты и скорости выполнения программы максимальная длина кода была ограничена 24 битами, чтобы при побайтной записи в сжатый файл или чтении из него в 32-битном слове гарантированно помещался как минимум один код независимо от положения кода по отношению к границам байтов (можно бы и 25, в принципе, ну да ладно). Эффективный алгоритм построения кодов с ограничением длины тогда еще не придумали, поэтому решили, что на практике такого соотношения частот символов, которое могло бы привести к кодам длиной более 24, не встретится. Действительно™, чтобы у символа был код длиной 1 бит, его частота должна быть порядка 50%, длиной 2 бита - порядка 25%, и т.п. Итого, чтобы длина кода была больше 24, частота символа должна быть меньше 1/224, а это может быть, только если символ встречается реже, чем 1 раз на 16 Мб.

Типичные длины файлов, которые могло бы захотеться сжимать этим алоритмом, в конце 70-х годов были от силы порядка сотен килобайт (потому что емкости дисков были порядка единиц мегабайт), вот и в программе написано



На самом же деле это наглое враньё, и рассуждение выше с "действительно" - заблуждение. В молодости у меня не потребовалось много времени, чтобы, познакомившись с программой pack, вызвать эту диагностику с помощью файла гораздо меньшей длины, чем 16 Мб. Попробуйте и вы.

Автор первоначальной программы - T.G. Szymanski (тот, который вторая S в LZSS). Вот же ж ведь позорник.

This entry was originally posted at https://spamsink.dreamwidth.org/1209677.html. Please comment there using OpenID.
lenin

Из Лувра и музея Карнавале пишут

via



Оказывается, целым двум парижским музеям недавно надоело, что их спрашивают "а что это у вас тут написано", показывая на римские цифры в номерах веков или монархов, и они решили писать арабскими (Лувр пока только века, а Карнавале и монархов тоже). Статья начинается с шутки 30-летней давности «À mort Louis-croix-vé-bâton» (к сожалению, без подписки много прочесть не дают), так что дело к тому шло.

По мне так это и логично. Единственная корысть в римских цифрах - это то, что по крайней мере в русском языке числа, ими записанные, по умолчанию означают порядковые числительные, а не количественные ("XX век", но "20-й век"), и поэтому не требуют наращений (а то с 15-м съездом машинописный конфуз будет), но по-французски номера монархов количественные (Louis quatorze, а не Louis quatorzième, так что им не должно быть никакой разницы, даже если у них и имелось такое семантическое различие.

Впрочем, и в русском мы видим тенденции к переходу на арабские цифры в порядковых числительных. Чем писать, например, MDCCCXXXVII, мы пишем "1837 г." без наращения и прекрасно себя чувствуем, понимая по контексту, что числительное тут порядковое. И в номерах веков арабские цифры нас, вроде, не особенно раздражают. Ну 15-й век, ну 20-й.

Так что же нам мешает отряхнуть остатки этой античной пыли и писать "Иоанн 22", "Пий 9", "Бенедикт 16" и пр., понимая, что читать числительное нужно как порядковое, потому что, в отличие от "Маяк-202" или "уран-235", разделителем служит пробел, а не дефис?

This entry was originally posted at https://spamsink.dreamwidth.org/1209137.html. Please comment there using OpenID.
lenin

(no subject)

Какие неленивые люди в Великобритании живут! Одни придумывают головоломки на тему новой банкноты, посвященной Тьюрингу, другие их тут же решают почём зря...



This entry was originally posted at https://spamsink.dreamwidth.org/1208981.html. Please comment there using OpenID.
lenin

Исправление ошибок

Как мы знаем™, в номерах кредитных карточек последняя цифра - контрольная, так что любая ошибка в одной цифре будет распознана (а также и большинство ошибок перестановки соседних цифр, но это другая история). Таким образом, если в номере карточки N десятичных цифр, то теоретически валидных номеров будет 10N-1.

А что, если мы хотим не только распознавать, но и исправлять одиночные ошибки? Сколько тогда будет валидных N-значных десятичных номеров?

Рассмотрим для начала трехзначные номера. Тут мы быстро обнаружим, что валидных номеров может быть не более чем 10, потому что одна и та же цифра не может повторяться ни в одной позиции. Действительно, если номера вида ABC и ADE оба будут валидны, то мы не сможем понять, как исправить номер ABE. Или, другими словами, хэммингово расстояние между двумя валидными номерами должно быть не меньше трёх.

А сколько можно построить четырёхзначных номеров, исправляющих одиночную ошибку замены? Ровно 100 или меньше?

This entry was originally posted at https://spamsink.dreamwidth.org/1208379.html. Please comment there using OpenID.