4 ms·
> 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
by moonchild 4y ago
> 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
For Word, the condition 'r - l > 1' is true in all cases where l>r.
- tromp 4y ago> For Word, the condition 'r - l > 1' is true in all cases except when r=l. Simplest counterexample: (l,r) = (0,1) > For Word, the condition 'r - l > 1' is true in all cases where l>r. Simplest counterexample: (l,r) = (1,0), although one should always have l <= r.
- henrydark 4y agoThe predicate given is monotonic in the range 0.,100.. using the floating point bit representation (with appropriate starting l, r as they have) gives (a) best possible convergence rate - one bit per iteration. Using floating point math would also have this converge rate, but the halting condition would be interesting. Do you use the smallest epsilon? Alternatively, do you check that the midpoint is one of l,r? Both approaches require you know a little something about floating point numbers, and I'd say it's mostly an esthetic choice, especially since the convergence rate is the same.
- moonchild 4y ago> the halting condition would be interesting For l,r known to be positive: l*(1+(2^-52)) < r. Substitute 2^-23 for single-prec floats. > Using floating point math would also have this converge rate As I said, it does not; using float math has a less predictable convergence rate. With float math, you'd halve the magnitude of the search space every iteration, whereas with integer math, you'd halve the number of floating-point numbers contained in the range.
- henrydark 4y agoBoth methods give you a bit of information per iteration. The number of distinct floating point numbers between l,r is the same as the number of integers in the reinterpretation of l,r as integers. (assuming starting l,r were appropriate)
- moonchild 4y agoSuppose l=1, r=3. So m=(1+3)/2=2. There are twice as many floating-point numbers between 1 and 2 as between 2 and 3. So if you refine from [1 3] to [1 2], you've only managed to prune 1/3 of your search space, not 1/2. (Also: integer halving breaks when l and r have opposite signs.) Perhaps this will make it clearer: suppose we have l=0 and r=1, and the number we're searching for is the smallest float, 2^-1074. If we use integer halving, we get one bit per iterations; floats have 64 bits, so we should require no more than 64 iterations. But if we use floating-point halving, obviously it will take 1074 iterations to get from [0 1] to [0 2^-1074].