Talk:Bloom filter

message: Maybe the following graph could be added to the "Probability of false positives" section.
--Jerz4835 (talk) 12:29, 12 March 2008 (UTC)
replies: text: The graph isn't really showing how "good" the bloom filter is, rather how various filter sizes and set sizes relate to the false positive rate. The probability axis emphasizes the area between 0 and 0.01 because differences there are a lot more meaningful than between, say, 0.99 and 1. Unfortunately I agree that it's not very clear at a glance, but I am no good at these types of visualizations and probably couldn't improve on it. Maybe someone else has ideas. Maghnus (talk) 04:11, 13 August 2010 (UTC)
thread_title:  A Graph 

message: False positives are silly in a spelling checker.  I think an example more like  should be used, with the secrecy thing mentioned elsewhere.  But my english very bad, so I leave in capable hands of brother and sister.  —Preceding unsigned comment added by 220.233.116.128 (talk) 16:19, 9 January 2008 (UTC)
thread_title:  The example 

message: I propose changing insert to add and test membership to query.  I think add better matches what actually happens and query is just more concise.  --Pfunk42 22:42, 1 Jun 2005 (UTC)
thread_title:  Operation Names 

message: I propose changing discoverer in "...named after its discoverer Burton H. Bloom," to inventor. Algorithms like this aren't 'discovered' so much as invented.
:I tried "conceived by" whoever in year whatever, a pattern I've seen elsewhere. Deco 01:21, 5 Jun 2005 (UTC)
thread_title:  Discoverer? 

message: It feels like you can't. This should probably be emphasized in the article, as this is a distinction from similar data structures. It's mentioned in the intro, but then never discussed...I don't have the technical expertise to say definitively how to handle this, so I can't write it up myself. -- Metahacker 15:32, 21 Jun 2005 (UTC)
replies: text: Good idea. I added a short explanation. You think it'll do? Deco 19:46, 21 Jun 2005 (UTC)

text: The problem with that idea is that the Bloom filter corresponding to "universe minus my element" will almost certainly be identical to the Bloom filter corresponding to "entire universe". You'll never introduce a false negative, but you will usually introduce false positives — that is, if you take the Bloom filter for (A,B,C) and try to subtract out (B) using your method, you'll probably end up with the Bloom filter for (A,B,C). The "removal" didn't actually do anything! Hope this helps; also, check out the other variations mentioned on this Talk page. Some of them support removals, with various restrictions. --Quuxplusone 03:26, 15 April 2007 (UTC)

text: Yes, that's already in the article under Bloom filter#Counting filters. —David Eppstein (talk) 18:13, 17 April 2010 (UTC)
replies: text: What if you have a second Bloom filter, which stores a set of deleted items?  So, check the first Bloom filter to see if the item was (at some point) a member of the set, then check the second Bloom filter to see if it was deleted.  Of course, there is a downside: once an item is deleted, you can never add that item again, simply because there's still no way to delete something from the second Bloom filter.  Well, unless you have *another* Bloom filter for 'undeleted' items, but it's not a practical solution.  For applications where deletion is irrevocable (such as with SSL certificates), this may be an extremely desirable feature. 208.81.212.224 (talk) 19:04, 24 October 2013 (UTC)
replies: text: False positives in the second filter could be a problem... They would eliminate one of the more useful properties of Bloom filters, that its errors are only one-sided. —David Eppstein (talk) 19:12, 24 October 2013 (UTC)
thread_title:  Removing from a Bloom filter 

message: You could implement a voting algorithm in a single bit Bloom filter to allow both adds and deletes, at the cost of admitting false negatives, with an add setting k hash-bits, and a delete clearing k hash bits. The difference from an ordinary Bloom filter would be that the decision threshold would be less than requiring all k bits to be set for a rejection: for example, say, k/2, for say k=20. In this way, although both false-positive and false-negative results would be possible, the threshold factor could be tuned to give low error rates for both types of error. 
Has anyone done this? Or are multi-bit Bloom filters simply superior? Inquiring minds weant to know. -- The Anome 13:54, September 9, 2005 (UTC)
:Good question. I can't imagine why nobody's thought about this already, it's pretty obvious considering the implementation of your average BPP algorithm. I shall have to ask some people about it. Dcoetzee 08:03, 28 May 2007 (UTC)
thread_title:  Adding and removing in a single-bit Bloom filter 

