Методология Math.Round, начиная с наименьшего десятичного знака - PullRequest
Новая
       3

Методология Math.Round, начиная с наименьшего десятичного знака

7 голосов
/ 27 августа 2010

Было много потоков, начатых из-за путаницы в том, как работает Math.Round. В большинстве случаев на них отвечают, подсказав людям параметр MidpointRounding, и большинство людей ожидают MidpointRounding.AwayFromZero. У меня есть еще вопрос по поводу фактического алгоритма, реализованного AwayFromZero.

Дано следующее число (результат ряда расчетов): 13.398749999999999999999999999M

наши пользователи ожидают увидеть тот же результат, что и Excel * 13.39875. Поскольку в настоящее время они округляют это число до 4, используя Math.Round (num, 4, MidpointRounding.AwayFromZero), результат будет на 0,0001 меньше ожидаемого. Предположительно, причина этого в том, что алгоритм просто смотрит на пятую цифру (4), а затем округляет соответственно. Если бы вы начали округлять последние 9, реальный математический ответ на самом деле дал бы вам то же число, что и в Excel.

Итак, вопрос в том ... есть ли способ эмулировать это поведение, а не текущее?

Я написал рекурсивную функцию, которую мы могли бы использовать за это время. Но прежде чем мы запустили его в производство, я хотел посмотреть, что SO думает о проблеме: -) 

    private decimal Round(decimal num, int precision)
    {
        return Round(num, precision, 28);
    }

    private decimal Round(decimal num, int precision, int fullPrecision)
    {
        if (precision >= fullPrecision) return Math.Round(num, precision);

        return Round(Math.Round(num, fullPrecision), precision, --fullPrecision);
    }

Редактировать: просто для ясности, я должен был быть более ясным в моем первоначальном посте. Спрашиваемая здесь методология округления заключается в том, что меня представляют бизнес-аналитики и пользователи, которые сообщают о «ошибке округления». Несмотря на то, что мне неоднократно говорили, что это не неправильно, просто отличается от того, что они ожидают ... этот отчет продолжает поступать. Так что я просто собираюсь ограничиться сбором данных, чтобы собрать как можно больше информации по этой теме, чтобы сообщить о ней обратно пользователи.

В этом случае, похоже, что любая другая система, используемая для генерации этих средних цен (которым мы должны соответствовать), использует другую точность уровня (10 в базе данных, и для Excel по умолчанию, по-видимому, 15 или около того) , Учитывая, что у всех разный уровень точности, я застрял в середине вопроса о переходе на более низкую точность, о некоторых странных правилах округления (как описано выше) или просто о результатах, отличных от ожидаемых пользователями.

Ответы [ 2 ]

3 голосов
/ 27 августа 2010

Если я правильно вас понял, люди ожидают 13.3988, потому что они сначала округляются до 13.39875, а затем до 13.3988, и им нужно, чтобы вы были совместимы с ошибками.

Если это так, нет необходимости повторять более одного шага округления, поскольку недостаток в их методе проявляется только на последнем шаге округления (по своей природе округление устраняет значение шага на два шага перед ним ). 

private static decimal InaccurateRound(decimal num, int precision)
{
  return Math.Round(
    Math.Round(num, precision + 1, MidpointRounding.AwayFromZero),
    precision, MidpointRounding.AwayFromZero);
}
3 голосов
/ 27 августа 2010

Итак, если вы округлите это число до 5 мест, а затем округлите результат до 4 мест ... Вы получите другой результат, чем если бы вы просто округлили исходное число до 4 мест? Это ожидается. И я думаю, это объясняет, что вам нужно сделать. Другой вариант - сделать так, чтобы Excel показывал полную точность, чтобы «они» округлялись так же, как и ваш код. Двойное округление кажется неправильным.

...