Eli Balta

So it seems that this happens due to built-in C++ conversion rules for ternary operator assignments or otherwise. Usage of the const int expression 0 causes the compiler to down-convert the half argument to float, and then float to int in order to perform the comparison. Afterwards converting the int result back to float and assigning it to the result via using half& operator=(float rhs) I've found that disabling all the operators in the library which specify (float rhs) as their signature helps...

So it seems that this happens due to built-in C++ conversion rules for ternary operator assignments or otherwise. Usage of the const int expression 0 causes the compiler to down-convert the half argument to float, and then float to int in order to perform the comparison. Afterwards converting the int result back to float and assigning it to the result via using half& operator=(float rhs) I've found that disabling all the operators in the library which specify (float rhs) as their signature helps...

So it seems that this happens due to built-in C++ conversion rules for ternary operator assignments or otherwise. Usage of the const int expression 0 causes the compiler to down-convert the half argument to float, and then float to int in order to perform the comparison. Afterwards converting the int result back to float and assigning it to the result via using half& operator=(float rhs) I've found that disabling all the operators in the library which specify (float rhs) as their signature helps...

So it seems that this happens due to built-in C++ conversion rules for ternary operator assignments or otherwise. Usage of the const int expression 0 causes the compiler to down-convert the half argument to float, and then float to int in order to perform the comparison. Afterwards converting the int result back to float and assigning it to the result via using half& operator=(float rhs) I've found that disabling all the operators in the library which specify (float rhs) as their signature helps...

So it seems that this happens due to built-in C++ conversion rules for ternary operator assignments or otherwise. Usage of the const int expression 0 causes the compiler to down-convert the half argument to float, and then float to int in order to perform the comparison. Afterwards converting the int result back to float and assigning it to the result via using half& operator=(float rhs) I've found that disabling all the operators in the library which specify (float rhs) as their signature helps...

So it seems that this happens due to built-in C++ conversion rules for ternary operator assignments or otherwise. Usage of the const int expression 0 causes the compiler to down-convert the half argument to float, and then float to int in order to perform the comparison. Afterwards converting the int result back to float and assigning it to the result via using half& operator=(float rhs) I've found that disabling all the operators in library which specify (float rhs) as their signature helps catch...

Hi Christian, thanks for your reply. I've done some further testing regarding this issue and found some strange and interesting results. This is probably beyond the scope of this forum since it is probably related to C++ behavior in general, rather than the half precision library specifically. Nevertheless, I'd like to share my findings here. #define MAX(a,b) (((a)>(b)) ? (a) : (b)) Example 1: half myvalue = half(49.625f); half result = MAX(0, myvalue); std::cout << std::hex << "0x" << myvalue.data_...

Hi, I've noticed that the only assignment operator implemented in the library looks like this: half& operator= ( float rhs ) And internally it performs conversion to/from float if the original argument is a half-precision value. This sometimes causes somewhat unexpected behavior. Consider the following example: half_float::half value_a = SomeCalculationResult(); //let's say the result is 49.625 or 0x5234 half_float::half value_b = value_a; //the value stored in value_b is now 49.0, or 0x5220 I suppose...