message: Riffing on The Anome's suggestion above: You could also implement a "counting" Bloom filter, by using b bits per hash instead of only one. For example, using b=2, you'd replace Bloom's array of m bits with an array of m 2-bit counters. Adding an element would increment all k relevant counters; if any counter was already at 3, it would "stick" there instead of wrapping around. Therefore, a count of 0 represents "absence," and a count of 1 or 2 indicates 1 or 2 entries sharing that counter. A count of 3 indicates at least three entries sharing that counter.
To remove an element, you'd decrement all k relevant counters, except for those counters that contained 3 — such a counter you'd leave at 3, since to decrement it would falsely imply that it was shared by exactly two entries.
This kind of "counting" Bloom filter would have all the problems with false positives of a normal Bloom filter, but it would allow a certain number of removals to proceed correctly. Add enough elements, though, and removals would stop working — you'd be unable to remove any element all of whose counters had maxed out.
I suspect that the added complexity of implementation wouldn't make a "counting" Bloom filter worth the trouble, but it's worth a mention on this Talk page, at least. :) --Quuxplusone, 19:06, 18 March 2006 (UTC)
replies: text: . Quuxplusone, that's a great idea, now in the article at Bloom filter#Counting Bloom filters. --DavidCary (talk) 16:52, 27 December 2020 (UTC)
thread_title:  Adding and removing in a counting Bloom filter 

message: A bloom filter is a bloom filter - a counting bloom filter is a different beast with enough different permutations to discuss for the rest of eternity.
Break it into two - at least
: . That's been broken off into the counting Bloom filter article. --DavidCary (talk) 16:52, 27 December 2020 (UTC)
thread_title:  You should break this into multiple pages 

message: Don't mean to be a wank, but has the "Generalized Bloom Filter" thingy been accepted into a peer-reviewed publication?
Regardless, the author should stick in info on how much bigger than a regular BF a GBF that uses ones and zeros needs to be to have the same false positive rate.  Oh, I see.  You forgot to mention that because it's A LOT (many times) bigger.  ;) --pfunk42 04:35, 28 May 2007 (UTC)
thread_title:  Generalized 

message: The events of each particular bit being 1 are not independent.  Intuitively, if you know the first bit mapped to 1, it suggests the array is more dense.  That is, the probability the second bit maps to 1 given that the first did is greater than the probability the second bit maps to 1 given the first mapped to 0 (or say, given no other information). 128.2.16.192 22:49, 27 September 2007 (UTC)
replies: text: First of all, i would call it an "analysis", not a "proof".  And, in fact, this is an average case analysis, because it doesn't take into account the fact that the number of bits set in the Bloom filter from n additions follows a probability distribution, and with random hash functions, the number of set bits determines the false positive probability.  Thus, adding n things to a Bloom filter doesn't always result in a certain false positive probability--you might get lucky or unlucky.  But the variance is small.  There are possibly some other suble, mostly insignificant inaccuracies in that  formula.  See this paper for what seems to be a more detailed analysis, but it has not, to my knowledge been accepted under peer review.  --pfunk42 05:32, 30 September 2007 (UTC)
thread_title:  Proof of false positive probability is wrong 

message: What are bloom filters used for? Any applications people can think of should be put in the intro. Fresheneesz 02:09, 16 October 2007 (UTC)
replies: text: No. Any applications people can source should be put into later parts of the article, and (per WP:LEDE) mentioned briefly in the intro. —David Eppstein 02:47, 16 October 2007 (UTC)
replies: text:  I agree with both of you -- this article should mention some applications, but in an "applications" section rather than the intro. It appears that has been done already with the Bloom filter#Extensions and applications section. Would it be better to split that section up into an "applications" section and a "extensions"/"generalizations" section? --DavidCary (talk) 21:29, 24 December 2020 (UTC)
thread_title:  What are they used for? 

message: if it gives "false positives" and "correct negatives" then it must be used to find whether element is *not* in a set (and so one would be 100% sure). maybe this article could be change according to it. 84.16.123.194 (talk) 15:47, 28 January 2008 (UTC)
replies: text: I know this is old but this conclusion is either slightly incorrect or just poorly phrased. Bloom Filters are used to filter things out but not to conclusively determine whether an element is not in a set since it can return a "maybe" result. You can sometimes use it to avoid doing more expensive lookups/calculations if the Bloom Filter first determines your element is NOT in the set. 209.131.62.115 (talk) 05:49, 16 November 2013 (UTC)
thread_title:  meaning of bloom filter 

