Здравствуйте, 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 увидел.
Угу, и это тоже переделал по твоему совету.
Сорян, что "Спасибо" сразу не сказал, был в бане
Да, сейчас вот вообще всё переделал на "честном" десятичном числе, но округление переехало практически без изменений