Здравствуйте, Marty, Вы писали:

M>Например, какую-нибудь статистику считать. Банковское округление оно не только "банковсеое", но и статистическое.
В статистике точность определяется количеством значащих цифр, а не способом округления. Как в большинстве других областей деятельности, где нужна арифметика. В финансах есть особенность — вынужденное (и объективно необходимое) округление до минимальной денежной единицы. Но и там полезность "банковского" округления совсем не очевидна.

Здравствуйте, netch80, Вы писали:


N>Ну вот тут таки кажется, что ты теряешь вариант типа 23.51, 23.501, 23.5001... этот precisionFitTo, если просто обрубает хвост, то теряет важные цифры на таких пограничных значениях.
N>Причём это будет касаться не только roundHalfEven, но и, например, roundCeil для 23.01. Первым рывком ты урезаешь до 23.0 отсекая хвост, потом видишь 0 и останавливаешься на 23, когда должно быть 24.

N>Добавь тесты на значение типа 23.01, 23.001, 23.51, 23.501 и проверь. Для полного набора ещё включить 23.49, 23.499, 23.99, 23.999.

N>Имеет смысл переделать эту precisionShrinkTo с возвратом, например, bool-признака "было ли ненулевое в отсечённой части" (назову его sticky по традиции). А дальше по этому признаку, например:


Ага, добавил тестов, и оно сломалось. Переделал по твоему совету.


N>Ещё очень полезно перемапить режимы округления на основании знака и после этого работать только с мантиссой, например:
N>...

N>а в switch оставить только уменьшенный набор и уже не смотреть на знак.
N>Это я в том же Berkeley Softfloat увидел.

Угу, и это тоже переделал по твоему совету.

Сорян, что "Спасибо" сразу не сказал, был в бане


Да, сейчас вот вообще всё переделал на "честном" десятичном числе, но округление переехало практически без изменений