Странное поведение при сравнении литого поплавка с нолем

Question

В настоящее время я пытаюсь подробно узнать о представлении с плавающей запятой, поэтому я немного поиграл. Делая это, я наткнулся на какое-то странное поведение; Я не могу понять, что происходит, и я был бы очень благодарен за понимание. Извиняюсь, если на это был дан ответ, мне было довольно сложно Google!

#include <iostream> 
#include <cmath> 
using namespace std; 

int main(){ 

  float minVal = pow(2,-149); // set to smallest float possible 
   
  float nextCheck = static_cast<float>(minVal/2.0f); // divide by two 
  bool isZero = (static_cast<float>(minVal/2.0f) == 0.0f); // this evaluates to false 
  bool isZero2 = (nextCheck == 0.0f); // this evaluates to true 
  cout << nextCheck << " " << isZero << " " << isZero2 << endl; 
  // this outputs 0 0 1 
   
  return 0; 

} 

По сути то, что происходит это:

• Я поставил MINVAL быть наименьшим поплавок, который может быть представлен с использованием одинарной точности
• разделив на 2 должны давать 0 - мы на минимум
• Действительно, isZero2 действительно возвращает true, но isZero возвращает false.

Что происходит - я бы подумал, что они идентичны? Компилятор пытается быть умным, говоря, что деление любого числа не может привести к нулю?

Благодарим за помощь!

Answer 1

Причина isZero и isZero2 могут оценить различные значения, и isZero может быть ложным, является то, что компилятор C++ разрешено осуществлять промежуточные операции с плавающей точкой с большей точностью, чем тип выражения будет указывать, но дополнительные точность присваивается при назначении.

Как правило, при генерации кода для 387 исторического FPU сгенерированные инструкции работают либо с 80-битным типом расширенной точности, либо, если FPU установлен на 53-битное значение (например, в Windows), странный тип с плавающей точкой с 53-битными знаками и 15-битными показателями.

В любом случае, minVal/2.0f оценивается точно потому, что диапазон экспонентов позволяет его представлять, но присвоение его nextCheck округляет его до нуля.

Если вы используете GCC, есть дополнительная проблема, что -fexcess-precision=standard еще не реализован для интерфейса C++, что означает, что код, сгенерированный g ++, не реализует точно то, что рекомендует стандарт.