Точность числовых данных (значащие цифры числа):   5 цифр для типов float и double, 15 цифр для типа decimal. Есть страны, где буханка хлеба стоит сотни тысяч денежных единиц. Представим себе, что надо написать в такой стране банковскую программу, использующую такие большие числа (для банка это уже будут сотни и тысячи триллионов). 

Как можно это сделать при таком малом числе значащих цифр? 
Или я что-то не то спрашиваю?...

Это не так. Я бы сказал скорее 7 цифр для float, 15 для double и 28 для decimal.


По MSDN наибольшее число, представимое в decimal:
79,228,162,514,264,337,593,543,950,335
Это 79 триллионов умноженных на триллиард. Должно хватить даже для Зимбабве 

Это сообщение отредактировал(а) Дрон - 30.11.2009, 18:18

Хорошо.
Что делать, если число всё же выходит за рамки типа double, а нам к этому числу ой как надо применить несколько функций из математической библиотеки ?  Тип decimal здесь не подходит. Как специалисты выходят из такого положения ?

ИМХО они туда не заходят, не стоит доводить до такого, все числа должны быть сопоставимы

Может конечно фигню скажу, но я бы просот передвинул запятую в числе до всех мат.операций (в процессе считывания, когда число  еще строка), а потом обратно запятую...

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

зы Сталкивался с подобной проблемой при написании программы вычисления конечными элементами, решение наиболее верное => менять подход в расчетах, дифуры "причесать"  

Ну у человека я думаю абстрактный вопрос ))) Вообще можно рискнуть в таком случае писать свой класс, нуружу который выпускает число в строке (и принимает тоже), внутри себя же разбивает его на подчисла (пускай по 12 знаков, допустим), и перегрузить ему сложение, вычитание и прочее. Для него же перегрузить и все другие мат. функции, которые нужны. боюсь что с синусами и проч. буду проблемы, но элементарные сложение-вычитание реализовать можно. По идее для банка хватит ;-)

Вообще, для подобных задач давно уже придуман EA-паттерн "Money".
А уж при его реализации вполне можно все эти тонкости учесть (например хранить отдельно целую часть, ее десятичный порядокб дробную часть).

Вот навскидку пример реализации - http://www.codeplex.com/MoneyType

это конечно вариант, но я не об этом, а о том "стоит ли?"