AxeleronrigorMortis,

Не зря Ваш товарищ уволился (был уволен?). Double нельзя использовать для стоимости.
Из каких соображений - нелзя? Вера, законадельство или воспитание запрещает?

PallarismikronИз каких соображений - нелзя?

Из-за особенностей хранения double в памяти. Если ты видишь на экране 42,13, а на самом деле там 42,1299999876, то на операциях эта разница будет выражаться в копейках и рублях, а это уже - ответственность

Почему нелзя то я так и не понял из примера.
Мне всё равно как оно там внутри на самом деле представлено. Пусть в двоичном коде, електронным зарядом или магнитнитизацией. Если на экране или в отчёте 42,13 то осталное вроде как значения не имеет. Где я не прав?

Axeleronmikronпропущено...

Из каких соображений - нелзя? Вера, законадельство или воспитание запрещает?
Учить матчасть
Посмотрел на лозунги на немесном наречии, но ответа на мой вопрос не увидал. Почему нельзя то?

PallarisНа экране у тебя 42,13 и таких - тысячи, а в месячном отчете отчисления в налоговую составили вместо 50371 руб - 50369 руб. И уже статья.
А каким образом мы пришли к 50371 руб / 50369 руб? И каким образом всё это связано с машинным представлением данных?

AxeleronmikronПочему нельзя то?
Потому что это деньги, а деньги любят точный счет. double используется, если точность после запятой неважна. Так понятнее на 'местном наречии'?
Это ваше убеждение. Вы попробуйте аргументами, а не внушением. Почему нелзя? Достаточно привести один пример,
где хранение данных в доубле не позволяет достич определённой (на ваш выбор) цели обработки данных.

Shocker.Proа еще проверка на равенство
30 + 12,13 = 42,13
не сработает, упс, счета не сходятся, пошло поехало...

В этом примере есть две явных операции и одня неявная: сложения, сравнения и приведения.
При этом иммено привидение теряет точность. Другими словами мы видим или пишем (42,13) не то что получим
в результате машинной обработки. Если же иметь эту операцию приведения в виду, то результат
(30 + 12,13) - 42,13 будет условно равен погрешности, которая принимается нами уже на первом шаге неявного приведения. Таким образом если мы согласимся принятъ погрешность приведения то и на этапе сравнения нужно это учитывать. Проблем нет. Это не коим образом не ограничивает приминение доубле.

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