W>Искал по форумам, видел замечательные советы использовать BCD, но конкретных ссылок на реализацию BCD... Нужна С++ библиотека, желательно кроссплатформенная. Или какое-либо другое решение, кроме BCD.
Возможна поможет General Decimal Arithmetic. Там на сайте перечислены несколько библиотек работающих с такими числами.
Здравствуйте, wtom, Вы писали:
A>>причем здесь BCD? A>>Посмотри libgmp
W>Учитывая, что первая и основная target-платформа проекта Windows, меня в описании libgmp смутила такая фраза:
It also is known to work on Windoze in 32-bit mode.
:) W>не охота проблем, связанных с отсутствием достаточной поддержки "Windoze" ))) W>Но, видимо, придется ее попробовать... Спасибо )
Вообще-то Вам лучше более качественно определиться с задачей. Для бухгалтерии и других финансовых задач принципиально не BCD (хотя с ним удобнее), а точное представление с выбранной точностью — то есть представление с фиксированной точкой. Этого можно достичь десятичным float'ом (где он есть), но лучше всё-таки явно фиксированной точкой — тогда ещё и легко определить переполнение сразу в момент вычисления.
И если не гнаться за BCD, то может хватить и простого враппера вокруг 64-битных целых: отведя 3 цифры на доли копейки, Вы получите 12 цифр на рубли (то есть до триллиона оных), по-моему, практически вполне достаточно:) А если нет — из той же libgmp можно взять подсистему mpz (в целых числах) с произвольной точностью.
Далее, про "Windoze on 32-bit" — тут совершенно нет проблемы в названии:) кроме того факта, что она там неплотно используется (в отличие от Unix, где требуется несколькими стандартными продуктами для криптографии). И отзывов мало. Но попробовать безусловно можно — она сделана хорошо, есть тесты работы, и, думаю, максимумом проблем для 64 бит будет LLP64 в отличие от привычной для Unix LP64. Это лечится достаточно просто.
Ну или напишите сами:) длинная арифметика — задачка уровня курсовой 1-го курса или лабораторной работы 4-го.
Здравствуйте, wtom, Вы писали:
W>Пишу расчет бухгалтерии на C++ и Qt. Соответственно, насущной стала проблема неточности двоичного представления десятичных дробей в double и float.
От каких проблем double может спасти BCD?
Просто хорошо знаю немаленькую бух.систему в которой все числа double, проблемы с округлением, конечно возникают, но использование BCD или чего-то еще не может спасти в от проблем с округлением в принципе.
Приветствую!
Пишу расчет бухгалтерии на C++ и Qt. Соответственно, насущной стала проблема неточности двоичного представления десятичных дробей в double и float. А т.к. оперировать приходится не только суммами бабла, но и ценами и не целым количеством других различных штук, то необходимая точность плавает в широком диапазоне. Порядок чисел — тоже. Это я к тому, что хранить количество центов целым числом недостаточно. Надо поддержку BCD.
Искал по форумам, видел замечательные советы использовать BCD, но конкретных ссылок на реализацию BCD... Нужна С++ библиотека, желательно кроссплатформенная. Или какое-либо другое решение, кроме BCD.
Спасибо за любую помощь =)
The mantissa in stored in binary, as might be imagined from the fact precisions are expressed in bits. One consequence of this is that decimal fractions like 0.1 cannot be represented exactly. The same is true of plain IEEE double floats. This makes both highly unsuitable for calculations involving money or other values that should be exact decimal fractions. (Suitably scaled integers, or perhaps rationals, are better choices.)
Чъорт!!!
Это плюс к тому, что собрать последнюю версию под "Windoze" тот еще геммор.
Вопрос снова открыт: кто чем бабло считает, господа программисты?
Не стоит переходить реку вброд, если известно только, что ее глубина (средняя) 4 фута.
Здравствуйте, pagid, Вы писали:
P>Здравствуйте, wtom, Вы писали:
W>>Пишу расчет бухгалтерии на C++ и Qt. Соответственно, насущной стала проблема неточности двоичного представления десятичных дробей в double и float.
P>От каких проблем double может спасти BCD? P>Просто хорошо знаю немаленькую бух.систему в которой все числа double, проблемы с округлением, конечно возникают, но использование BCD или чего-то еще не может спасти в от проблем с округлением в принципе.
Например, 229885. * 1.305 в double представляется как 299999.924999999...
Округли до сотых на выводе: 299999.92. Тебя спросят: кто спер цент?
BCD способно представить 299999.925 как 299999.925 и правильно округлить до сотых: 299999.93.
Идея использовать int64 имеет право на жизнь, но у меня есть миллионные и т.д. дроби.
Использовать double тоже идея здравая, но только надо решить вышеописанную проблему. Все методы, которые я знаю, являются костылями, что не есть гуд, но, видимо, деваться некуда. Хнык.
Можно, например, перед округлением прибавлять к числу его epsilon (value + value * epsilon), можно умножать на нужный порядок и прибавлять .5 перед округлением )
Не стоит переходить реку вброд, если известно только, что ее глубина (средняя) 4 фута.
Здравствуйте, lazyden, Вы писали:
L>Здравствуйте, wtom, Вы писали:
W>>Искал по форумам, видел замечательные советы использовать BCD, но конкретных ссылок на реализацию BCD... Нужна С++ библиотека, желательно кроссплатформенная. Или какое-либо другое решение, кроме BCD.
L>Возможна поможет General Decimal Arithmetic. Там на сайте перечислены несколько библиотек работающих с такими числами.
Ага. Видел, спасибо )
Не стоит переходить реку вброд, если известно только, что ее глубина (средняя) 4 фута.
Здравствуйте, wtom, Вы писали:
P>>Просто хорошо знаю немаленькую бух.систему в которой все числа double, проблемы с округлением, конечно возникают, но использование BCD или чего-то еще не может спасти в от проблем с округлением в принципе.
W>Например, 229885. * 1.305 в double представляется как 299999.924999999... W>Округли до сотых на выводе: 299999.92. Тебя спросят: кто спер цент? W>BCD способно представить 299999.925 как 299999.925 и правильно округлить до сотых: 299999.93.
Это да, но рано или поздно придется не умножать, а делить и эти же эффекты проявятся и в BCD.
Не знаю как бухгалтера использующие центы, но те, что пользуются копейками к чудесам округления относятся спокойно.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, wtom, Вы писали:
A>>>причем здесь BCD? A>>>Посмотри libgmp
W>>Учитывая, что первая и основная target-платформа проекта Windows, меня в описании libgmp смутила такая фраза:
It also is known to work on Windoze in 32-bit mode.
W>>не охота проблем, связанных с отсутствием достаточной поддержки "Windoze" ))) W>>Но, видимо, придется ее попробовать... Спасибо )
N>Вообще-то Вам лучше более качественно определиться с задачей. Для бухгалтерии и других финансовых задач принципиально не BCD (хотя с ним удобнее), а точное представление с выбранной точностью — то есть представление с фиксированной точкой. Этого можно достичь десятичным float'ом (где он есть), но лучше всё-таки явно фиксированной точкой — тогда ещё и легко определить переполнение сразу в момент вычисления.
N>И если не гнаться за BCD, то может хватить и простого враппера вокруг 64-битных целых: отведя 3 цифры на доли копейки, Вы получите 12 цифр на рубли (то есть до триллиона оных), по-моему, практически вполне достаточно А если нет — из той же libgmp можно взять подсистему mpz (в целых числах) с произвольной точностью.
N>Далее, про "Windoze on 32-bit" — тут совершенно нет проблемы в названии кроме того факта, что она там неплотно используется (в отличие от Unix, где требуется несколькими стандартными продуктами для криптографии). И отзывов мало. Но попробовать безусловно можно — она сделана хорошо, есть тесты работы, и, думаю, максимумом проблем для 64 бит будет LLP64 в отличие от привычной для Unix LP64. Это лечится достаточно просто.
N>Ну или напишите сами длинная арифметика — задачка уровня курсовой 1-го курса или лабораторной работы 4-го.
Да в итоге обошлись оберткой над int64, как выше был пост. Количество бабла хранится в int64 с точностью до цента, цены и share-сы в double. Результат вполне устраивает )
libgmp последней версии под Windows мне в приемлемом варианте собрать не получилось. Есть VS проекты для более ранней версии, но в ней нет C++ обертки. Для свежей версии таких проектов не нашел. Мог бы, конечно, запариться и сам написать, но она по-любому не решает задачи. В libgmp такие же проблемы с представлением десятичных дробей, как и у double. Так что пусть ее.
Не стоит переходить реку вброд, если известно только, что ее глубина (средняя) 4 фута.