message: Can anybody provide a description of various techniques for decaying bloom filters? Google has hits for several different terms, "Scope Decay", "Deterministic Decay", "Time Decaying", etc. I conjecture this is a way to stochastically remove no longer relevant members from the set, but  the articles I've found all require various subscriptions. nuffin (talk) 20:25, 26 July 2008 (UTC)
thread_title:  Decay? 

message: It would be helpful to note that the number of bits in the filter (m) should be a multiple of the expected number of elements (usually called n in the papers).  Not as obvious as you might think.  Could save someone's afternoon, a note like that...  —Preceding unsigned comment added by 208.85.112.97 (talk) 15:15, 24 September 2008 (UTC)
thread_title:  Filter size (''m'') 

message: Everything in the section "Probability of false positives" is verifiable from basic principles of mathematics and science by following the author's reasoning, thus the demand for proper authoritative sources is a rejection of science and the scientific method.
This section not original research, rather it is replicated research that each one and every one should replicate.
Roger Bacon was the first scientist since because insisted on observing things for himself and urged others to do the 
same.  If Wikipedia prohibits people from doing the same, it becomes the holy book of a scientistic religion.
The motto of the Royal society was "Nullius in verba" meaning "Take no one's word for it".
Wikipedia is scientifically and morally wrong to demand that people take someone else's word for things.  Replicability, not proper authority is the gold standard of truth.
James A. Donald (talk) 02:48, 13 January 2010 (UTC)
replies: text: Technically, a citation is required for the jump from (1-(1-m)^kn)^k to (1-e^(-kn/m))^k, since that requires some level of calculus.  A better reason for removing the tag is that it echoed information found in an external link (and also has a hard reference), rather than complaining that Wikipedia doesn't follow the scietific method of more formal peer review.  --Sigma 7 (talk) 18:51, 17 April 2010 (UTC)
thread_title:  Probability of false positives - demand for sources is a rejection of science and the scientific method. 

message: Saying that a Bloom Filter at k=1 is a special kind of Hash Table (in the Space & Time Advantages section) seems counter intuitive. Hash Tables are deterministic and a Bloom Filter with k=1 is exactly what is described, not a surprising anomaly having to do with what happens when a Hash Table no longer checks for collisions and uses single bits rather than full entries.
Specifically, "Note also that hash tables gain a space and time advantage if they begin ignoring collisions and store only whether each bucket contains an entry; in this case, they have effectively become Bloom filters with k = 1." should be removed for conciseness.
 Rbkillea (talk) 22:08, 6 December 2011 (UTC)
thread_title:  Hash Tables are no longer Hash Tables when they are Bloom Filters 

