Опасно ли переходить из поплавка в BigDecimal и обратно? - PullRequest
5 голосов
/ 31 марта 2012

Я нахожусь в процессе создания программы, которая генерирует тестовые векторы для использования в тестовом стенде VHDL. Тестовый стенд по существу тестирует аппаратное обеспечение, которое действует как сумматор с плавающей запятой одинарной точности, поэтому векторы будут соответствовать стандарту IEEE 754.

В любом случае, мой текущий план генерации - преобразовать значения с плавающей точкой в ​​BigDecimal, выполнить необходимую арифметику, а затем преобразовать обратно в число с плавающей точкой. Это опасно? Будет ли потеряна точность, приводящая к потенциально неточному результату в тестовом векторе? Я хочу преобразовать в BigDecimal, чтобы избежать проблем с округлением.

Так бы это усекло результат?

BigDecimal repA = new BigDecimal(Float.toString(A));
BigDecimal repB = new BigDecimal(Float.toString(B));
BigDecimal repResult = repA.add(repB);
float result = repResult.floatValue();

Где A и B - некоторые поплавки.

1 Ответ

5 голосов
/ 31 марта 2012

Если ваша цель состоит в том, чтобы иметь точные 32-битные векторы с плавающей запятой в пределах ожидаемых ограничений числа с плавающей запятой, тогда мне нравится ваш подход. Сначала вы конвертируете 32-битное значение с плавающей точкой в ​​объект с более высокой точностью, выполнив несколько шагов по математике, а затем снова вернетесь к 32-битной переменной с плавающей точкой. В конце концов, ваши ошибки округления будут, вероятно, ниже, чем если бы вы выполняли ту же серию шагов изначально в 32-битных числах.

Если ваша цель состоит в том, чтобы точно смоделировать ожидаемые результаты аппаратного обеспечения, которое выполняет вычисления с использованием 32-разрядных операций с плавающей запятой, то вы можете подвергнуться риску ложного сообщения о сбое теста, поскольку ваши вычисления выполняются с большей точностью, чем проверяемое оборудование.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...