fix: remove \operatorname

Author: wenkokke

README.md

@@ -537,13 +537,12 @@ database executes a lookup operation, any Bloom filter query that
 returns a false positive causes the database to unnecessarily read a run
 from disk. The probabliliy of these spurious reads follow a [binomial
 distribution](https://en.wikipedia.org/wiki/Binomial_distribution "https://en.wikipedia.org/wiki/Binomial_distribution")
-$`\operatorname{Binomial}(r,\operatorname{FPR})`$ where $`r`$ refers to
-the number of runs and $`\operatorname{FPR}`$ refers to the
-false-positive rate of the Bloom filters. Hence, the expected number of
-spurious reads for each lookup operation is
-$`r\cdot\operatorname{FPR}`$. The number of runs $`r`$ is proportional
-to the number of physical entries in the table. Its exact value depends
-on the merge policy of the table:
+$`\text{Binomial}(r,\text{FPR})`$ where $`r`$ refers to the number of
+runs and $`\text{FPR}`$ refers to the false-positive rate of the Bloom
+filters. Hence, the expected number of spurious reads for each lookup
+operation is $`r\cdot\text{FPR}`$. The number of runs $`r`$ is
+proportional to the number of physical entries in the table. Its exact
+value depends on the merge policy of the table:
 
 `LazyLevelling`  
 $`r = T (\log_T\frac{n}{B} - 1) + 1`$.
@@ -578,9 +577,9 @@ $`[1\mathrm{e}{ -5 },1\mathrm{e}{ -2 }]`$.
 The total in-memory size of all Bloom filters scales *linearly* with the
 number of physical entries in the table and is determined by the number
 of physical entries multiplied by the number of bits per physical entry,
-i.e, $`n\cdot\operatorname{BPE}`$. Let us consider a table with 100
-million physical entries which uses the default table configuration for
-every parameter other than the Bloom filter size.
+i.e, $`n\cdot\text{BPE}`$. Let us consider a table with 100 million
+physical entries which uses the default table configuration for every
+parameter other than the Bloom filter size.
 
 | False-positive rate (FPR) | Bloom filter size | Expected spurious reads per lookup |
 |----|----|----|

lsm-tree.cabal

@@ -335,9 +335,9 @@ description:
   Querying a Bloom filter returns either \"maybe\" meaning the key is possibly in the run or \"no\" meaning the key is definitely not in the run.
   When a query returns \"maybe\" while the key is /not/ in the run, this is referred to as a /false positive/.
   While the database executes a lookup operation, any Bloom filter query that returns a false positive causes the database to unnecessarily read a run from disk.
-  The probabliliy of these spurious reads follow a [binomial distribution](https://en.wikipedia.org/wiki/Binomial_distribution) \(\operatorname{Binomial}(r,\operatorname{FPR})\)
-  where \(r\) refers to the number of runs and \(\operatorname{FPR}\) refers to the false-positive rate of the Bloom filters.
-  Hence, the expected number of spurious reads for each lookup operation is \(r\cdot\operatorname{FPR}\).
+  The probabliliy of these spurious reads follow a [binomial distribution](https://en.wikipedia.org/wiki/Binomial_distribution) \(\text{Binomial}(r,\text{FPR})\)
+  where \(r\) refers to the number of runs and \(\text{FPR}\) refers to the false-positive rate of the Bloom filters.
+  Hence, the expected number of spurious reads for each lookup operation is \(r\cdot\text{FPR}\).
   The number of runs \(r\) is proportional to the number of physical entries in the table. Its exact value depends on the merge policy of the table:
 
   [@LazyLevelling@]
@@ -373,7 +373,7 @@ description:
       The value must be in the range \((0, 1)\).
       The recommended range is \([1\mathrm{e}{ -5 },1\mathrm{e}{ -2 }]\).
 
-  The total in-memory size of all Bloom filters scales /linearly/ with the number of physical entries in the table and is determined by the number of physical entries multiplied by the number of bits per physical entry, i.e, \(n\cdot\operatorname{BPE}\).
+  The total in-memory size of all Bloom filters scales /linearly/ with the number of physical entries in the table and is determined by the number of physical entries multiplied by the number of bits per physical entry, i.e, \(n\cdot\text{BPE}\).
   Let us consider a table with 100 million physical entries which uses the default table configuration for every parameter other than the Bloom filter size.
 
   +---------------------------+----------------------+------------------------------------------------------------------+