Is a*b < a for 0 <= b < 1 in IEEE floating point with positive a?

Question

I am writing in C++, using conformant IEEE arithmetic in round-to-nearest mode. If a is a positive short int (16 bits) and b is a float (32 bits), where 0 <= b < 1, does a*b < a always evaluate to true?

Answer 1

Maybe. It depends on how the compiler decide to evaluate floating-point expressions (read about FLT_EVAL_METHOD, invented by C99 but now part of the C++ standard, if you want the gory details.)

As soon as a can be greater than 4, the product a*b expressed as a float will round up to a when b is "big enough", for example b = 1-ε/2 (where ε is the difference between 1.0 and the next representable number, 2^-23.) But if the compiler does not perform the rounding in the intermediate evaluation, before the comparison, then the product may be kept in some (better) internal precision where a*b is still different from a, and the comparison done on that internal precision will be always asserted. And this case is not uncommon: because of the design of the x87 coprocessor, keeping all results as 64-bit long double was typical of 32-bit x86 architecture, for example; 53-bit double would also keep all values separate, since 24+16<53.

Assuming there are no bugs in your compiler, a explicit cast to float should force the rounding, so (float)a*b < a should evaluate sometimes to false. Be specially cautious here, since this area is known to show compiler bugs, particularly since floating-point is declared "reserved to experts" and programmers are generally advised to not rely on details like these. You should particularly take care to not activate the optimization options (like /fp:fast) of your compiler, which are very likely to skip the rounding operation to improve performances.

A safer (but still not completely safe) way to perform the test is to explicitly store the result of the multiplication into a float variable, like in

float c = a * b;
  if (c < a) call_Houston();

Here again, the C++ standard require explicit rounding (which is quite logical since the representation of the expression has to be stored into the 32-bit float variable.) But here again, some clever compilers, particularly when in optimization mode, might guess that the expression is reused just after, and could take the short path and reuse the in-register evaluation (which has more precision), and ruin your efforts (and left Houston unaware.) The GCC compiler used to recommend in such case to beg the compiler with code like

volatile float c = a * b;
  if (c < a) call_Houston();

and goes to specific options like -ffloat-store. This does not prevent loss of sanity points. BTW, recent versions of GCC are much more sane on this respect (since bug323 is fixed.)