и второй:Shaos wrote:Idea about representation of floating point numbers: Lets take "truble" and divide it to 2 parts: 6-trit exponent and 18-trit fraction. By accuracy it is better than 32-bit "float", worse than 64-bit "double" and similar to 36-bit floating number in IBM System/360 from 1964 that had 9-bit sign and exponent and 27-bit fraction. Because of nature of balanced ternary numeric system we don't need "biasing" exponent. Also we don't need separate sign bit - we simply combine it with "hidden" most significant bit of fraction instead and it will be part of full 18-trit fraction. So range of exponent is from -364 to +364 (3^6/2) and fraction from -193710244 to +193710244 (3^18/2 that is max possible integer represented by this floating point format). To simplify formula for calculation number from representation we may simply forget about "fractional" nature of fraction and say F*3^E
![]()
P.S. here ^ means "power"
Shaos wrote:Right now I think that ability to compare normalized floating point numbers as integers is good and to have it we should do "fraction" really fractional (-1 < F < 1): (F*3^18)*3^E = F*3^(18+E). In this case for example to do float from integer 193710244 (PPPPPPPPPPPPPPPPPP) we have to add exponent +18 (OOPNOO): OOPNOOPPPPPPPPPPPPPPPPPP (here fraction is O.PPPPPPPPPPPPPPPPPP). Also to represent 0.5 we will use OOOOOOPPPPPPPPPPPPPPPPPP (error is 0.00000000258).
P.S. But in case of integer "fraction" described in my previous post we still can use normalization as shifting to the left and comparison "normalized" floating point numbers as regular integers...
Последний вариант более походит на обычную двоичную плавающую точку (но без отдельного бита под знак и без необходимости сдвигать порядок exponent) и на днях я понял как можно разрешить проблему что дробная часть может вылезти за точку в троичном представлении (как показано выше P.N = 0.666...) - нам надо выдерживать не -1 < F < +1 (F это мантисса - mantissa или significand или fraction) при нормализации, а -0.5 < F < +0.5 т.к. .PPPPPPPPPPPPPPPPPP это +0.5, а .NNNNNNNNNNNNNNNNNN это -0.5. Соответственно OOOOOOPPPPPPPPPPPPPPPPPP всё также будет означать 0.5, однако если прибавить сюда .OOOOOOOOOOOOOOOOOP нам придётся сдвинуть мантиссу для нормализации, хоть она всё ещё будет оставаться меньше 1 (но уже больше 0.5).Shaos wrote:I forgot one important feature of balanced ternary numeric system - fractional number may have not zero in integer part of balanced ternary representation! For example P.N is 0.666...
Можно специальные числа добавить:
положительная бесконечность - все триты порядка равны P, а старший трит мантиссы равен P;
отрицательная бесконечность - все триты порядка равны P, а старший трит мантиссы равен N;
не-число (NaN) - все триты порядка равны P, а старший трит мантиссы равен O?
все остальные триты мантиссы игнорируются во всех трёх случаях
(кстати примерно тоже самое предлагал sva в 2008 году)
Мне представляется, что реализация троичной плавающей точки должна быть сильно проще двоичной - попробуем посчитать сколько нужно тритов для реализации точности, сравнимой с двоичным вариантом (будем прибавлять к количеству битов двоичной мантиссы 2 т.к. там есть отдельный бит знака и скрытый самый старший бит 1 для нормализованных чисел с плавающей точкой):
float (32-bit floating point) - порядок 8 мантисса 23 и 1 знак - троичный порядок 8/1.585=5.05 -> будет чуть больше 5 тритов, троичная мантисса (23+2)/1.585=15.77 -> 16 тритов т.е. всего 21;
double (64-bit floating point)- порядок 11 мантисса 52 и 1 знак - троичный порядок будет 11/1.585=6.95 -> 7 тритов, троичная мантисса (52+2)/1.585=34.07 -> 35 тритов т.е. всего 42;
x86 extended (80-bit floating point) - порядок 15 мантисса 64 и 1 знак - троичный порядок 15/1.585=9.46 -> 10 тритов, троичная мантисса (64+2)/1.585=41.64 -> 42 трита т.е. всего 52;
quad (128-bit floating point) - порядок 15 мантисса 112 и 1 знак - троичный порядок 15/1.585=9.46 -> 10 тритов, троичная мантисса (112+2)/1.585=71.93 -> 72 трита т.е. всего 82.
Значит для троичного float можно взять описанный выше вариант с 6-тритным порядком и 18-тритной мантиссой - всего 24 трита (и это будет чуть лучше, чем float).
А для троичного double - скажем пусть будет 9-тритный порядок и 39-тритная мантисса - всего 48 тритов (по точности будет где-то между 64-битной и 80-битной плавающей точкой).
P.S. Соответственно расширенная троичная плавающая точка будущего (quad) может иметь 12-тритный порядок и 84-тритную мантиссу - всего 96 тритов ( вот оно побъёт всех : )
P.P.S. Я в 2011 году начал было городить на сях библиотеку троичной арифметики с внутренним представлением числа с троичной плавающей точкой - можно её реанимировать и на ней обкатать все алгоритмы