> we can also do exact binary search on the bit representations of floating-point numbers! That is, we do binary search as if the bit representations of l and r were unsigned integers. This is possibly more efficient than “continuous” binary search, and lets us find the two precisely adjacent floating-point numbers where our predicate switches from False to True.
Why is it better to use integer operations than with floating-point operations? Assuming everything is inlined and type-inferred away, float math should be faster, and just as precise.
One may argue that the convergence rate is less predictable; but this may be a feature, if the predicate under consideration is not quite monotonic (monotonicity is hard to guarantee when negative numbers are involved--though '\x -> x^2 >= 150' is straight up not monotonic, both mathematically and numerically).
> It even works when l is negative and r is positive (it seems like in that case the bit representation of l would correspond to a larger unsigned integer than r, but somehow it all works anyway!).
It's because of underflow:
ghci> (unsafeCoerce (-100.0) :: Word) - (unsafeCoerce 100.0 :: Word)
9223372036854775808