有什么办法可以制作一组具有公差并且仍然是 O(1) 查找的浮点数？

Question

I want to make a set of floating point numbers, but with a twist:

When testing if some float x is a member of the set s, I want the test to return true if s contains some float f such that

abs(x - f) < tol

In other words, if the set contains a number that is close to x, return true. Otherwise return false.

One way I thought of doing this is to store numbers in a heap rather than a hash set, and use an approximate equality rule to decide whether the heap contains a close number.

However, that would take log(N) time, which is not bad, but it would be nice to get O(1) if such an algorithm exists.

Does anyone have any ideas how this might be possible?

Answer 1

If you're not too fussy about the tolerance, then you can round each number to the closest multiple of tol/4.

You can then use a hash map, but when you add a number x, add floor(4x/tol), floor(4x/tol+1) and floor(4x/tol-1).

When you look up a number x, look up floor(4x/tol), floor(4x/tol+1) and floor(4x/tol-1).

You will certainly find a match within tol/2, and you may find a match within tol.

Answer 2

Two ideas I had (and by no means are these necessarily the best):

1.) Mask the lower N bits of the number to all 0's. For instance, if you want the tolerance to be approx. 1E-3, force the lower 10 bits of mantissa to 0 when adding. Do the same when checking.

One caveat of this approach is that real computers often do weird things to LSB's of mantissas when you're not looking. You store x = b00111111100000000000000000000000, and when you retrieve it you get 00111111100000000000000000000001, 001111110111111111111111111111111, etc. The reasons for this are many, but the bottom line is that it's still brittle. Anything that relies on float equality is brittle.

2.) Create a hashable data structure containing the different fields from an IEEE-754 float separately. Why do that? you ask. The reason is twofold:

A.) By using an object that isn't a float, you prevent the runtime from treating this number as a float. I know it shouldn't matter, but I've seen LSB's mangled so many times it obviously matters even if it's hard to say why. This overcomes one caveat with storing a multiple of tol/4 as a float . I like the idea of rounding a number to a multiple of tol. The only downside is that if you store the number as a float the runtime can still mangle LSBs, which is the original motivation for this question.

B.) You can store just the upper N MSB's of the mantissa - in other words, choose N such that 2**-N represents a relative tolerance you like.

This captures the idea of rounding to multiple of tol, but also doesn't tell the runtime and/or CPU that this is a float, thereby preventing LSB mangling.

Interested to hear other ideas, critiques, etc.

Answer 3

Rather than another set, adjust meaning of "close".

Create a function that maps each finite float to an integer.

Mentally place every positive float in a list - sorted by value. 0.0 is at index 0 and MAX_FLOAT is at index N . (Likely-wise for negatives: -MAX_FLOAT to -0.0 maps to -N to 0.total ordering

To find if 2 float values are "close", subtract their indexes and compare to a tolerance.

This maintains the idea of float in floating-point numbers as the tolerance is a fixed integer in the index mapping domain, yet scales in the float domain.