AxeleronmikronА каким образом мы пришли к 50371 руб / 50369 руб? И каким образом всё это связано с машинным представлением данных?
Потому что, если эта сумма будет суммироваться из множества рублевых с копейками сумм, у вас может получиться разброс в итоговой сумме - в большую или меньшую сторону. Ибо double точности НЕ ГАРАНТИРУЕТ!
Не надо так с горячя. гарантирует, но в определённых пределах. так же как и децимал. пределы у каждого свои.
Дополню ответ позже.

AxeleronmikronА каким образом мы пришли к 50371 руб / 50369 руб? И каким образом всё это связано с машинным представлением данных?
Потому что, если эта сумма будет суммироваться из множества рублевых с копейками сумм, у вас может получиться разброс в итоговой сумме - в большую или меньшую сторону.
А может проблема в суммировании а не в хранении как double? Как вы пришли к выводу что дабл проблема а не операция сложения?

Shocker.PromikronА каким образом мы пришли к 50371 руб / 50369 руб? И каким образом всё это связано с машинным представлением данных?у тебя есть рулетка на 1 метр. Ты можешь отмерить ей километр (допустим, точность твоих рук позволяет это сделать)

А теперь представь, что у тебя немножко косячная рулетка, и длиной она 99,5 см

Сколько будет "разбег", когда ты отмеришь ей километр? А 10 километров? то-то.
Деньги такого не терпят
Если мне известа кривизна рулетки, то и километр я отмерю так-же точно. Но пример неудачный.

Axeleronmikron,

Надо не спорить, а скорее исправлять где там у себя накосячили пока не обнаружилось
Я не враг себе, следовать таким советам: меня уволят и будут правы. Но отношения к дискуссии это не имеет.

AxeleronОшибся немного с запятыми выше:


Я уже ответил на похожий пример. Вы исключаете из рассмотрения операции приведения, сложения и сравнения и приходите к выводу что виноват во всём дабл. Может просто такое обращение с даблом недопустимо?

Shocker.PromikronТаким образом если мы согласимся принятъ погрешность приведения то и на этапе сравнения нужно это учитывать. Проблем нет. Это не коим образом не ограничивает приминение доубле.то есть мы ради использования double откажемся от операции прямого сравнения. Будем всегда сравнивать с заданной точностью. Иначе получится как в приведенном мной экселевском файле (а именно это я и привел) - прямое сравнение двух вроде бы одинаковых чисел дает ЛОЖЬ.

еще раз - применение неточных типов допустимо только в расчетах с допустимой погрешностью. В финансовых расчетах погрешность недопустима, так как там не используются неточные величины.

А разве правило, при работе с дабл всегда учитывать точность представления, не входит самые азы обучения программированию? Сравнивать дабл на равенство это вобще моветон и редко допустимо. Но на этом я уже не заостряюсь сдесь. Почему вы исключили операцию сложения хочу спросить? Я бы сказал что и складывать так нельзя, если речь идёт о деньгах. А вот на ограничения использование дабла никак не сказывается.
И пересмотрите на досуге ваши убеждения, они силь смахивают на веру неподкреплённую фундаментальными знаниями.

AxeleronmikronЯ уже ответил на похожий пример. Вы исключаете из рассмотрения операции приведения, сложения и сравнения и приходите к выводу что виноват во всём дабл. Может просто такое обращение с даблом недопустимо?
Давайте лучше Вы покажите почему в моем примере сложенное выражение двух double не равно ожидаемому? И какое обращение с даблом допустимо с Вашей точки зрения?
Взгляните со стороны: бы утверждаете, что использование дабла недопустимо, обосновать утверждение не можете, приводите странный пример, и предлагаете мне, показать почему пример не отвечает вашему ожиданию? Я не знаю почему это должно быть лучше и лучше чего, но это был ваш выбор - получите: ошибка в вашем ожидании. Оно просто ошибочно и не обоснованно.
Предположим вы хотели спросить: как сложить два дабл числа представляющих цену(amount). Ответ: накопленный результат округлят до точности представления цены и избегать накопление погрешности но единицы измерения.
Если вы хотели спросить как сравнить два дабла: только с учётом погрешности.
И эти правила также действительны при работе с децимал.

Ну и ещё в догонку: децимал тоже floating point.

Shocker.PromikronИ пересмотрите на досуге ваши убеждения, они силь смахивают на веру неподкреплённую фундаментальными знаниями.Веры тут нет, знаний у меня достаточно, я писал, в том числе, на ассемблере. И я по этим граблям уже ходил. Удачи.
Давайте не будем тут мерятся, а то получится как в анекдоте.
Вернёмся к теме: Ваше утверждение о непременимости дабле для финансовых вычислений получит подтверждение или останется голословным?
Я считаю использование дабла в приведённом примере верным и могу это обосновать: возведение в степень для децимала.
Кроме этого обоснования есть ещё очень важный аргумент: скорость вычислений. А вот тот, кто взялся править код у меня вызывает подозрения: он даже не смог самостоятельно справится с ошибкой привидения.

skyANAmikron, почитайте: Что нужно знать про арифметику с плавающей запятой , - думаю Вам будет полезно.
Я не понял ваш поинт. Вы хотели привисти аргумент в пользу какого-то утверждения?