Здравствуйте, alzt, Вы писали:
A>Здравствуйте, toffeeA, Вы писали:
E>>>А чем, тогда, не устраивает double? E>>>Вообще, о какой платформе речь?
A>>Речь идет о процессоре SHARC. А вы когда-нибудь сталкивались с реализацией типа в виде простой дроби или это просто мысль?
A>О чём речь — о реализации в виде простой дроби или о типе данных с плавающей точкой? A>Если нужно деньги считать, то плавающая точка тут не нужна. Достаточно обычного целого. При этом надо помнить, что считаем не в единицах, а в сотых долях единиц (или в десятитысячных), в зависимости от задачи. Если диапазон маленький — то слепить несколько целых в один класс.
Кто-то тут шутку про деньги кинул и она прижилась . Речь идет не о деньгах, а о мощном типе с плавающей точкой по типу Double. Можно в точности как Double. Мне предложили реализацию плавающей точки в виде отношения двух int, то есть в виде простой дроби, но я считаю что это чуток не подходит из-за маленького диапазона.
Здравствуйте, toffeeA, Вы писали:
A>Здравствуйте, Erop, Вы писали:
E>>Здравствуйте, toffeeA, Вы писали: A>>>Место в памяти есть, таких значений не много будет, быстродействие не сильно важно, так как именно этот обсчет планируется выполнять раз в 30сек (60 сек)
E>>А чем, тогда, не устраивает double? E>>Вообще, о какой платформе речь?
A>Речь идет о процессоре SHARC. А вы когда-нибудь сталкивались с реализацией типа в виде простой дроби или это просто мысль? У меня тоже она возникла, но какой-то маленький диапазон получается. Минимально в виде такой дроби можно записать 1/(2^32), что соответствует порядку 1E-10. А максимально (2^32)/1. Можно конечно парочку интов взять, но по-моему мне только лишь усложнит реализацию?
кпд у такого подхода низкий
1/2 = 2/4 = 6/12 и тд.
реально будут использоватся только простые числа из диапазона 32 бит...
Здравствуйте, toffeeA, Вы писали:
A>Кто-то тут шутку про деньги кинул и она прижилась . Речь идет не о деньгах, а о мощном типе с плавающей точкой по типу Double. Можно в точности как Double. Мне предложили реализацию плавающей точки в виде отношения двух int, то есть в виде простой дроби, но я считаю что это чуток не подходит из-за маленького диапазона.
Читал вскольз, поэтому не понял.
Тогда почему бы не реализовать подобно double. С мантисой, экспонентой. Работать будет медленнее, плюс тестировать много.
Наверняка в сети уже есть подобные реализации.
A>Читал вскольз, поэтому не понял. A>Тогда почему бы не реализовать подобно double. С мантисой, экспонентой. Работать будет медленнее, плюс тестировать много. A>Наверняка в сети уже есть подобные реализации.
Мне тоже кажется, что это давно уже и много раз кем-то написано. Хочется найти готовенькое, но пока найти не могу
Здравствуйте, toffeeA, Вы писали:
A>Здравствуйте, Caracrist, Вы писали:
C>>О! Уже приближаемся к истине! C>>Сложение, вычитание и умножение побитово не сложно организовать... C>>Вопрос: какие операции этот тип должен поддерживать? C>>(деление, корень, синусообразные... )
A>Из операций только сложение, вычитание и умножение. Допустим организую я свой тип по типу double с 11-битной экспонентой и 52-битной мантиссой. Побитно достучаться к нему смогу и сконвертировать из float в этот формат и обратно. Но как организовать арифметические операции "побитово" без потери точности введенного типа я в упор не понимаю. И что за тип такой Decimal, можно поподробней?
сложение:
на базе 16 битного флоата:
1 — знак
5 — смещение
10 — число
два числа:
первое: смещение: 10010 = +2, число: 0000001101 == 110100.0
второе: смещение: 01011 = -5, число: 0110101001 == 1101.01001
выводим их оба в bitarray одинаковой длины:
00101100.00000000
00001101.01001000
складываем:
00111001.01001000
переводим обратно к плавающей точке:
1110010101 -4 (единица в конце изза округления)
результат: смещение: 01100 = -4 число: 1110010101 == 111001.0101
максимальный необходимый bitarray размером в диапазон смещения, для double 11bit это 256 байт, хотя можно обойтись и двойным размером длины числа (52х2 bit у double = 13 байт) так как часть ниже всё равно урежется.
Вычитание по такому же приципу.
Теперь умножение:
возьмём те же два числа: 110100.0 и 1101.01001
умножаем в столбик:
110101001 +0 (х1)
+
110101001 +2 (х100)
+
110101001 +3 (х1000)
Складывать мы умеем.. дальше делаем поправку смещения на (+2 -5)
000110101001.
011010100100.
100001001101. = 1000010011 +2
...
A>Мне предложили реализацию плавающей точки в виде отношения двух int, то есть в виде простой дроби, но я считаю что это чуток не подходит из-за маленького диапазона.
Если постараться, то точность при подобном подходе может быть расширена за счёт костылей вида 1/( 1/2^32 ) и 2^31/1 * 2^31/1 и т.д. Когда-то писал подобное под винду для проведения мат. расчётов с большой точностью. К сожалению, не подыму никаких этих наработок, но по скорости они (в большинстве моих задач) превосходили решения на основе длинной арифметики. Главное — правильно всё спроектировать .
Здравствуйте, Sni4ok, Вы писали:
S>Здравствуйте, Vamp, Вы писали:
S>>>конечноже хранят V>>Только там, где плюс-минус доллар ничего не решает.
S>множество торговых терминалов хранят денежные значения в даблах, не говорите чего не знаете.
Примеры можно? И какие именно денежные значения? Value, price...? Без подвоха, просто интересно.
Не стоит переходить реку вброд, если известно только, что ее глубина (средняя) 4 фута.
Здравствуйте, Caracrist, Вы писали:
C>сложение: C>на базе 16 битного флоата: C>1 — знак C>5 — смещение C>10 — число
C>два числа: C>первое: смещение: 10010 = +2, число: 0000001101 == 110100.0 C>второе: смещение: 01011 = -5, число: 0110101001 == 1101.01001 C>выводим их оба в bitarray одинаковой длины:
C>00101100.00000000 C>00001101.01001000 C>складываем: C>00111001.01001000 C>переводим обратно к плавающей точке: C>1110010101 -4 (единица в конце изза округления) C>результат: смещение: 01100 = -4 число: 1110010101 == 111001.0101
C>максимальный необходимый bitarray размером в диапазон смещения, для double 11bit это 256 байт, хотя можно обойтись и двойным размером длины числа (52х2 bit у double = 13 байт) так как часть ниже всё равно урежется. C>Вычитание по такому же приципу.
C>Теперь умножение: C>возьмём те же два числа: 110100.0 и 1101.01001 C>умножаем в столбик: C>110101001 +0 (х1) C>+ C>110101001 +2 (х100) C>+ C>110101001 +3 (х1000) C>Складывать мы умеем.. дальше делаем поправку смещения на (+2 -5) C>000110101001. C>011010100100. C>100001001101. = 1000010011 +2
C>0100001001100. C>0110101001000. C>1010110010100. = 1010110011 +3
C>1010110011 +3 +2 -5 = 1010110011 +0 C>результат умножения: смещение: 10000 = 0, число: 1010110011 == 1010110011.0 C>сверяем с калькулятором: 1010110010.10100
C>Деление если очень понадобится можно реализовать бинарным поиском через умножение...
Спасибо! На примере все сразу понятней стало, сейчас буду пробовать.
S>множество торговых терминалов хранят денежные значения в даблах, не говорите чего не знаете.
Такие разработчики. Потом считают, почему у них не сходятся дебет с кредетом.
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, <Аноним>, Вы писали:
А>> Точности Float к сожалению не хватает, а использовать тип Double не представляется возможным.
К>А это задача, изначально требующая высокой точности, или ошибка набегает? К>Может, вычислительный метод поменять, а там и float хватит?
Нет, не ошибка набегает. Вычисляются коэффициенты аппроксимационного полинома. И реально не порядка не хватает, а точности мантиссы, знаков после запятой. При определенном раскладе получается так, что циферки сжирают друг друга(складываются и вычитаются) и получается 0, а должен быть не 0! Я уже занялась созданием Double, хотя и не испытываю оптимизма по этому поводу.
Здравствуйте, toffeeA, Вы писали:
A>Нет, не ошибка набегает. Вычисляются коэффициенты аппроксимационного полинома. И реально не порядка не хватает, а точности мантиссы, знаков после запятой. При определенном раскладе получается так, что циферки сжирают друг друга(складываются и вычитаются) и получается 0, а должен быть не 0! Я уже занялась созданием Double, хотя и не испытываю оптимизма по этому поводу.
Когда циферки сжирают друг друга — это именно что ошибка набегает.
Например, величина ошибки зависит от порядка суммирования. Если суммировать числа по возрастанию абсолютного значения, ошибка будет меньшей, если по убыванию — большей.
Вычисление сходящегося ряда — т.е. сумма убывающей последовательности — в наивной реализации даст большую ошибку.
Глубоко вычислительной математикой не занимался, поэтому не скажу за хорошие методы вычисления коэффициентов. Но они должны быть, надо порыться в гугле и специальной литературе.
Здравствуйте, toffeeA, Вы писали:
A>Речь идет о процессоре SHARC. А вы когда-нибудь сталкивались с реализацией типа в виде простой дроби или это просто мысль? У меня тоже она возникла, но какой-то маленький диапазон получается. Минимально в виде такой дроби можно записать 1/(2^32), что соответствует порядку 1E-10. А максимально (2^32)/1. Можно конечно парочку интов взять, но по-моему мне только лишь усложнит реализацию?
Сталкивался. От задачи зависит хватит диапазона или нет.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
. Речь идет не о деньгах, а о мощном типе с плавающей точкой по типу Double. Можно в точности как Double. Мне предложили реализацию плавающей точки в виде отношения двух int, то есть в виде простой дроби, но я считаю что это чуток не подходит из-за маленького диапазона.
)
Перекуём баги на фичи!