message: I am going to be borrowing from another page, called a 'quotient filter', which is a derivative data structure which came from the idea of a bloom filter.  It's usage, design, and purpose are exactly the same as a bloom filter, however, its implementation was performed in a way that 'enhances' what a bloom filter fails to do - where we can see in the bloom filter article that it needs restructured, which is a total restructure, as n changes.  
Here are the changes I am proposing:
1.  --> Clarify Introductory paragraphs to more accurately represent what the data structure is, what it is intended to be used for, and what it does and does not do.
[note] then add this (an important piece of information borrowed from quotient filters.  I borrowed this from quotient filters, which has the exact same properties of a bloom filter only its internal representation is different.  Both a bloom filter and a quotient filter are equivalent data structures - probabilistic data structure filters...  This is a better description of what a bloom filter is, what it is used for, and why secondary storage is needed.  A bloom filter cannot resize without storing keys - if you think it can, I would love to see you try and build a bloom filter that can rehash and resize for optimal m and k as per p and n.  In fact, I would take great pleasure at seeing you attempt this impossible programming feat:
"Each Bloom Filter is associated with a more space-consuming set, such as a B-tree and its variants, or other disk-based algorithms, and its contents are reflective of the associated set. As elements – key/value pairs – are added to the set, their keys are also added to the Bloom Filter. However the Bloom Filter stores only a few bits per key, whereas the set stores the entire key, which can be of arbitrary size; therefore, a Bloom Filter can often be memory-resident while the associated set is stored in slower secondary storage. Thus this association can dramatically improve the performance of membership tests, because a test that results in "negative" (definitely not in the set) can be resolved by the Bloom Filter without necessitating any I/Os to access the set itself.  The reason for having secondary storage, even though it is never accessed by the lookup operation for the stand-alone case of "negative" only lookups, is due to the fact that a bloom filter needs to resize according to the number of elements in the data set to account for optimally small false positive rates and therefore more definite "negative" results.  If the bloom filter is static, the probability suffers where its size and hash usage are constants.  A bloom filter cannot re-hash by itself, because it never stores any keys, only bits or numbers.  Therefore, in order to resize the bloom filter we must at least store the actual keys somewhere.  This gives the bloom filter the ability to re-hash, and therefore resize, without difficulty."
[note] Borrowing from 'Quotient Filter' page, 
2.  --> Algorithm Description section - careful on wording..
"To query for an element (test whether it is in the set), feed it to each of the k hash functions to get k array positions. If any of the bits at these positions are 0, the element is definitely not in the set – if it were, then all the bits would have been set to 1 when it was inserted. If all are 1, then either the element is in the set, or the bits have by chance been set to 1 during the insertion of other elements, resulting in a false positive. In a simple bloom filter, there is no way to distinguish between the two cases, but more advanced techniques can address this problem."
[note] The above paragraph just needs re-wording.  This is also a fact.  A bloom fiter cannot and never does say 'A contains x', it only says 'A may contain x with standard probability error p', basically meaning the only definitive test is 'x is not in A' - but that isn't even definitive, since as the bloom filter fills up, 'x is not in A' becomes 'A may contain x with standard probability error p'  These are facts about the data structure.  The more advanced techniques refer to other sections of this article...
"To query for an element (test whether it might be in the set), feed it to each of the k hash functions to get k array positions.  If any of the bits at these positions are 0, the element is definitely not in the set - if it were, then all the bits would have been set to 1 when it was inserted.  If all are 1, then either the element is in the set, or it actually is not (a collision resulting in a false positive).  More advanced techniques work out the problems of a normal bloom filter - such as dynamic resizing, allowing removal, and maintaing a preferable false positive rate."
[note] and the following paragraph
"One-time removal of an element from a Bloom filter can be simulated by having a second Bloom filter that contains items that have been removed. However, false positives in the second filter become false negatives in the composite filter, which may be undesirable. In this approach re-adding a previously removed item is not possible, as one would have to remove it from the "removed" filter."
[note] should read - this is factual.  A bloom filter cannot be resized without rehashing, and most bloom filters are not constant-sized arrays.  Therefore, if you want to resize a bloom filter secondary storage of keys is required.  A scalable bloom filter does address the problem of resizing.  Cite Scalable Bloom filter for more info, these are borrowed from the respective links to articles.:
"More advanced algorithms resolve the problem of not being able to remove from a bloom filter.  Additionally, a bloom filter cannot be resized - in most proposed bloom filter algorithms there is no way to re-hash, since no keys are stored.  A Scalable Bloom Filter addresses this problem.  Additionally, if the actual keys are stored in secondary storage, this gives the bloom filter the ability to resize and re-hash, therefore implying that we can choose an optimal m and k for any p and n."
[note] The following should be added to algorithm description/merged into it somewhere.  This is also fact.  A bloom filter only says 'x maybe is in the set' or 'x is not in the set'.  The probability of false positives is a probability application.  Following probabilistic math, this means that if you have a 1% chance of error, then 1/100 queries, based on that probability, will return a false positive, on average.  However, this is not exact - as you can see the probability of flipping a coin is 1/2, but usually by the sixth time you flip it will land on a different side eventually.  This is a fact of probability.  It is also fact that as the bloom filter fills up, if it doesn't resize itself, p will rise.  This means more false positives and also less definitive negatives.  That is a fact.  The only way to have a constant bloom filter with acceptable p is to set its initial size arbitrarily large - which defeats the purpose of memory efficiency and also increase k, which worsens performance - usually to six hashes, according to your formulas...
"A bloom filter resolves two situations.  The first is when a program only wishes to know whether an item is definitely not in the set.  In this situation, a bloom filter can be used as a stand-alone data structure.  However, if the program wants to know whether an item definitely is in the set, an accompanying data structure must be utilized.  The reason for an accompanying data structure in the latter case is because even though a bloom filter employs a 1% false positive rate storing fewer than 10 bits, and can be reduced easily to 0.1% - this still means that 1 out of every 100 or 1 out of every 1000 queries, respectively, will return a false positive in the general case; yielding an item that is not actually in the set when the bloom filter says it is.  As the data structure fills up and the bloom filter size in bits m and hash function numbers k are not set to ideal proportions of item numbers n, it becomes the case that the probability p will suffer, meaning higher chances of false positive lookups.  This is especially a problem when n is dynamic and the bloom filter cannot resize itself without total reconstruction, if that is possible according to the implementation of the bloom filter.  Therefore, care must be taken, unless using Scalable Bloom Filters, in choosing an optimal m and p."
[note] - this is also a factual statement.  What would you call hashing to the same bucket?  A collision.  However, bloom filters do not provide collision resolution - that is how it arrives as a probabilistic data structure.  Increasing false positive rates means that you have decreased the amount of definite negatives.  What is a false positive?  It is an item that is not in the set, but the bloom filter says it is.  What would the inverse of that situation be?  The bloom filter says it is not in the set.  Because false positives exist - a false positive is actually a negative.  Let x be 'maybe in Set' and y be 'not in set'.  As n increases, and the bloom filter does not resize, p increases.  As p increases, x gets bigger and y gets smaller.  In fact, false positives only exist because y gets smaller.  In other words, the negative members of x in a real data set would be members of y, or to put it more bluntly, false positives are members of y.  understood?  this is why you have an algorithm page that contradicts itself... 
"Because the margin of error is usually 1% to test if an item is in the set, the bloom filter cannot guarantee with 100% certainty that an item actually is in the set.  In fact, just like a hashtable; a bloom filter can have collisions.  A collision in a bloom filter is when an item lookup results in all 1s but is actually not in the set, meaning a false positive.  As the number of items it represents increases, the data structure, if left alone, continues to turn 'not in this set' to 'maybe in this set' - increasing false positive rates; also meaning negative results will dwindle to false positives.  An exhausted bloom filter, if it cannot be re-hashed, may get full at which point it considers almost everything 'a part of the set', and almost nothing 'not in this set'.  Hence the term probablistic bloom filter: it is a probablistic data structure, intended to be used as a filter."
[note] now the article does not conflict
3. --> Space and Time Advantages
[note] change the entire section to the following.  The following paragraph re-iterates the points made above..  It does you all no good to discuss calculations if you are using a constant size m.  Given a constant size m, why would you need to calculate m?  It would be a constant.  So would k.  Why do any calculation?  The only time this is fine is if n is also constant - which in practice, n is hardly ever constant size.  Therefore, if you do not resize, and therefore re-hash, and therefore need to store keys somewhere, then these calculations are meaningless.  That's why I propose you state the following:
Bloom filters with 1% error and an optimal value of k requires only about 9.6 bits per element - regardless of the size of the individual elements.  This advantage comes partly from its compactness, inherited from arrays, and partly from its probablistic nature.  The 1% false positive rate can be reduced by a factor of ten by adding only about 4.8 bits per element.  However, simple bloom filters and counting filters are static data sets - that also cannot be resized unless actual keys are stored somewhere.  This is because items that are inserted do not store their keys - there is no way to re-hash.  For this reason, we must either choose ahead of time an optimal, static m and then an appropriate k (meaning an unecessarily large data structure to account for any n items), or store the actual keys in secondary storage so we can re-hash the bloom filter and therefore acheive optimal, calculated m and k in accordance with any p and n.      
[note] - see usage examples and actually read them
Its general use is to accompany and filter unecessary disk I/O, or avoid similar more costly operations - but will come at the cost of memory consumption, as well as insertions, removals, and lookups being in addition to the underlying secondary data structure.  Filtering is employed to weed out what isn't in the set, but no matter how small the probability of false positives p, a bloom filter never says with absolute certainty whether or not an item is in the set - it just says it might be; and in addition it cannot find a nearest neighbor that definitely is in the set.  In this situation, the bloom filter serves to eliminate, sometimes dramatically, unecessary operations simply by ruling out what items aren't members of a set - which results in performance enhancements on the secondary data structure lookup.  See use cases below for examples of how this is used.
[note] - I do not see what's wrong with this statement, either.
For the case of lookups where the only concern is what definitely isn't in the set, it can be used as a stand-alone data structure; and in those cases it may be beneficial over other algorithms in terms of lookup speed 0(k) and memory consumption (m bits).  Note that a Scalable Bloom Filter may reduce the need for setting m higher than is necessary relative to a dynamic n, but so too can re-hashing and therefore calculating appropriate sizes of m and k.  If n is static, then m and k can easily be pre-calculated for optimization.  See use cases below for examples of how this is used.
[note] cited from article
An example of the problem in practice with bloom filters using up more memory than desired or is ideal was proven by : "Counting Bloom Filters (CBFs) are widely used in networking device algorithms. They implement fast set representations to support membership queries with limited error, and support element deletions unlike Bloom Filters. However, they consume significant amounts of memory..."  
[note] this is basically what you had, just re-worded slightly..
Bloom filters have the unusual property that the time needed either to add items or to check whether an item is potentially in the underlying data set is a fixed contant, 0(k) - where k is a multiple of hash functions, completely independent of the number of items already in the set.  These lookups can also be parallelized, even in a multithreaded environment.  This gives a bloom filter its main advantage over or in accordance with other data structures - like hashtables, tries, lists, or trees.  
[auth]Thank you - sorry it got heated.  All I wanted was for this page to get corrected and clarified.  One person actually posted on a site saying it was a form of a trie.  That is very incorrect, and I am assuming they got it off of this page..75.133.175.2 (talk) 18:54, 6 November 2013 (UTC)
replies: text: Re your point #1, please see WP:TECHNICAL. The lead is supposed to be for an easy-to-read introduction to the subject. It is not supposed to be the place to go into this level of detail. And your writing could use copyediting, e.g. the last sentence no verb. And your last sentence in your last point, "A Bloom filter must be accompanied by..." is simply blatantly, false. There are plenty of use cases for Bloom filters that do not accompany it with another data structure. —David Eppstein (talk) 19:09, 6 November 2013 (UTC)

text: I think we are still far apart. You seem to have a very dogmatic point of view about what operations must be supported to call something a set data structure. Dogmatism and opinions are not a good mix for editing here, where you need to back up things with reliable sources. What are your sources? —David Eppstein (talk) 06:58, 7 November 2013 (UTC)

text: I know what a set is. That wasn't the point, and cluttering up this talk page with copied and pasted definitions doesn't seem to be very constructive to me (nor does copying and reversing lines from my comments). The question was, what is your source for the assertions that Bloom filters are not data structures, do not (even approximately) represent sets, and can only used with an exact backing data structure? —David Eppstein (talk) 07:09, 8 November 2013 (UTC)
thread_title:  This page needs revision - conflicts, clarity, the rest can stay as-is 

message: The presentation might be clearer if we were to separate the formulas from their derivations in this section.  Anyone agree/disagree?  --Doradus (talk) 16:31, 8 November 2013 (UTC)
thread_title:  Separate derivation from results in the "Probability of false positives" section 

message: "With unlimited core memory an error-free hash eliminates all unnecessary disk accesses..."  Nice thought experiment, but back here in the 3rd dimension we could probably just say that an in-memory hash table based on some reasonable multiple of the size of your keys would suffice, and then from there go into how those requirements could be made lower with a compact Trie or a Bloom Filter.  -- The Arcadian  — Preceding unsigned comment added by 98.169.58.20 (talk) 21:34, 6 March 2014 (UTC)
replies: text: Some anonymous user rewrote all the hypotheticals leading to such sentences. Anyway, I've changed "unlimited" to "sufficient", etc.  Shreevatsa (talk) 10:36, 7 March 2014 (UTC)
thread_title:   Imagine A World With An Infinitely Sparse Hash Table 

message: Hello fellow Wikipedians,
I have just modified  on Bloom filter. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added archive https://web.archive.org/web/20070202202510/http://www.arl.wustl.edu:80/~sarang/ancs6819-dharmapurikar.pdf to http://www.arl.wustl.edu/~sarang/ancs6819-dharmapurikar.pdf
*Added archive https://web.archive.org/web/20090517023058/http://adetti.iscte.pt:80/events/CONEXT06/Conext06_Proceedings/papers/13.html to http://www.adetti.iscte.pt/events/CONEXT06/Conext06_Proceedings/papers/13.html
*Added archive https://web.archive.org/web/20070114035556/http://www.cs.utexas.edu:80/users/simha/publications/lsq.pdf to http://www.cs.utexas.edu/users/simha/publications/lsq.pdf
When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at ).
Cheers.—InternetArchiveBot (Report bug) 09:55, 4 November 2016 (UTC)
thread_title:  External links modified 

