Мне вполне вольготно жилось в этой позиции, но какое-то время назад я понял, что моё мировоззрение изменилось. Убеждение «вот так говорят, а так не говорят» сменилось на «давайте делать язык богаче, а не беднее». Не заменять «одолжил» на «занял», «надел» на «одел», «из» на «с», «последний» на «крайний» и так далее. Просто потому что это ведёт к потере оттенков.

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

Я до сих пор поправляю окружающих, но далеко не всех. Например, поправляю дочку, чтобы она говорила правильно, просто потому что литературная норма и умение говорить ассоциируется с профессионализмом, а я ей желаю успешной профессиональной карьеры. Пока у неё планы стать дизайнером интерьеров.

Не факт, что лет через пять мы не будем общаться через речевые фильтры, которые будут поправлять все огрехи, синхронизируя губы, но личное общение, я уверен, всё равно не исчезнет.

Я на днях под влиянием книги «Сфера-80…», про которую недавно рассказывал, решил пофантазировать, как можно было бы гипотетически расширить «Электронику МК-61», если бы я, подобно герою книги, попал в то время и мне бы довелось его разрабатывать.

Поскольку этот калькулятор изначально не задумывался для игр, однако для него написано более шестисот игр, которые были опубликованы, и неизвестно сколько ещё пропало, мысли мои пошли в сторону того, что именно я бы добавил туда, чтобы на нём было интереснее играть.

Расширил набор команд двумя префиксами, в другой раз покажу какими, а для тестирования, как водится, написал при помощи нейросети игру — простой клон известной «Элиты». Для «МК-61» это не диковинка — в моём каталоге их четыре штуки, но тут новый уровень.

Игра поначалу получилась достаточно объёмной, и, чтобы сэкономить место на диске, а заодно ускорить загрузку, я решил добавить к расточительному шестнадцатеричному формату хранения программ что-то более компактное.

Вспомнил, конечно, про Base64, а также более редкий Base85, но оказалось, что есть ещё чуть более экономный формат Base91. Я, вроде, про него слышал, но крепко про него забыл. Все они, по сути, решают одну проблему — кодируют бинарную информацию так, чтобы её можно было хранить внутри текстовых файлов.

Самый простой вариант — шестнадцатеричная запись. Каждый байт превращается в два символа от 00 до FF. Это очень удобно для человека: файл можно открыть в редакторе, посмотреть и при некотором опыте даже что-нибудь исправить. Но за удобство приходится платить — размер данных увеличивается ровно вдвое.

Base64 работает экономнее. Он собирает три байта, то есть 24 бита, и превращает их в четыре символа по шесть бит каждый. Отсюда и название: шесть бит позволяют выбрать один из 64 символов. Размер файла при этом вырастает примерно на треть.

Base85 упаковывает четыре байта в пять символов. Тут уже нет такого красивого соответствия битам, зато 85⁵ чуть больше 2³², поэтому любой четырёхбайтовый блок в эти пять символов помещается. Накладные расходы уменьшаются до 25%.

Алгоритм, который обычно называют Base91, на самом деле называется «basE91» — именно так, с заглавной «E» посередине. Его написал Йоахим Хенке. В качестве алфавита он взял почти все печатные символы ASCII, кроме дефиса, апострофа и обратной косой черты.

На первый взгляд кажется, что Base91 должен просто брать некоторое количество бит и переводить получившееся число в систему счисления с основанием 91. Но подходящего целого количества бит тут нет: один символ вмещает чуть больше шести с половиной бит.

Зато хорошо работают пары символов.

В двух символах Base91 гарантированно помещаются 13 бит, причём после этого остаётся ещё 89 незанятых комбинаций. Автор алгоритма решил их не выбрасывать.

Обычно очередная пара символов хранит 13 бит. Но если значение этих бит попадает в диапазон от 0 до 88, кодировщик прихватывает ещё один, четырнадцатый бит. Для каждого из 89 маленьких значений получается две версии: с нулём и единицей в дополнительном бите. Декодер по получившемуся числу понимает, сколько бит надо забрать из входного потока — 13 или 14.

В исходном коде вся эта математика превращается в очень короткую проверку:

(v & 8191) > 88 ? 13 : 14

Без объяснения числа «88» и «8191» выглядят как магические константы. На самом деле первое число это те самые 89 оставшихся комбинаций, только нумерация начинается с нуля, а «8191» — это 2¹³ − 1, или тринадцать единиц в двоичной записи для выделения тринадцати младших бит.

Из-за такого устройства размер результата зависит от содержимого. В худшем случае Base91 добавляет около 23%, а на данных с большим количеством нулевых байтов накладные расходы могут уменьшаться примерно до 14%. Для обычного смешанного бинарного потока получается около 22,97%.

Если взять тысячу байтов, то без учёта заголовков и переносов строк выйдет примерно так:

• шестнадцатеричный формат — 2000 символов;
• Base64 — 1336;
• Base85 — 1250;
• Base91 — обычно около 1230.

То есть по сравнению с Base85 выигрыш совсем небольшой — около двадцати символов на килобайт. Зато по сравнению с исходным шестнадцатеричным форматом файл уменьшается почти на 40%.

Для обычной программы «МК-61» размером 105 байтов цифры  такие: 210 символов в шестнадцатеричном виде, 140 в Base64, примерно 132 в Base85 и около 129 в Base91. Всего три символа выигрыша у Base85, зато 81 — у старого формата. На одной программе можно было бы не обращать внимания, но на большой игре и целом каталоге разница постепенно накапливается.

У меня программа получилась побольше — несколько килобайт, мои расширения такое позволяют, поэтому я перед кодированием ещё и сжимаю программу уже испробованным алгоритмом «ZX0».

Вот так выглядит половина сжатой и закодированной «Элиты», половина, потому что из-за ограничений файловой системы она разбивается на 2 файла

Добавлено позже: один из читателей предложил вариант хранить программу в бинарном виде. Я такой вариант отбросил в самом начале, потому что мне больше нравилась идея всем управлять из текстового файла терминала, кроме того по расчётам тогда получалось, что в один файл всё равно всё не уместится.

Но я тогда не учитывал сжатие, плюс сама «Элита» была больше, я потратил немало токенов, чтобы её ускорить (первые версии рисовали экран секундами), а по пути она ещё и меньше стала. В общем, эту идею точно надо было рассмотреть.

В итоге, от команд  ztart и zin я избавился в пользу одной команды load, которая загружает сжатый заранее бинарный образ.