Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Как ты пришёл к такому выводу?
Ты продемонстрировал их недостаток в качестве иллюстрации к утверждению, что числа с фиксированной точкой "лучше".
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, avpavlov, Вы писали:
A>>Ну и контр пример A>>http://ideone.com/f8ELDf
EP>Те же самые грабли. EP>Если же действительно нужно накапливать суммы в дробях — то и возьми тип представляющий рациональные числа.
"Суммы в дробях" — это вообще в финансах-бухгалтериях самая распространённая операция. Получается, что числа с фиксированной точкой идут в лес, и теперь рациональные числа наше всё?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, pagid, Вы писали:
EP>>>http://ideone.com/IsCuWE P>>Нужно ли из этого сделать вывод, что числа с плавающей точкой использовать нельзя?
EP>Как ты пришёл к такому выводу?
Тебя подводят к мысли, что проблему с округлением нельзя решить ни даблами, ни фиксированной точкой. Эта проблема решается только административным путем Нужно согласовывать с пользователем что и на каком шаге округляется. Нужно прорабатывать с ним сценарии, чтобы он видел на что подписывается. А когда всё проговорено, то реализацию можно что на том подходе, что на этом. Топикстартер же пытается от разговора с клиентами уклониться и решить проблему математически.
Здравствуйте, pagid, Вы писали:
EP>>Как ты пришёл к такому выводу? P>Ты продемонстрировал их недостаток в качестве иллюстрации к утверждению, что числа с фиксированной точкой "лучше".
Я показал, что "Без фиксированной точки у него могут быть проблемы даже без округления."
Как ты от этого перешёл к "числа с плавающей точкой использовать нельзя" —
Здравствуйте, avpavlov, Вы писали:
A>"Суммы в дробях" — это вообще в финансах-бухгалтериях самая распространённая операция.
Пример в студию. А то у тебя сравнение — "не такое частое", а дроби — самоё распратранённое.
A>Получается, что числа с фиксированной точкой идут в лес, и теперь рациональные числа наше всё?
EP>>Если же действительно нужно накапливать суммы в дробях — то и возьми тип представляющий рациональные числа.
На практике же, я встречался с тем что есть правило по которому нужно округлять, и в какую кучку положить остаток.
Здравствуйте, avpavlov, Вы писали:
EP>>>>>>Без фиксированной точки у него могут быть проблемы даже без округления. A>>>>>Давай в студию пример для чисел из реальной жизни (а не граничных значений double) EP>>>>http://ideone.com/IsCuWE P>>>Нужно ли из этого сделать вывод, что числа с плавающей точкой использовать нельзя? EP>>Как ты пришёл к такому выводу? A>Тебя подводят к мысли, что проблему с округлением нельзя решить ни даблами, ни фиксированной точкой.
Каким телепатическим путём ты к этому пришёл? А главное каким образом это относится к подчёркнутой фразе?
да, кстати, fixed-point вовсе не означает что нужно использовать только копейки/центы/пфенниги.
Precision спокойно увеличивается и для fixed-point, без потери ассоциативности сложения, без потери точности вычислений на +-*%, с простыми сравнениями. Так что контр-пример в топку.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Ну вот тебе финансовая задачка — тебя надо купить некий stuff и ещё что-то, берёшь соответственную сумму, покупаешь stuff — а на что-то уже не хватает :
Так в случае применения чисел с фиксированной точкой та же проблема, только вид сбоку. Да, она может проявится только если исходныне, числа (в твоем примере stuff и etc) не заданы литералами, а получены в результате вычислений — деление, расчет процентов, расчет налога по тарифу.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, avpavlov, Вы писали:
A>>"Суммы в дробях" — это вообще в финансах-бухгалтериях самая распространённая операция.
EP>Пример в студию. А то у тебя сравнение — "не такое частое", а дроби — самоё распратранённое.
Ну подсчет стоимости накладной и НДС отдельной колонкой. А если товар ещё и весовой При этом никаких сравнений тут вообще нет и не предвидится. Но я согласен, приложение приложению рознь, и частота операций разнится. Но речь ведь идёт о решении административной проблемы математическими методами
A>>Получается, что числа с фиксированной точкой идут в лес, и теперь рациональные числа наше всё?
EP>
EP>>>Если же действительно нужно накапливать суммы в дробях — то и возьми тип представляющий рациональные числа.
EP>На практике же, я встречался с тем что есть правило по которому нужно округлять, и в какую кучку положить остаток.
Правила == административное решение. Если есть правила, то можно и на даблах всё то же самое замутить.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, avpavlov, Вы писали:
A>>Ну и контр пример A>>http://ideone.com/f8ELDf
EP>да, кстати, fixed-point вовсе не означает что нужно использовать только копейки/центы/пфенниги.
Увеличение точности просто отодвигает проблему, а не решает её
EP>Precision спокойно увеличивается и для fixed-point, без потери ассоциативности сложения, без потери точности вычислений на +-*%, с простыми сравнениями. Так что контр-пример в топку.
Расскажи, как в таком сценарии с фиксед пойнтами должна была бы обеспечиваться ассоциативность сложения?
decimal_2_2 x = 1.33
decimal_2_2 y = 1.33
decimal_2_1 z = 1.1
decimal_2_1 s1 = (x+y)+z
decimal_2_1 s2 = x+(y+z)
Здравствуйте, pagid, Вы писали:
P>Совсем по другим причинам.
Каюс, 'float + деньги = проблемы' послужило возбудителем условного рефлекса, внимательно уже не читал.
Здравствуйте, pagid, Вы писали:
EP>>Ну вот тебе финансовая задачка — тебя надо купить некий stuff и ещё что-то, берёшь соответственную сумму, покупаешь stuff — а на что-то уже не хватает : P>Так в случае применения чисел с фиксированной точкой та же проблема, только вид сбоку. Да, она может проявится только если исходныне, числа (в твоем примере stuff и etc) не заданы литералами
А причём тут вообще литералы?
P>, а получены в результате вычислений — деление, расчет процентов, расчет налога по тарифу.
Расчёт процентов и налогов — вообще не в кассу — там десятичные дроби, которые, при достаточной разрядности fixed-point, представляются в точном виде
Здравствуйте, avpavlov, Вы писали:
A>>>"Суммы в дробях" — это вообще в финансах-бухгалтериях самая распространённая операция. EP>>Пример в студию. А то у тебя сравнение — "не такое частое", а дроби — самоё распратранённое. A>Ну подсчет стоимости накладной и НДС отдельной колонкой.
НДС? Да ты шутишь наверное? Там десятичная дробь
A>А если товар ещё и весовой
И что у тебя весы показывают? 47/59кг небось?
A>При этом никаких сравнений тут вообще нет и не предвидится. Но я согласен, приложение приложению рознь, и частота операций разнится. Но речь ведь идёт о решении административной проблемы математическими методами
Речь идёт не об исходном округлении, а об "Без фиксированной точки у него могут быть проблемы даже без округления." — мы же в этой под-ветке находимся?
A>>>Получается, что числа с фиксированной точкой идут в лес, и теперь рациональные числа наше всё? EP>>
EP>>>>Если же действительно нужно накапливать суммы в дробях — то и возьми тип представляющий рациональные числа.
EP>>На практике же, я встречался с тем что есть правило по которому нужно округлять, и в какую кучку положить остаток. A>Правила == административное решение.
Да это понятно всё. Речи о том, что правил которые предписывают накоплять всё в дробях (не-десятичных!) на практике не встречал. Так что твой пример мало того что решается и в fixed-point, так ещё и притянут за уши
Здравствуйте, avpavlov, Вы писали:
A>>>Ну и контр пример A>>>http://ideone.com/f8ELDf EP>>да, кстати, fixed-point вовсе не означает что нужно использовать только копейки/центы/пфенниги. A>Увеличение точности просто отодвигает проблему, а не решает её
А ты думаешь double её как-то решает? Там тоже самое увеличение точности
EP>>Precision спокойно увеличивается и для fixed-point, без потери ассоциативности сложения, без потери точности вычислений на +-*%, с простыми сравнениями. Так что контр-пример в топку. A>Расскажи, как в таком сценарии с фиксед пойнтами должна была бы обеспечиваться ассоциативность сложения? A>
A>decimal_2_2 x = 1.33
A>decimal_2_2 y = 1.33
A>decimal_2_1 z = 1.1
A>decimal_2_1 s1 = (x+y)+z
A>decimal_2_1 s2 = x+(y+z)
A>
Во-первых пример притянут за уши — таким образом можно "показать" что у unsigned нет ассоциативности сложения.
Во-вторых — в любой нормальной реализации fixed-point, в примере выше s1 будет равно s2. При операции над типами разной точности делается promotion до самого точного — так работают встроенные типы, и так нужно по-возможности реализовывать пользовательские
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>А причём тут вообще литералы?
Как причем? Проблема продемонстрированная выше сотоит в том, что числа точно представленные десятичными литералами не представимы точно в двоичных float или double.
Числом с фиксированной точкой они будут представлены тоже точно, это понятно.
EP>Расчёт процентов и налогов — вообще не в кассу — там десятичные дроби, которые, при достаточной разрядности fixed-point, представляются в точном виде
И какой НДС с суммы продаж 100 руб. НДС включая при ставке 10% ?
Нужно согласовывать с пользователем что и на каком шаге округляется. Нужно прорабатывать с ним сценарии, чтобы он видел на что подписывается. А когда всё проговорено, то реализацию можно что на том подходе, что на этом. Топикстартер же пытается от разговора с клиентами уклониться и решить проблему математически. 
Перекуём баги на фичи!
Проблема продемонстрированная выше сотоит в том, что числа точно представленные десятичными литералами не представимы точно в двоичных float или double.