From a6e3231211c2fdd35d54a0295c8ba63b13c90c29 Mon Sep 17 00:00:00 2001
From: Amir MOHAMMADI <amir.mohammadi@idiap.ch>
Date: Thu, 7 Jun 2018 18:35:35 +0200
Subject: [PATCH] Explain that the thresholds might not satisfy the requested
criteria
---
doc/guide.rst | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/doc/guide.rst b/doc/guide.rst
index d6a0c44..5df02a0 100644
--- a/doc/guide.rst
+++ b/doc/guide.rst
@@ -164,6 +164,20 @@ calculation of the threshold:
By setting cost to 0.5 is equivalent to use
:py:func:`bob.measure.min_hter_threshold`.
+
+.. important::
+ Often, it is not numerically possible to match the requested criteria for
+ calculating the threshold based on the provided scores. Instead, the closest
+ possible threshold is returned. For example, using
+ :any:`bob.measure.eer_threshold` **will not** give you a threshold where
+ :math:`FAR == FRR`. Hence, you cannot report :math:`FAR` or :math:`FRR`
+ instead of :math:`EER`; you should report :math:`(FAR+FRR)/2` instead. This
+ is also true for :any:`bob.measure.far_threshold` and
+ :any:`bob.measure.frr_threshold`. The threshold returned by those functions
+ does not guarantee that using that threshold you will get the requested
+ :math:`FAR` or :math:`FRR` value. Instead, you should recalculate using
+ :any:`bob.measure.farfrr`.
+
.. note::
Many functions in ``bob.measure`` have an ``is_sorted`` parameter, which defaults to ``False``, throughout.
However, these functions need sorted ``positive`` and/or ``negative`` scores.
--
GitLab