Архитектура компьютера→Троичная система кодирования символов
Стандарт кодирования символов, должен позволять представлять знаки всех письменных языков, быть компактным и расширяемым.
Alexander Obukhov, Тринари,
Мнения
001 Так как фиксированное значение количества разрядов не позволяет получить расширяемость и компактность, следует обратить внимание на системы с переменным количеством разрядов на символ.
Подобная система применяется в системе кодирования UTF-8.002 В http://trinary.ru/forum/view/5/17 была предложена идея чтобы количество разрядов на символ определялось как натуральное число закодированное вместо символа, если первый разряд не 0,
что позволяет кодировать (если принимать за трайт 6 трит) до (3^6)^(3^5) = 4,4*10^695 символов, что действительно очень много.003 Другой вариант:
http://en.wikipedia.org/wiki/UTF-8
когда часть разрядов первого байта указывает на общее количество байтов на символ, а оставшаяся часть дополняет разряды последующих байтов в определении кода символа.
В UTF-8:
0xxxxxxx
110xxxxx 10xxxxxx
1110xxxx 10xxxxxx 10xxxxxx
11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
Вариант для троичной системы:
0xxxxx
++xxxx -xxxxx
+-xxxx -xxxxx
+0+xxx -xxxxx -xxxxx
+0-xxx -xxxxx -xxxxx
+00+xx -xxxxx -xxxxx -xxxxx
+00-xx -xxxxx -xxxxx -xxxxx
+000+x -xxxxx -xxxxx -xxxxx -xxxxx
+000-x -xxxxx -xxxxx -xxxxx -xxxxx
+0000+ -xxxxx -xxxxx -xxxxx -xxxxx -xxxxx
+0000- -xxxxx -xxxxx -xxxxx -xxxxx -xxxxx
+00000 -xxxxx -xxxxx -xxxxx -xxxxx -xxxxx
Что позволяет закодировать:
3 * (3^25) + 2 * (3^21) + 2 * (3^17) + 2 * (3^13) + 2 * (3^9) + 3^5 = 2,5 * 10^12
004 В качестве обобщения системы, предложенной мною в В http://trinary.ru/forum/view/5/17 могу указать такой способ:
1. Для кодировки символа можно использовать столько трайт, сколько надо
2. Символы отделять друг от друга нулевым трайтом (комбинация трайт ..., sym1, 0, 0, 0, sym2, ... таким образом будет означать последовательность символов sym1, '\\0' (нулевой трайт), sym2)
Вообще эта тема касается не только троичного кодирования, но и двоичного (и любого другого)
Одна проблема: неудобно произвольное чтение символов: придется читать последовательно, но это проблема всех систем с переменной длиной элемента005 Если я правильно понял, то чтобы получить 1 символ нужно прочитать символы между нулевыми трайтами. С одной стороны это ведь слишком расточительно ведь минимальная длина одного символа получается всегда минимум 2 трайта. С другой стороны зачем безграничная длина символа? В том же unicode возможно лишь закодировать ~4*10^9 символов.
А что всё таки думаете про предложенную выше систему кодирования?
Ведь она более эффективна: прочитав трайт сразу ясно что это либо одиночный символ, либо многотрайтовый, либо продолжение предыдущего.
Также можно иметь ввиду что кодировка с постоянной длиной символа не такая уж и плохая всё таки.
Ведь передачу данных можно осуществлять в сжатом виде.
Хотя 3 трайтов вроде маловато, а четыре уже слишком :)006 Если коротко, то все зависит от поставленной задачи. Если нужно хранить большие объемы данных, то можно воспользоваться вариантом, предложенным мною в http://trinary.ru/forum/view/5/17. При обработке текстовой строке удобнее разворачивать ее так, что длина всех символов была одинаковой, чтобы иметь возможность чтения произвольного символа, не перелопачиваю все предыдущие.
Насчет разделения нулевыми трайтами: я посчитал это выгодным, поскольку элементарным сравнением типа if(k[i]) можно определеить границы символов. В противном случае нужно залазить внутрь трайта и операциями тритового сдвига (типа << и >>) рассматривать значения первых тритов. ИМХО, это работает медленнее.
То есть я предлагают посмотреть такие варианты:
1. При обработке разворачивать код так, чтобы все смволы имели одинаковыую длину (эта длина будет равна длина символа, занимающего больше все трайт), но мне кажется, что в 80% случаев дело ограничится 1 трайтом, а еще в 8% - 2 трайтами
2. Разделять симолы нулевыми трайтами (здест можно совершать обход даже в обратном порядке)
3. Использовать предложенный вариант (по аналогии с UTF-8)
Спорить здесь, я думаю, не имеет смысла. Нужно все рассчитать математически, зная время выполнения соответствующих операций или ставить эксперименты (хотя бы на двоичной системе)
Кстати, схемы можно комбинировать. Если у нас используются символы только русской и английской кодировок (думаю, в 2 трайта мы уложимся), но в программе понадобятся символы для шахматных фигур (допустим они 6-трайтовые), то кодировку развернем до 2 трайтов, а для шахматных символов вставим указатели вместо самих значений, а сами значения будем хранить отдельно (все это я имел в виду для ОЗУ)
007 Хочу поднять одну проблему принципов построения кодовой таблицы, которая не касается ни размера, ни базы, на которой она реализован (двоичная, троичная или какая другая): управляющие символы.
В прародительнице многих современных систем кодирования было много различных управляющих символов (http://ru.wikipedia.org/wiki/Ascii), но потом все равно приходилось добавлять новые. Я предлагаю другой подход:
Рассмотреть все современные управляющие символы и разбить их условно на две группы: сигналы для обмена сообщениями и символы управления текстом. Первую группу прдставляют различные "замена", "отмена", "стереть последний символ", "конец страницы", "разделитель" и прочие. Ко второй группе относятся "конец строки", "перевод строки" (но не "возврат каретки"), "табуляция" (пожалуй и все).
Сигналы для обмена сообщениями, на мой взгляд, не стоит включать в кодовую таблицу, поскольку они устарели, сейчас используются форматы файлов, управления устройствами, сетевые протоколы и прочее.
Символы управления текстом нужны например для хранения текстовых файлов (хотя и хдесь можно обойтись символом конца строки '\\0'). Можно ограничиться набором стандарта POSIX ( \\0, \\a, \\b, \\t, \
, \\v, \\l, \\r), хотя нет необходимости, например, в \\a
Мои доводы такие:
1. Уменьшить область применения зловредных ESCAPE-последовательностей. Зачем преобразовывать строку к страшному формату для передачи, чтобы потом обратно ее разбирать. если не верите, наберите в google запрос русскими буквами, нажмите ПОИСК и увидите в каком страшном виде передается эта строка параметра запроса
2. Текстовые строки предназначены для хранения ТЕКСТОВОЙ информации, то есть ОТОБРАЖАЕМЫХ СИМВОЛОВ, а управляющие символы типа "стереть последний" относятся к КОМАНДАМ и в общем случае представляют собой ДВОИЧНЫЕ ДАННЫЕ. Я не вижу смысла передавать двоичные (троичные) данные в виде текстовой строки.
3. Если кому-то сильно хочется вставить управляющие символы, то можно в кодовую таблицу нам добавить один-единственный управляющий символ, обозначающий что-то типа "Этот символ не является отображаемым и дальше по твоей логике, господин программист, должны следовать придуманные тобой команды, зачем-то вставленные в текстовую строку. Будь любезен не забыть перейти обратно в тестовый режим". В качестве этого символа вполне может работать символ конца строки '\\0' (а если использовать не его, то дело усложняется).
Этого единственного символа должно хватить для возможности вставки как фрагментов текста в двоичные данные, так и двоичных данных в текст.
Примером данных внутри текста может служить HTML-редактор. Основное содержимое файла - текст. Тэги сейчас вставляются символами < и >, который можно вполне заменить на наш управляющий символ. Для печати угловых скобок, входящих в текст можно использовать клавишы "<" и ">" соответственно. При нажатии например Ctrl+< в HTML-редакторе будет печататься < или > соответсвенно (как признак тэга). Сами тэги при этом надо будет как-то визуально подсвечивать. И не надо использовать всякие там "<" замещающие скобку как символ текста
Примером текста внутри данных может служить редактор кода программ (например, C++). Мы набираем код, а для ввода текстовой строки типа char k[]="qwerty" вместо " используем наш символ. Само qwerty подсвечивается и нет проблем в использовании " внутри текстовой строки.
Если что-то непонятно или по какому-то пункту интересен более подробное описание, оставляйте свой коммент, попытаюсь ответить008 Предлагаю использовать следующую схему:
x - трит
xxx - трет (по аналогии с октетом/полубайтом)
xxxxxxxxx - трайт
в этом случае, кодовая таблица может быть страничной и состоять из переменного числа трайтов. В примитивном случае это будет 1 трайт (первая страница, мощности которой хватит на 19683 символа, как я понимаю это все национальные кодировки, за исключением китайской упрощённой, для которой использовать вторую и последующие страницы.
код +++++++++ будет означать что следует выбирать символ из следующей страницы. Например:
0000000++ +++++++++ 0001-+000 +++++++++ +++++++++ 00000+12+
означает что символ 0000000++ выбирается из первой кодовой страницы, символ 0001-+000 - из второй кодовой страницы, а 00000+12+ из третьей кодовой страницы.009 Идея хорошая. Основное ее достоинство, IMHO, в том, что все страницы одинакового размера (у вас точнее не 19683, а 19682, так как +++++++++ рарезервирован). Это очень удобно еще в том плане, что в некоторых случаях можно использовать не все страницы, а только некоторые. Например надо использовать только символы шахматных фигур (предположим, они на 25-ой странице). Можно как-то договориться, что мы используем ТОЛЬКО 25-ую страницу (чтобы не писать 24 раза по +++++++++)
012 На самом деле я сомневаюсь что дойдёт до 3-ей страницы. Но можно зарезервировать два варианта:
+++++++++ - переключиться для следующего символа на следующую страницу
++++++++0 <номер страницы> - Переключиться для следующего символа на указанную страницу
010 Предлагаю использовать разные системы кодирования для разных ситуаций, а именно:
1. при обработке данных использовать код постоянной длины (удобен доступ к произвольному символу)
2. при хранении данных использовать код переменной длины (компактен, так как занимает мало места)
Таким образом, предлагаю использовать терминологию:
1. Переменная длина - постоянная длина: РАЗВОРАЧИВАНИЕ
2. Постоянная длина - переменная длина: СВОРАЧИВАНИЕ
Вообще говоря, постоянная длина может быть условно-постоянной. В разных странах, в разных программах, для разных текстовых строк можно строку из файла разворачивать до такой длины, которая небходима. Например, в США достаточно разворачивать строку до 1 трайта, в России - до 2-х, в шахматной программе - до 7-ми (например).
Как я понимаю, основной вопрос дискуссии: как при переменной длине указывать, сколько трайт отводится на данный символ. Стоит обобщить все варианты:
1. По аналогии с UTF-8 (en.wikipedia.org/wiki/UTF-8). Однако, у нас, к счастью, нет необходимости в обратной совместимости, поэтому можно использовать троичный аналог такой схемы:
0xxxxx
10xxxx xxxxxx
110xxx xxxxxx xxxxxx
1110xx xxxxxx xxxxxx xxxxxx
11110x xxxxxx xxxxxx xxxxxx xxxxxx
111110 xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx
111111 0xxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx
111111 10xxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx
Если я ничего не перепутал и можно серию единиц не ограничивать одним байтом (трайтом), то длина символа не ограничена
2. Первый трайт - целое число, обозначающее количество трайтов для символа. Длина сивола ограничена числом трит в трайте, хотя возможны варианты (например, максимальное число может обозначать, что для опередления длины использован еще и следующий трайт)
3. Отделять символы нулевыми трайтами (для неограниченной длины - самый подходящий вариант, так как элементарной проверкой на ноль можно отделять символы), но не самый экономичный с точки зрения размера строки.011 Предлагаю обобщить твой вариант до более простого, использовать код постоянной длины, а там где это уместно хранить текст упакованным :)
015 Пожалуй действительно лучше оперировать с кодами символов постоянной длины. Главное и решающее преимущество - возможность произвольного доступа. Сворачивать в коды переменной дины надо лишь при долговременном хранении или для передачи по низкоскоростным каналам связи.
Лучше наверно использовать условно-постоянную длину. Например, мы договорились использовать в какой-то задаче 3 трайта на символ. Если символ закодирован больше чем 3 трайтами, то вместо кода исмвола указывается адрес в памяти, где этот код расположен (некая куча, возможно в конце строки).
Величину условно-постоянной длины можно задавать на аппаратном уровне, уровне ОС, региональных настроек ОС, на уровне программы или даже на уровне отдельной строки.
Я стараюсь предложить систему, которая позволяла бы неограниченно наращивать кодовую таблицу, ибо как показала история, сколько байт на символ не отводи, все равно когда-нибудь не хватит
013 Какие существуют препятствия для организации набора символов в виде дерева ? И при чтении данных анализировать скажем каждую тройку тритов, в которой каждый отдельный трит обозначает направление перемещения по текущей ветки дерева: -1 - налево, 0 - прямо, +1 - направо. Таким образом мы сможем организовать не просто некий алфавит, а даже кодировать наиболее употребительные фрагменты и короткие слова языков.
014 Теряется скорость работы
016 Вот идея про тройки тритов интересна,
потому, как до сих пор не определено сколько тритов использовать для кодирования символов, а 3-мя тритами можно описать и трайт и 9 тритов, т.е. что хочется сказать, что можно попробовать по манипулировать длиной именно в числах кратным 3: 3, 6, 9, 12, 15...017 А можно поподробнее про систему кодирования в виде дерева,
единственно пока что подумалось,
что как бы мы не задавали кодирование, в конечном получается так называемый абсолютный адрес, т.е. номер, который соответствует конкретному символу.
018 Бороздя просторы интернета наткнулась на следующее:
Коды бывают постоянной и переменной длины. Коды переменной длины применяются в технике довольно редко. Исключением лишь является код Морзе.
Азбука Морзе – это троичный код с набором знаков: точка, тире, пауза. Паузу необходимо использовать в качестве разделителя между буквами и словами, так как длина кода непостоянна. Если бы длина кода была постоянной, то расположение символов можно было устанавливать при помощи отсчета. В этом случае пауза не нужна. Сообщение будет раскодировано однозначно.
Тут сам код:
http://www.cultinfo.ru/fulltext/1/001/010/001/271200971.jpg019 Примерно это я предлагал сообщением выше.
020 Итак, насколько я понимаю, останавливаемся на (условно-)постояной длине кода при обработке и переменной по типу unicode при долговременном хранении.
Я специально указал "условно-постояная". Целесообразно некий абстрактный тип "Символ" языка программирования делать настроиваемой длины (автоматическая настройка при записи данных в переменную и ручная настройка для оптимизации скорости работы)
021 Так как либо скорость, либо размер — следует использовать оба метода.
022 А что насчёт специфики троичности в обоих контекстах?
+ — большой регистр
- — маленький
0 — спецсимвол
:)023 Длина кода постоянной длины?
64 бита = 18446744073709551616
36 трит = 150094635296999121
36 = 6*6 — 6 трайт
36 трит?
024 Предлагается использование системы кодирования по аналогии с UTF-8:
0xxxxx
+0xxxx xxxxxx
++0xxx xxxxxx xxxxxx
+++0xx xxxxxx xxxxxx xxxxxx
++++0x xxxxxx xxxxxx xxxxxx xxxxxx
+++++0 xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx
++++++ 0xxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx
++++++ +0xxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx
Количество трит, которые реально используются для кодирования при том или ином количестве трайт: 5n (n - число трайт).
Таким образом получается:
n=1 5 трит 5^3=243 символа
n=2 10 трит 10^3=59 049 символов
n=3 15 трит 15^3=14 348 907 символов
n=4 20 трит 20^3=3 486 784 401 символов
n=5 25 трит 25^3=847 288 609 443 символов
n=6 30 трит 30^3=205 891 132 094 649 символов
n=6 35 трит 35^3=50 031 545 098 999 700 символов
и т. д.
Количество трайт, используемых при кодировании данного символа: число плюсов до первого нуля, увеличенное на 1
Недостаток данной системы: Не видно, является ли произвольный трайт началом символа или продолжением предыдущего. Для этого можно использовать модификацию данной системы:
+0xxxx
++0xxx 0xxxxx
+++0xx 0xxxxx 0xxxxx
++++0x 0xxxxx 0xxxxx 0xxxxx
+++++0 0xxxxx 0xxxxx 0xxxxx 0xxxxx
++++++ -0xxxx 0xxxxx 0xxxxx 0xxxxx 0xxxxx 0xxxxx
++++++ -+0xxx 0xxxxx 0xxxxx 0xxxxx 0xxxxx 0xxxxx 0xxxxx
++++++ -++0xx 0xxxxx 0xxxxx 0xxxxx 0xxxxx 0xxxxx 0xxxxx 0xxxxx
++++++ -+++0x 0xxxxx 0xxxxx 0xxxxx 0xxxxx 0xxxxx 0xxxxx 0xxxxx 0xxxxx
++++++ -++++0 0xxxxx 0xxxxx 0xxxxx 0xxxxx 0xxxxx 0xxxxx 0xxxxx 0xxxxx 0xxxxx
++++++ -+++++ -0xxxx 0xxxxx 0xxxxx 0xxxxx 0xxxxx 0xxxxx 0xxxxx 0xxxxx 0xxxxx 0xxxxx 0xxxxx
++++++ -+++++ -+0xxx 0xxxxx 0xxxxx 0xxxxx 0xxxxx 0xxxxx 0xxxxx 0xxxxx 0xxxxx 0xxxxx 0xxxxx 0xxxxx
++++++ -+++++ -++0xx 0xxxxx 0xxxxx 0xxxxx 0xxxxx 0xxxxx 0xxxxx 0xxxxx 0xxxxx 0xxxxx 0xxxxx 0xxxxx 0xxxxx
Здесь признаки таковы:
"0" - трайт, продолжающий предыдущий символ
"-" - трайт, продолжающий предыдущий символ (идет указание количества трайт)
"+" - первый трайт символа
Здесь количество трит, которые реально используются для кодирования при том или ином количестве трайт: 4n (причем не используются значения n, дающие 1 в остатке при делении на 5: 6 ,11, 16, 21)
n=1 4 трита 4^3=81 символа
n=2 8 трит 8^3=6 561 символов
n=3 12 трит 12^3=531 441 символов
n=4 16 трит 16^3=43 046 721 символов
n=5 20 трит 20^3=3 486 784 401 символов
n=6 не используется
n=7 28 трит 28^3=22 876 792 454 961 символов
и т. д.
025 Прошу замечания и опровержения
026 Мне кажется что в модифицированной системе можно немного эффективнее кодировать префикс (часть до нуля).
027 А какие +/- по сравнению с предложенной ранее:
0xxxxx
++xxxx -xxxxx
+-xxxx -xxxxx
+0+xxx -xxxxx -xxxxx
+0-xxx -xxxxx -xxxxx
+00+xx -xxxxx -xxxxx -xxxxx
+00-xx -xxxxx -xxxxx -xxxxx
+000+x -xxxxx -xxxxx -xxxxx -xxxxx
+000-x -xxxxx -xxxxx -xxxxx -xxxxx
+0000+ -xxxxx -xxxxx -xxxxx -xxxxx -xxxxx
+0000- -xxxxx -xxxxx -xxxxx -xxxxx -xxxxx
+00000 -xxxxx -xxxxx -xxxxx -xxxxx -xxxxx028 Неграниченное число символов
029 А оно надо?
Шрифт тоже будет неограниченной длины — неограниченного размера файла?030 Шрифт не обязан поддерживать ВСЕ символы
031 А как визуализировать тогда все эти символы?
032 Надо обсуждать формат шрифта :)
033 Не все современные шрифты поддерживают все символы Юникода, заменяя их часто всякой ерундой
?????????????????????????????????????????????????????????????????????????????????034 Правильно — не все,
а что из этого следует?
Что даже для текущего кол-ва символов нахватает ресурсов что бы создать шрифт. А ведь ещё существуют варианты начертания, основных таких только 4, это уже получается что нужно в 4 раза больше рисовать символов.037 Рисовать ничего не потребуется, необходимо лишь импортировать уже существующие глифы в нужном порядке и сформировать таблицу-описатель.
038 Это только для текущих существующих, речь идёт о том что кодировка имеет бесконечное кол-во символов
039 Современный Юникод содержит (теоретический максимум) что-то около 2^20+2^16 символов, но естественно далеко не каждый мобильный телефон имеет соответствующую таблицу с начертанием шрифтов.Главное, что он МОЖЕТ СОДЕРЖАТЬ эту таблицу, если возникнет необходимость.
040 Конечно поддержка кодирования UNICODE и набор шрифтов две независимые вещи.
Более того в самом UNICODE до сих пор существуют зарезервированные области, для которых не определены значения, но это никак не мешает использовать UNICODE повсеместно.
036 Для начала бы систему кодирования разработать
035 Как любая универсальная система имеет недостаток который заключается в её универсальности :)
041 Похоже, принципиальных возражений нет
042 По скорости данная система уступает UTF-8 подобной и тем более системе с фиксированным количеством трит.
043 А ещё есть система кодирования символов для моего компьютера 3niti :)
http://ternary.info/modules/newbb/viewtopic.php?topic_id=58&forum=7&viewmode=flat&order=ASC&start=11044 Да, действительно, есть такой способ кодирования основанный на таблицах кодов, которые переключаются спецсимволами.
Такая система использовалась ещё в первой МЦВМ «Сетунь».
048 Проблема в том, что фактически мы эти первые "сигнальные" триты/трайты в такой схеме пускаем коту под хвост. Особенно явно видно это становится как раз в модификации, с использованием одного трита в трайте как признака "продолжение предыдущего символа". Как только мы используем такого рода признак в каждом трайте, явное указание длины символа в его начале становится избыточным. Ведь можно просто считать, что символ продолжается до тех пор, пока он не закончится (т.е. пока не встретится трайт, не являющийся продолжением, т.е. пока не начнётся новый символ).
Например (если мы используем 0xxxxx для начала символа, и остальные 2 варианта для продолжения):
0xxxxx n=1 5 трит 3^5 = 243 символа
0xxxxx [+-]xxxxx n=2 10 трит + 1 бит = 3^10 * 2 = 59049 * 2 = 118098 символов
0xxxxx [+-]xxxxx [+-]xxxxx n=3 15 трит + 2 бит = 3^15 * 2^2 = 14348907 * 4 = 57395628 символов
и т.д.
(Возможен вариант наоборот, когда 0xxxxx обозначает последний трайт, а не первый. Принципиально ничего не меняется).
Как видно, в этом варианте только на первый (или последний) трайт приходится 5 трит "полезного содержимого", тогда как каждый из трайтов продолжения несёт по 5 трит+1 бит. Поэтому на уровне одного трайта имеем всё те же 243 символа, но вот дальше каждый трайт увеличивает вдвое количество символов по сравнению с вашей первой схемой. (Можно поступить и наоборот, и использовать одно значение старшего трита для "продолжения", и два других для начала или конца, тогда однотрайтный символ расширяется вдвое до 486 значений, двухтрайтный остаётся таким же по ёмкости, а вот на более длинных символах мы, наоборот, проигрываем).
И - при этом именно что для произвольного трайта сразу видно, начинает/заканчивает ли он новый символ или является продолжением. Т.е. попав в буфер по произвольному адресу, мы можем начать читать сразу начиная с символа по этому адресу (с передвижением левее или правее, если изначально попали не на начало символа, это уже на усмотрение программиста, куда в этом случае перемещаться, или вовсе выдать ошибку), а не прочитывать всю строку с начала. Соответственно и возможности по последовательному приёму данных не с начала или с перерывом связи, без специальных мер по синхронизации.
Со второй схемой с её 4 тритами на трайт - и вовсе нечего сравнивать, т.к. она чудовищно избыточна - параллельно кодируется и длина символа в его начале, а потом - примерно с такими же затратами - метятся символы продолжения. И при этом непонятен практический смысл этого дублирования. Помеченность трайтов продолжения уже решает все задачи. Более того, даже если очень хочется обозначать длину символа, то при наличии однозначной метки продолжения кодировать длину можно куда экономичнее. Т.е. используя для этого хотя бы двоичную систему (+/- - если 0 используется по-прежнему для обозначения конца "кода длины"), а не унарную (число плюсиков). Это "двоичники" не могут воспользоваться двоичной системой для неизвестного заранее числа разрядов, т.к. у них и так всего 2 цифры, и вынужденно оказываются в плену совсем уж неэкономичной унарной. А если у нас есть третья цифра, так что бы ей не воспользоваться для двоичного кодирования длины символа. Пусть и "некошерно" в троичном компьютере, однако хоть сколько-то экономичнее, начиная с 3 трайт, и особенно - для наиболее длинных символов:
+0xxxx : 4 трита/1 трайт
+-0xxx 0xxxxx : 8 трит/2 трайта
++0xxx 0xxxxx 0xxxxx : 13 трит/3 трайта
+--0xx 0xxxxx 0xxxxx 0xxxxx : 17 трит/4 трайта
+-+0xx 0xxxxx 0xxxxx 0xxxxx 0xxxxx : 22 трита/5 трайтов
++-0xx 0xxxxx 0xxxxx 0xxxxx 0xxxxx 0xxxxx : 27 трит/6 трайтов
+++0xx 0xxxxx 0xxxxx 0xxxxx 0xxxxx 0xxxxx 0xxxxx : 32 трит/7 трайтов
и т.д.
... например
+--+-+ --+0хх (здесь идут 147 трайтов вида 0xxxxx, не буду их выписывать :) ): 737 трит/149 трайт
- оно вообще кому-нибудь практически надо, или как, если это всего лишь текстовые символы, а не что ещё? Если больше одного трайта на указание длины не использовать - то можно либо отдать "-" для трайтов продолжения, опять же добавив им тем самым дополнительный бит. Или же отдать "-" на указание длины (что ещё немножко экономит место на указание длины, оставляя больше для значащих разрядов).
Хотя, повторюсь, я считаю вообще указание длины символа как таковое баловством и излишеством, когда в каждом трайте уже есть метка начала или конца символа против "продолжения".049 "Хотя, повторюсь, я считаю вообще указание длины символа как таковое баловством и излишеством, когда в каждом трайте уже есть метка начала или конца символа против "продолжения".
Поддерживаю. Я категорически против явного указания длины кодируемого символа. Кроме того, во всех предложенных системах кодирования мне не нравится очевидная потеря достаточно большого количества разрядов в последнем трайте. Так же я не представляю себе текст, который содержит все возможные символы, за исключением документа описывающего этот набор символов. Поэтому я все ещё считаю что кодировать надо только тот набор символов, который есть в документе, применяя префиксный код без разделителя, а не сохранять указатели переменной длинны. Хорошо понимаю что работать с такими данными можно будет только последовательно, но ни кто не запрещает производить преобразование в более удобное представление при чтении и сохранении данных из файла.051 > Кроме того, во всех предложенных системах кодирования мне не нравится очевидная потеря достаточно большого количества разрядов в последнем трайте.
А в чём эта потеря заключается? Кроме одного разряда "метки продолжения" вроде бы все разряды могут быть использованы по делу.
Другой вопрос, что юникодный подход сам по себе довольно дикий и неэкономичный, по крайней мере, для языков, использующих алфавит или слоговое письмо. Т.е. если вдруг тебе не повезло, и твой язык разместили в области n-трайтных (n-байтных в двоичном варианте) символов, то приходится тупо выписывать каждый раз (при каждом символе) кучу разрядов для обозначения того, что текст, блин, до сих пор продолжает оставаться на всё том же языке, а не перескочил внезапно на другой язык, или на цифры, или на какую псевдографику или международные пиктограммы. Несмотря на то, что в твоём языке, допустим, всего-то 60 букв в алфавите, на которые вообще отлично хватает 4 трит/6 бит. Аналогично и со строчными/прописными буквами: в том же самом ASCII, а равно и в Юникоде, фактически тратится лишний 1 бит информации для указания того, что мы опять, в который раз (ну надо же, какое редкое совпадение!), не решили внезапно влепить прописную букву где-то в середине предложения или слова, или, наоборот, строчную где-то в середине документа или строчки, целиком написанной прописными. Вот наверняка, если бы только в распоряжении авторов ASCII было чуть больше бит, чем им было дано, а печатающие устройства чуть более гибкими, они бы обязательно этим воспользовались, и все, как минимум, графически отображаемые символы продублировали четырёхкратно: отдельный символ для обычного начертания, отдельный для полужирного, третий для курсивного, а четвёртый для курсивного полужирного. А там дальше и подчёркнутый, и надчёркнутый, и зачёркнутый, и нижний индекс, и верхний индекс... Короче, на каждое сочетание непременно нужен был бы отдельный бит и соотв. отдельный символ. Хорошо, что больше 7 бит им не дали. Но плохо, что дали целых 7. Это оказалось слишком много. Видимо, надо было больше 6 на символ никак не давать. А то, может, и 5 - хоть это и сурово, но хорошо бы защитило от странных поползновений. И, глядишь, никакого юникода изобретать бы не пришлось, ибо универсальное кодирование разноязычных символов пришло бы само собой в самом естественном и удобном виде.
> Хорошо понимаю что работать с такими данными можно будет только последовательно, но ни кто не запрещает производить преобразование в более удобное представление при чтении и сохранении данных из файла.
Это так только в случае, если файл готовенький (и без ошибок) лежит на диске, и в любой момент доступен для чтения с начала. И если это чтение с начала не будет непозволительно долгим процессом. Собственно, в этих случаях и сейчас никто не мешает воспользоваться форматами сжатия общего назначения, и многие вменяемые программы ими пользуются при посредстве соответствующих библиотек. Во всех остальных случаях исключительно последовательная обработка оказывается проклятием. Например, нам недоступно начало текста (мы включили радиоприёмник позже начала его передачи), или кусок в середине выпал. Может быть, он будет передан позже повторно, или просто задерживается - но пока мы не можем отобразить ничего вообще. Для исключения таких ситуаций неизбежно придётся вводить-таки целый символ-синхронизатор, и вводить строгое правило, что оный символ должен включаться в текст не реже n значащих символов, независимо ни от чего, или не реже n секунд(миллисекунд) времени и т.п.
Кстати, у меня на работе до сих пор есть один старый комп, 1999 года, который когда-то в 2000-х начал странным образом глючить (причём это на аппаратном уровне), так что приходящие из инета через сетевую карту данные стали приходить со случайными точечными ошибками. В результате получилось, что, например, скачать и поставить какую-либо программу больше единиц килобайт было решительно невозможно, равно как и что-либо поставленное обновлять по сети (а в качестве бонуса - разумеется, этот комп оказался почти абсолютно неуязвим для вирусов/троянов/червей, пытающихся пролезть из сети), а картинки скачивались нормально только в верхней части, где-то в середине же обязательно случались несколько ошибок, и картинка корёжилась. В то же время всё это почти не мешало бродить по "текстовой" части веб-страниц, и даже самому писать что-то на форумах. Потому что ошибки обычно попадали в какие-то случайные буквы, что не приводило к критическим проблемам, а чаще всего просто оставалось незамеченными. И лишь изредка ошибка попадала, например, в какой-то тег, разрушая его, и серьёзно ломала всю разметку страницы. Тем не менее, такая текстовая работа оставалась вполне возможной и даже не безумно дискомфортной на весьма глючном оборудовании. Если только не встречался сайт, который настаивал на выдаче страницы в сжатом виде - вот тогда гарантированно осмысленный текст обрывался на середине, превращаясь дальше в абракадабру. НЯП, то, что Вы сейчас предлагаете, означало бы, что не было бы никакой возможности работать на таком оборудовании, т.к. с точки зрения устойчивости к ошибкам (в смысле сохранения читаемости человеком текста на человеческом языке) оно было бы подобно сжатому тексту.
Кстати, к слову, забавно, что это не был глюк сетевой карты - сами карты несколько раз меняли, и все, заведомо исправные (и оставшиеся исправными и после) сетевые карты работали с тем же результатом. Это не был и глюк операционной системы - замена одной винды на другую (одновременно с заменой собственно диска) ничего не меняла, и, как ни странно, не изменила даже установка линукса. В то же время, скажем, возможность установки программ из сети и вообще работы без ошибок в принципе была - т.к., например, через вай-фай хрень, включаемую по USB, всё шло без ошибок. Удивительно, почему так плющит на том компе исключительно сетевые карты, причём совершенно исправные...
045 Система кодирования основанная на таблицах кодов.
Суть метода заключается в наличии таблиц с одинаковыми ключами но разным набором символов.
Кодирование осуществляется в два этапа:
1. С помощью специальных кодов определяется текущая таблица символов.
2. Идёт запись символов из текущей таблицы указанием соответствующих ключей.
При необходимости указания символов из другой таблицы задаётся соответствующий спецкод который осуществляет смену текущей таблицы на новую, после которого все коды будут соответствуют символам из новой таблицы.
Пример работы системы кодирования в МЦВМ «Сетунь»:
++0 +0- +0+ 0++ ++- 0-+ ++0 -0+ 0+0
Коды ++0 и ++- являются спецкодами смены таблицы символов «Буквенный регистр» и «Цифровой регистр» соответственно.
Так код +-0 в буквенном регистре соответствует символу «А», а в цифровом символу «6», т.е.
++0 +-0 выведет «А», в то время как ++- +-0 выведет «6»046 К плюсам такого метода можно отнести компактность кода: имея всего коды 3-х тритной длины можно закодировать до 182 символов имея 13 таблиц по 14 символов.
Минусы: невозможность однозначной идентификации произвольного символа (необходимо знать текущую установленную таблицу), как следствие, в случае потери информации о установке текущей таблицы, все символы, которые будут идти после, вплоть до очередного спецкода, будет невозможно интерпретировать.
Что касается скорости работы такой системы то она не уступает по скорости системам с одной таблицей с фиксированной длиной кодов.047 именно поэтому я предполагал, что символ перевода строки сбрасывает шрифт и раскладку - т.е. если была потеря или искажение данных, по пострадают только абзацы, непосредственно примыкающие к области искажения
050 Мне кажется в некоторых областях необходимость знания контекста и возможность утраты смысла в интерпретируемых данных при потере или искажении маркера может считаться достоинством.
История сообщений
22 января
8 января
2009
21 октября
15 октября
12 октября
11 октября
10 октября
9 октября
- Бармалейкин
- Alexander Obukhov
- Alexander Obukhov
- Alexander Obukhov
- Serg
- Бармалейкин
- Alexander Obukhov
- Serg