nedoPC.org

хм, не понимаю.
какие будут значения трёх тритов при -7, а какие при +5 ?

Очевидно, -+- для -7 и +-- для +5. Ни кто же не спрашивает состояние битов при шестнадцатеричных 9 и C, например...

ну в двоичных,восьмеричных и шестнадцатиричных системах счисления вроде нет отрицательных чисел(-0x1A никто же не пишет).
при конвертации в десятеричную систему крайний левый бит определяет знак числа.

В троичной(тритичной!?) системе я не могу сообразить что определяет знак числа.
Где можно посмотреть значения тритов полного ряда от -13 до 13, может конвертер какой есть?

Поэтому я и предложил использовать 9ричную систему счисления, что бы не было непоняток со знаком.

Знак старшего значащего трита. (Не самого старшего, а старшего, отличного от "0").

Запросто.

И далее по такому принципу

Очень даже пишут, но как правило, в десятеричной системе. Есть и байт со знаком от -128 до +127 (0 считается положительным). В троичной системе ноль относится к отдельной группе... да какой группе то? он один и есть беззноаковый

Да и в популярных открытых источниках это всё представлено весьма доходчиво:
https://ru.wikipedia.org/wiki/Троичная_система_счисления

Кстати, хорошо видно, что знак числа определяет знак старшего значащего трита.

Хм. Интересно, теперь понял.

Кстати, насчет шрифтов вообще...

Я когда пишу программы, люблю чтобы шрифт был моноширинный - так удобнее в ряде случаев...
Но стандартно в Венде моноширинных шрифтов не так уж много: Courier, Courier New...
Ну и остальные менее пригодны для работы.

А тут я вдруг неожиданно наткнулся на залежи приятных моноширинных шрифтов!
http://7fonts.ru/monoshirnyie/font_jackinput.html

Возможно, эту ссылку все знают, но я не знал...

Кстати, конвертер такой у нас прямо на форуме есть:

http://ternary.info/ternary/java.php?applet=2

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

Если надо сильно красочно посмотреть, то вот например

Понемногу пытаясь заставить работать конвертер из 6 тритов в 10 битов, посетила меня такая мысль:
6 тритов - 729 значений, многовато для байта, но уже 5 тритов с 243-мя значениями довольно приемлемо вписывается в байт, но некое несоответствие имеется.
А что, если конвертируя символы из байта в трайт (примем, что он 6-ти тритовый) сделать некое разбиение на страницы?
А именно первые 128 кодов символов являются стандартными для ASCII + добор до 243 символами из теоретической троичной таблицы символов - это первая "страница" (биты 9-10 = 00), символы с 129 по 256 + добор - вторая страница (биты 9-10 = 01) , а в третью запихать чисто троичные символы (биты 9-10 = 10).
Мне кажется при переводе двоичного текста в троичный это будет наиболее приемлемый вариант кодировки.

Нет, с этим я не согласен.
Обоснование : хотелось бы, чтобы как можно однороднее всё было кратно 3 .
( ну то есть если в двоичной в большинстве случаев пришли к кратности 2 , то логично, что тут 3 )
Впрочем навряд ли кто будет учитывать мнение .

( Однако предложений сурьёзных, без подколоки и переходов на личности ,как обзывать 9и-тритное пока что не было, так что критика моего мнения пока пустая
, в то время как я предлагал считать "старый трайт_Сетуни" схожим со "старым_байтом_шестибитным" ,то есть историческим и аналогично обусловленным дороговизной аппаратных ресурсов
, а новый трайт считать 9 тритов . Впрочем это надо обсуждать в другой теме . )

Но вот насчёт того,что символов 24310 - напомню, что система то сбалансированая.
И хозяину понравилась идея разделять код и данные.
То есть от -k до -1 код ,а от +1 до +k данные ,в случае 5и тритов данные в диапазоне от +1 до +121
так что и до 7и битной ascii чуток не хватит ( z { | } ~ _ не умещаются )

А вот идея страниц ( и кодов разной длины ) вполне себе "в тренде" - см. тот же unicod ..

Так что данные в диапазоне от +1 до (729-1)/2==+364 в случае типа "char" сопоставить в соответствие ascii8(+ещё10810{чего-нибудь})
,а в диапазоне от +1 до (19683-1)/2==+9841 сопоставить в соответствие юникоду
будет вполне логично.

Да тут вообще пока рано спорить. Это я для кода символа. Можно и 9 трит в будущем.
Или 12
Ну будет не 3 "страницы" а больше, или атрибут(ы) цвета.
До полной поддержки юникода пока далеко, но предусмотреть вполне будет правильным.

Да, спорить будем не здесь, а в другой теме, где грибы.

В любом случае не считайте, что у Вас в разпоржении все триты !

Сразу давайте будем делать непротиворечиво, без "закрывания" будущих возможностей нынешними "кривостями" .
Лучше зарезервировать, чем делать "впритык" .

Старший трит : "-1"~код , "0"~NIL , "+1"~данные
Следующие триты при старшем "+1" кодируют тег типа данных ( разширяемо! )
То есть можно например так :
+0- trilogik "-"
+00 trilogik "0"
+0- trilogik "+"

+-- в следующем триббле(триаде) продолжение тега, определяющее типы "unichar","string","unistring"

+-0 данные типа "char7" в следующих 6 тритах ( таким образом одиночный символ с тегом размещается в 9и тритном регистре, при этом считаем, что у него есть и седьмой(№6) трит, всегда равный +1 ,что даёт (2178-1)/2==109310 символа. Надеюсь для начала хватит ? .. )

+-+ в следующем триббле(триаде) продолжение тега, определяющее типы числовых данных "integer3"( {-13..+13} ) , "integer12"( {-265720..+265720} ) , "real3|9" , и т.д. ..


А вот в типах "string" , "unistring" можно будет хранить "char"-ы упакованно, не теряя драгоценные 3*n тритов на теги, ибо тег уже есть на всю структуру.