However my argument is still that these algorithms are O(m+n) and whatever optimization you perform you can't change that.

And yet they perform and scale in entirely different ways, which makes the big-O assessment, regardless of it's numerical value, as useful as a chocolate teapot.

And in fact the buk() function is a variation of the Bloom Filter. The only difference is that in your code you use one hash function which is f(x)=x. In the real Bloom Filter k hash functions are used, which makes this algorithm probabilistic.

I'm sorry, but that is just plain wrong! Actually, I going to say that rather more assertively. That is unmitigated and unmitigable, 100% pure bovine droppings. It is the intellectual equivalent of saying:an F1 car is a variation on an airplane; it's just that it's wings are on upside down.

The mathematicians trick of applying an identity function to a variable in order to re-categorise the situation doesn't work here, just as turning an F1 car upside down won't allow you to fly. It might allow you to drive upside down (on the roof of a tunnel given sufficient forward momentum), but it still wouldn't be flying.

The defining characteristic of a Bloom Filter is that it is non-determanistic. If it ain't non-determanistic, it ain't a Bloom Filter!

Bloom Filters were invented in 1970. Lookup tables have existed for hundreds, if not thousands of years. Seaman were using them at least as early as the 15th or 16th century. It might be correct (though still a stretch), to describe a Bloom Filter as a non-determanistic variation of a lookup table, but the reverse is and never will be true.