message: A browser incompatibility is affecting the first sentence of "Algorithm description". The editor content is as follows.
An empty Bloom filter is a bit array of  bits, all set to 0. There must also be  different hash functions defined,
In MS IE9 the text is correctly shown as:
:An empty Bloom filter is a bit array of m bits, all set to 0. There must also be k different hash functions defined,...
but in Google Chrome the text is incorrectly shown as:
:An empty Bloom filter is a bit array of   bits, all set to 0. There must also be   different hash functions defined,...
Perhaps the problem can be avoided by  replace  by m, replace  by k.  Blooteuth (talk) 03:10, 26 December 2016 (UTC)
replies: text: That would produce a slanted sans-serif letter m, where the result should be an italic serif m to indicate that it is a mathematical variable, not a fragment of emphasized text. —David Eppstein (talk) 04:31, 26 December 2016 (UTC)
thread_title:  Chrome browser problem 

message: Hello fellow Wikipedians,
I have just modified 5 external links on Bloom filter. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added  tag to https://git.postgresql.org/gitweb/?p=postgresql.git%3Ba%3Dcommitdiff%3Bh%3D9ee014fc899a28a198492b074e32b60ed8915ea9
*Added archive https://web.archive.org/web/20140828071451/http://plan9.bell-labs.com/magic/man2html/8/venti to http://plan9.bell-labs.com/magic/man2html/8/venti
*Corrected formatting/usage for http://www.arl.wustl.edu/~sarang/ancs6819-dharmapurikar.pdf
*Corrected formatting/usage for http://www.adetti.iscte.pt/events/CONEXT06/Conext06_Proceedings/papers/13.html
*Added archive https://web.archive.org/web/20090131053735/http://www.eecs.harvard.edu/~kirsch/pubs/bbbf/esa06.pdf to http://www.eecs.harvard.edu/~kirsch/pubs/bbbf/esa06.pdf
*Corrected formatting/usage for http://www.cs.utexas.edu/users/simha/publications/lsq.pdf
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 02:14, 22 July 2017 (UTC)
thread_title:  External links modified 

