[kostya-m 0]

При работе потребовалась обработка данных типа money. Это 64 битное целое, представляющее дробное число с фиксированным количеством знаков после запятой - 4. Вопрос стоит об оптимизированной библиотеке под IAR. Понятно, что неоптимизированную на С я и сам напишу достаточно быстро.

[vmp 0]

При работе потребовалась обработка данных типа money. Это 64 битное целое, представляющее дробное число с фиксированным количеством знаков после запятой - 4. Вопрос стоит об оптимизированной библиотеке под IAR. Понятно, что неоптимизированную на С я и сам напишу достаточно быстро.

 

А встроенный тип signed long long или unsigned long long чем не подходит?

Смотри EWARM_CompilerReference.pdf, Part 2. Compiler Reference, Data Representation, Basic data types.

[Alex03 0]

тем более что вряд ли эти money надо умножать друг на друга? (не представляю рубль в квадрате :) )

Скорее всего складывать/вычитать, да умножать на количество (т.е. на целое)

Если так то long long вполне рулит, а то и сразу int64_t.

[kostya-m 0]

А встроенный тип signed long long или unsigned long long чем не подходит?

Смотри EWARM_CompilerReference.pdf, Part 2. Compiler Reference, Data Representation, Basic data types.

В общем-то это и есть тот тип, базируясь на котором и можно написать нужное. В принципе, остаются только вопросы округления при делении и умножении, поскольку 4 знака после запятой в этих операциях превращаются в 8. Потому и спрашивал уже готвое. Ладно, наверно проще написать.

 

Спасибо.

 

Умножать и делить надо. Например, дробное количество умножить на дробную цену.

Изменено 1 марта, 2007 пользователем Мусатов Константин

[iShustov 0]

В общем-то это и есть тот тип, базируясь на котором и можно написать нужное. В принципе, остаются только вопросы округления при делении и умножении, поскольку 4 знака после запятой в этих операциях превращаются в 8. Потому и спрашивал уже готвое. Ладно, наверно проще написать.

 

Спасибо.

 

Умножать и делить надо. Например, дробное количество умножить на дробную цену.

 

Если уже собрались писать свою библиотеку для "денежного", рекомендую хранить в BCD-формате - и точность не теряется, и преобразования при печати практически отсутствуют...

 

А делить то точно надо??

[kostya-m 0]

А делить то точно надо??

Да. Например, может прийти сумма и количество.

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

[Alex03 0]

Умножать и делить надо. Например, дробное количество умножить на дробную цену.

А кол-во тоже в этом же типе данных?

И кстати какая максимальная сумма возможна?

Знаковый инт64 может хранить ln(2^63)/ln(10) = 18,96488972683 десятичных разрядов.

Если в промежуточном вычислении 8 из них после запятой, то максимальная сумма будет порядка десятков миллиардов. Иначе в промежуточных вычислениях придётся использовать более широкие переменные. :)

В BCD есть свои плюсы. :) Но есть и минусы.

Можно ещё поизвращаться, выделив на дробную часть целое число бит (типа 50.14 или 48.16), но тут другой гемор вылезет (типа 5копеек+5копеек=11копеек). :)

 

А делить то точно надо??

Да. Например, может прийти сумма и количество.

ИМХО вот тут то и может вылезти весь гемор с округлениями. Цена за единицу не всегда совпадёт с исходной. :)

[kostya-m 0]

Я с этими округлениями на финансовых вещах с 93 года столько собак съел, что сыт по горло. Тип money стандартный для виндов и с ним мы уже научились корректно работать, что бы не копить по копейке на старость. Вообще, тут все дробное, и цена и количество и сумма и скидка. А еще есть бухгалтерские правила округления. В конце концов, всегда можно действовать как в старом анекдоте.

Алкаш подходит к продавщице в рюмочной: "Скажите, сколько стоит капля водки" - "Ни сколько" - "Так накапайте мне стаканчик!"

Изменено 2 марта, 2007 пользователем Мусатов Константин

[Alex03 0]

:) И чё у человека не 8 пальцев на руках?

Считали бы всё в шестнадцатеричке и не жужжали б! :)