Комментарии 100
Система кодирования TREX разработанаКем разработана?
Предлагаемая система кодирования позволитКем предлагаемая?
Троичные компьютеры придумали давно. Подход интересный. Но хотелось бы знать авторов или ссылки на публикации.
Предлагаемая тоже мной :-)
И это, собственно, и есть публикация.
На самом деле, просто это (на мой взгляд) неудачный канцелярит. Какую фразу вы предпочтёте?
- «Система кодирования TREX разработана для компактного отображения симметричной ...»
- «Я предлагаю систему кодирования для компактного отображения симметричной ...»
В реальности есть цифровые системы исчисления с фиксированным шагом приращения (x++;), и аналоговая (напряжение и фазовые свойства волны) — с плавающей точностью.
Вся разница в ограничениях применения оператора "++".
В цифровых системах всего два варианта считаются стандартом: двоичная и десятичная. Изобретать тут особо нечего, потому как даже после изобретения — придётся использовать десятичную систему для доказательств и объяснений, что довольно глупо.
А вот аналоговые системы исчисления — не паханое поле.
Здесь уже иная математика, другие законы и правила. Но и возможностей на голову выше.
Приколы начинаются с того что аналоговый вариант просто невозможно записать на бумаге с абсолютной точностью. Так-же событие равенства в такой системе будет бесконечно редким событием.
Можно играться с уровнем напряжения — это достаточно легко, но накладывает несколько фундаментальных ограничений, отчего математические возможности явно беднеют.
Гораздо интереснее играться с фазой сигнала фиксированной амплитуды. В этом случае доступна вся математика без ограничений и нарушений баланса энергий.
Вот оно не паханое поле.
TREX.
Как я понимаю, TR это Trifonov.
Что тогда EX? Exchange?
А чем вам идея специально разработанных симметричных символов не понравилась? Я как то тоже думал над тем как отображать троичные симметричные числа, но так далеко не зашёл, только трит "осилил". Для трита мне в качестве отправной точки понравилась цифра 7 0 и отзеркаленная 7, в идеале нужны совершенно новые глифы один для нуля и пара симметричных и так что бы и рукой писать легко и распознавать с минимальными ошибками. Ну а для трибла соответственно 4 пары симметричных глифов. Переиспользывать буквы или десятичные цифры так себе идея по-моему. Ну и раз уж пошла такая пьянка, то для письма слева на право старший разряд должен быть тадам тадам с право. А то как обычно у арабов цифры позаимствовали и даже относительное расположение разрядов взяли, а то что они с право на лево пишут как то забыли учесть.
Что касается создания специальных символов: троичные компьютеры на данный момент находятся в начале своего развития, они очень непривычны, и любая дополнительная новая сущность, как, например, спецсимволы, будет усложнять их разработку, внедрение и принятие техническим сообществом.
Таким образом этот ваш трекс должен заиметь удобные кодепойнты прежде всего, а уж как они будут сопоставляться с глифами — это не так уж и существенно. Ваша система годна, почему нет? Но лёгкой заменой шрифта можно получить другую систему, однако же кодепойнты не поменяются и это замечательно.
Более того, ваши группировки трекс-цифр тоже должны иметь кодепойнты, т.к. выводить трексы станет сильно удобнее. Аналогия с hex: «00», «AB» и т.д. т.е. байт должны кодироваться тоже одним кодепойнтом (их 256 штук) ибо это астрономически удобно, подумайте. Более того если сразу закешировать двойные глифы — снизится нагрузка на графическую подсистему и т.д. и т.п.
А вообще, все эти разработки на самом деле требуют колоссально всеобъемлющего подхода, и просто так с наскока вряд ли что-то хорошее получится.
Простите, вы вообще о чём? Вообще-то hex как раз использует два юникодных кодепоинта на байт, которые ничуть не являются уникальными и "мешаются" с цифрами и английскими буквами.
А как там hex будет отображаться на экране — забота того, кто его собрался отображать, а не создателя hex-представления.
Вообще-то hex как раз использует два юникодных кодепоинта на байтВаш кэп? А выше где то утверждается обратное? Выше написано что хекс-байт должен иметь кодепойнт. Но не два кодепойнта, это глупость. Т.е. легаси. Когда то это было актуально, ну потому что деваться было некуда, но не сейчас. Сейчас есть куда деваться.
которые ничуть не являются уникальными и «мешаются» с цифрами и английскими буквами.Не с английскими, а с латинскими, если что. Английских букв в юникоде нет и никогда не было. Так вот я всего лишь про то, что «на дворе» уже 21-год, но из произвольной строки написанной на испанском крайне проблематично выхватить хекс-цифры, я бы даже сказал бы ну очень проблематично, причём до такой степени, что иногда эта проблема вообще не решаема. Т.е. в десятичной системе выхватить цыферки не проблема, а шестнадцатеричные цыферки выхватить это тот ещё квест. Нормально же? Т.е. так и должно быть? Серьёзно? Это как испанский стыд. Строка на испанском есть, а стыдно мне. Так вот это всё я вовсе не вам пишу, что либо писать вам бесполезно, это очевидно чуть более чем полностью. Я это автору пишу. Что бы не наступал на легаси-грабли и сразу и всеобъемлюще подумал. Иначе получатся пабрякушки.
А как там hex будет отображаться на экране — забота того, кто его собрался отображатьЭто забота сочинителя стандарта. Если сочинитель не откровенно тупой, и ему не плевать на то как оно вообще будет реализовываться, то как раз таки и подумает над этим, прежде чем оно дойдёт до стандарта.
п.с.: Автор, эти трекс-цифры должны быть похожи на буквы, но ни в коем случае не должны быть ими. Нужен стандартный префикс со своим кодепойнтом на это дело, у вас его нет. Или вы хотите 120 префиксов как в хексе? И т.д. и т.п. вот потому то выше и написано:
А вообще, все эти разработки на самом деле требуют колоссально всеобъемлющего подхода, и просто так с наскока вряд ли что-то хорошее получится.
Статья написана о системе кодирования. Если она «пойдет в народ», то несомненно будет определен «стандартный префикс со своим кодепойнтом». А до момента признания этой системы кодирования, определение «стандартного префикса со своим кодепойнтом» как раз и будет той самой «абстракцией в вакууме», и поэтому меня пока не интересует.
А, вы к этому серьезно относитесь, я думал это фан статья. Не переживайте вы так, всем похер на троичные числа и уж тем более как они там визуализируются. К сожалению я обделён художественными навыками, а то бы точно нарисовал бы новые глифы для троичной системы, во первых это просто интересно, а во вторых фан и красиво.
Каждый специалист по компьютерам знает, насколько сложно работать с длинными последовательностями нулей и единиц.
Работать с «нулями» и «единицами» это обязанность процессора, а человек работает с программой и обычно фиолетово что в процессоре используется: биты, триты или еще чего.
определение знака числа — по регистру самой старшей цифры
А остальные знаки в разрядах игнорируются? Получается, в пустую теряется часть информации?
при сравнении двух чисел, как положительных, так и отрицательных, больше то число, у которого больше первая отличающаяся цифра, начиная со старшей значащей
Это правило действует для чисел любой системы счисления.
С троичной логикой то же самое. Но, поскольку троичные компьютеры находятся в самом начале своего развития, то до того момента пока на них будут портированы ЯВУ, придется работать именно с тритами и трайтами. И тут система TREX должна помочь.
По поводу определения знака числа: это удобный наглядный способ для программиста. Например, вы вычисляете показатель кислотности pH (который от 0 до 14, т.е. неотрицательный), но видите, что результат вычисления имеет старшую значащую цифру в нижнем регистре. Сразу понятно, что число отрицательное, значит в программе что-то пошло не так.
По поводу сравнения:
в дополнительном коде в HEX: FFh < 01h, хотя F(десятичное 15) > 0 (ноль)
Но, поскольку троичные компьютеры находятся в самом начале своего развития, то до того момента пока на них будут портированы ЯВУ, придется работать именно с тритами и трайтами.
Если бы это было нужно, то уже давно бы сделали. Видать, не судьба троичным компьютерам развиваться дальше зачатка.
в дополнительном коде в HEX: FFh < 01h, хотя F(десятичное 15) > 0 (ноль)
Почему FFh (255) < 01h (1)
Почему FFh (255) < 01h (1)
Потому что в дополнительном коде FFh — это -1, а не 255.
Эти "костыли" как раз и называются дополнительный код.
Но все эти ваши рассуждения нисколько не отменяют того факта, что FFh = -1 в дополнительном коде.
Но, поскольку троичные компьютеры находятся в самом начале своего развития, то до того момента пока на них будут портированы ЯВУ, придется работать именно с тритами и трайтами.
Это не так, уже с 60-х ведутся эксперименты, а воз и ныне там. Небольшая оптимальность 3-й системы счисления по сравнению с 2-й нивелируется большим количеством недостатков: сложностью аппаратной базы и программной (если попробуйте выразить дизъюнкцию и конъюнкцию с помощью единственной операции (функции Вебба), то ужаснетесь их сложностью), дороговизной. Это не говоря о том, что все привыкли к двоичной и переползать на троичную будет болезненно.
В общем я не верю, что системы на троичной логике когда-нибудь выйдут в продакшн, а значит ничего на них портировано не будет. Какие-нибудь оптические или квантовые наверняка более перспективны.
А эмуляция не понятно зачем нужна, если все зависит от железа.
А остальные знаки в разрядах игнорируются? Получается, в пустую теряется часть информации?
Они не игнорируются, они просто не влияют на знак числа. Почитайте как уравновешенные системы счисления работают.
А в чём преимущества троичной системы для вычислений перед двоичной? Я вот вижу одни недостатки.
Что касательно преимуществ троичной системы, то в Интернете очень много материала. Например:
Википедия. Троичный компьютер
А можете всё-таки словами объяснить, пожалуйста? В статье какие-то странные вычисления, основанные на том, что «складывать в столбик в троичной системе быстрее чем в двоичной» (меньше переносов). С одной стороны это правда, с другой стороны - а какова практическая польза с учётом того, что компьютеры оперируют в основном с числами фиксированной длины и на таких числах базовая арифметика и логика всегда выполняется за один такт? Получается, что надо ориентироваться не на скорость работы, а на число транзисторов необходимых для реализации логики (меньше транзисторов = дешевле и проще делать многоядерные процессоры). И вот про число транзисторов в статье ни слова.
А вообще сильно уменьшается количество проводников между разными блоками в вычислительном устройстве. Но есть куча других минусов, типа, как если тремя уровнями напряжения представлять логику, то при переходе из +1 в -1 происходит переход через третье состояние 0, что может быть нежелательным.
А те не держат постоянное напряжение, и поэтому невозможно передавать длинные последователь едениц например (3 — 5 и более).
Поэтому в езернете и прочих ISDN передают данные чередованием импульсов в плюс и в минус каждый раз меняя полярность и чередуя их с паузами, т.е. есть коды вида 0+-0-+00-+000+- и тд. что и есть третичная запись. Поэтому её на первых парах явно удобнее обрабатывать как есть, и не тратить два провода вместо одного на этапе обработки самой физики и может чуть дальше
И основной посыл статьи о том, что если вы работаете с троичной системой счисления, то может быть вам будет удобно использовать TREX потому что…
Призываю haqreu за экспертным мнением!
Собственно, и с шестнадцатиричным кодом сегодня уже практически нигде не работают руками…
github.com/ssloy/triador
Прикол в том, что даже в моём низкоуровневом ассемблере у меня нет напрямую тритов, программист работает с числами, записанными в десятичном виде. И мои эксперименты пришли ровно к тому же выводу, что озвучил GennPen: для программиста биты/триты вообще мало что меняют. Он работает с переменной, а как она там внутри в памяти представлена — очень редко когда нужно знать.
Неплохая идея.
Я вижу небольшой недостаток: чтобы "в уме" преобразовывать из восьмеричной системы в отдельные биты, требуется помнить таблицу из 8 значений (0 — 000, 1 — 001, ...), из шестнадцатиричной — 16 значений, а тут — целых 27. Хотя можно взять урезанный вариант из двух тритов, остановившись на D/d.
Двоичный процессор имел бы однобитовые регистры, двоичный компьютер и соответствующий язык программирования позволил бы адресовать один бит с помощью указателя, объявлять соответствующие однобитные переменные.
То есть у нас нет сегодня двоичных компьютеров, в основном все компьютеры 256-ричные. Процессоры может быть внутри работают с битами, но все наши языки программирования и соответствующее им железо работает с 256-ричными цифрами (называют их байтами). Это минимальная единица, которую можно адресовать в памяти, минимальный размер которым оперирует регистр процессора. Это и есть наши цифры.
</Режим зануды>
Касательно наименования для двадцатисемеричной системы счисления. HEX исходит к слову hexadecimal — шестнадцатеричная. То для двадцатисемеричной уже будет twentysemeral (использовал онлайн-переводчик). То отсюда должно быть TWE, TWS и так далее и тому подобное.
Использование различных регистров для кодирования интересное, но не слишком ли опасное? В плане опечатки регистров. Ведь нередки случаи опечатки при наборе текста, кода и так далее. Да и некоторые языки программирования нечувствительны к регистру.
То для двадцатисемеричной уже будет twentysemeral
"икосигептимальная" скорее, hexadecimal это все-таки с греческого.
По поводу многобайтового кодирования: изначально было заложено 1символ = 1 байт и многобайтовое кодирование это способ выкрутиться из ситуации, которая бы не возникла, если бы под кодирование символа изначально выделили больше байт (точно так же, как и с первым мегабайтом памяти в IBM PC).
По поводу названия: нужно же было как-то назвать :-)
По поводу регистров — да, это «засада», но обеспечивающая наглядность, что важно при начальном освоении троичной системы счисления. За какое время _начинающий_ программист осваивается с восьмиричной и шестнадцатиричной системами счисления? Было бы неплохо это время уменьшить? И с троичной системой так же, я полагаю.
Начинающие программисты нынче вообще не разбираются в системах счисления, сегодня начинающие программисты должны уметь разбираться в концепциях питона, вебпака и прочего. А байты, биты и все такое - это предмет низкоуровневых оптимизаций.
изначально было заложено 1символ = 1 байт
Это не есть правда.
Существовали и 5-битные и 7-битные кодировки.
Хуже того и байт далеко не всегда и не везде был 8 бит
сокращения времени освоения троичного компьютера (который когда-нибудь уже будет создан)
статья видимо переводная?
неожиданно окажется, что ЭВМ на троичной логике были созданы в прошлом веке в СССР.
"Сетунь" была разработана в промышленную эксплуатацию в 1959 г.
Обобщим: как успехи у троичных компьютеров в целом? Хотя бы исследовательских.
А есть какие-то современные эффективные способы хранения именно троичных состояний? Я вижу лишь такой вариант: два уровня напряжения, а между ними — неопределённость, как третее значение.
Как это ферритовая память была троичной? Если я правильно помню, там было два колечка, одно состояние было неиспользуемым.
О, а это любопытный момент. Можете подсказать источник? Я сходу не нашёл...
В целом идея интересная, но хочется подробностей применения. Математика, троичные сдвиги (на один триб, триплекс), дополнительный код (он нужен?), примеры реальных данных на N трибов в памяти и т.д.
Попробуйте нарисовать экран обычного hexdump в этой штуке, чтобы понять насколько оно хорошо.
Кольцевой сдвиг на трибл вправо: ABC >> 3 = CAB
Дополнительный код не нужен.
ОФФТОПИК: У меня есть пример дампа (в виде файла на диске), но не могу понять как его можно прикрепить в комментарий.
Математика: что именно?
Число Pi например. Математике все равно, как числа закодированы, главное, чтобы математические операции работали.
Это, кстати, очень хорошая мысль. К примеру, двоичный поиск - как его организовать в троичном компьютере, если он не умеет легко делить на 2?
Только не предлагайте троичный поиск, я даже боюсь представить, как бы выглядел его алгоритм :)
Вообще, компараторы, используемые в (двоичном) поиске/сортировке, обычно возвращают как раз троичное значение (больше/меньше/равно).
Ну будет там операция деления вместо сдвига — на асимптотику это не повлияет.
А что плохого в троичном поиске, если у вас триты вместо битов и троичный выбор самоочевидный по плотности? Бинарность — она такая. Стоит задуматься от тренарности, как некоторые вещи становятся весьма любопытными.
А что плохого в троичном поиске
Без ALU, которое умеет в троичное сравнение, все плохо. Будет обычный двоичный поиск, только не оптимально работающий.
Разумеется. Если мы используем трайты и прочие "три-", то это делается в рассчёте на троичную логику снизу. Без неё это всё — 2 бита с одним забаненым состоянием (так себе удовольствие).
Отсутствие производительных компьютеров совсем не повод закапывать идею как математическую конструкцию. У троичности есть масса плюсов (например, троичные флаги позволяют передавать больше состояния), симметричность в математике. В конце-концов, 3^9 (3^3^3) — это почти 4КБ. Прям слюнки текут.
симметричность в математике
Она и так есть. А наличие дополнительного кода в записи отрицательных двоичных чисел — для упрощения ALU, а не для неудобства программистам.
По поводу числа Pi: вы имеете ввиду как оно будет представлено? Не знаю, но думаю, это может быть аналог кодирования с плавающей запятой в двоичных компьютерах, с тем лишь исключением, что мантисса и порядок сразу будут включать в себя знак.
По поводу двоичного поиска: как уже было сказано выше amarao троичные флаги имеют три состояния. Следовательно, и команды условного перехода в троичном ассемблере будут изменены. Если в x86 для флага Z мы имеем, например для JZ, переход в случае нуля:
JZ M1
; Z=0
...
M1:
; Z=1
...
то в троичном варианте это будет выглядеть как тройное ветвление по знаку:
JZ M1, M2
; Z=0
...
M1:
; Z=+
...
M2:
; Z=-
...
Если вы объедините ветки, например, для "-" и "+", то получите эмуляцию двоичного условия.
У троичной системы есть объективные математические достоинства (симметричность относительно знака при округлении) и недостатки (сложно реализовывать).
А как сложить 2+2 в системе счисления -,0,+
Вы какую-то другую систему изобретаете. В статье -+0 используют.
Поэтому «два плюс два» — это: «0+-» + «0+-» = «0++»
В TREX: «B»+«B»=«D»
Что значит — как? В столбик!
В уравновешенной троичной системе число 2 представляется как (+-), значит надо сложить два (+-).
Младшие разряды: (-) + (-) = (-+), плюс отставляем, минус уходит в перенос.
Старшие разряды: (+) + (+) + (-) = (+).
Итог: (+-) + (+-) = (++).
Собственно, ответ ни разу не удивителен, поскольку (++) является представлением числа 4.
При использовании системы TREX предлагается трайтом называть девять троичных разрядов
Лучше уж 3 трита взять. Компьютеру вообще без разницы, а человеку с числом на 9 вариантов работать проще. Вон для двоичной системы сколько восьмеричная запись держалась. На 16-ричную перешли только со стандартизацией 8-битного байта, он очень хорошо на две цифры раскладывается.
Так и у вас. Даже если использовать буквы, то с диапазоном dcba0ABCD работать проще, чем с m...a0A...M. Ну будет три цифры в вашем машинном слове, ну и что. Зато считать удобнее. Будет новемичная (от novem) система
Кто-то просил практическую задачу, легко — сигма-дельта модулятор с 3-мя уровнями квантования (в литературе иногда обозначается как 1.5-битный модулятор). Это позволяет при отсутствии сигнала иметь 0 на выходе, в то время как у 1-битных модуляторов всегда будет шум низкой амплитуды.
Публикации
TREX: 27-ричная симметричная система счисления