message: Changes made to Bloom filter
*Added an external reference for Kiss, et al
*Added an introductory paragraph setting the technical context as of 2018, including the review by Luo, et al which is in arXiv.org, and the application by Dasgupta, et al, which appeared in the prestigious journal, Proceedings of the National Academy of Sciences
 bayesianlogic.1@gmail.com 
 18:46, 4 December 2018 (UTC)
thread_title:  Added External References and Contextual Text 

message: I'm not an expert on this particular topic but this sentence:
:More generally, fewer than 10 bits per element are required for a 1% false positive probability, independent of the size or number of elements in the set.
...seems confusing and contradictory.  I interpret this to mean that a bloom filter may incorporate less than 10 bits per element from the set that it is "filtering."  In other words, if a bloom filter should have a 1% probability of returning a false positive when given an element from a target set, it may include less than 10 * n bits where n is the number of elements in the target set.  But this implies that there's at least an approximate relationship between the number of bits in the filter and the number of elements in the set.  So to say that the bits in the filter are independent of the number of elements in the set seems problematic.  If I'm confused and that sentence actually intends to illustrate a different concept, then maybe it should be reworded for clarity?
--Davesque (talk) 01:37, 8 August 2019 (UTC)
thread_title:  Last Sentence of Intro 

message: There is new work on the false positive rate: Summary, publication, Presentation. I sadly haven't the time to integrate it at the moment. -- MichaelSchoenitzer (talk) 00:29, 27 July 2020 (UTC)
thread_title:  New proven false positive rate 

message: In the section "Probability of false positives", it starts with "m is the number of bits in the array" and "k is the number of hash functions" (after the first equation). Later, to derive \varepsilon, it is suddenly "Each of the k array positions". Shouldn't this be m instead of k, both in the text as well as the following formula? 79.208.245.153 (talk) 16:32, 10 September 2021 (UTC)
thread_title:  Typo in section "Probability of false positives": k vs m?