further improved float section

Author: thomasWeise

bookbase

@@ -163,6 +163,7 @@
 We only have about 15~digits, so doing something like~$10^{20} + 1$ will usually work out to just be~$10^{20}$ in floating point arithmetics~\cite{PTVF2007NRTAOSC:EAAS}.
 But digits could also be lost when adding numbers of roughly the same scale, because their sum could just be larger so that the 15-digit-window shifts such that the least-significant digit falls off~\cite{BHK2006CNFCMEARFCS:NS}{\dots}%
 %
+\FloatBarrier%
 \endhsection%
 %
 \hsection{Back to Integers: Rounding}%
@@ -232,6 +233,7 @@
 However, especially with the function \pythonilIdx{round}, we need to be careful.
 It does \emph{not} necessarily work as one would expect!~({\dots}but arguably better.)%
 %
+\FloatBarrier%
 \endhsection%
 %
 \hsection{The Scientific Notation}%
@@ -294,6 +296,7 @@
 However, if we write \pythonil{9_999_999_999_999_999.0}, something interesting happens:
 We get \pythonil{1e+16}, i.e., $10^{16}$.
 This is because of the limited precision of the floating point numbers, namely the 15~digits often mentioned above.
+We did specify 16~\inQuotes{9s} and therefore, it got rounded to the nearest 15\nobreakdashes-digit number, which is~$1*10^{16}$.
 We cannot distinguish $10^{16}$ and $10^{16}-1$ when using \python's \pythonils{float}\pythonIdx{float}.
 Indeed, writing \pythonil{10_000_000_000_000_000.0} also yields \pythonil{1e+16}.%
 \end{sloppypar}%
@@ -314,15 +317,16 @@
 
 You can even violate the scientific notation a bit when entering numbers if you feel naughty.
 \pythonil{-12e30}, for example, would better be written as \pythonil{-1.2e+31}, which the \python\ console will do for you in its output.
-Similarly, \pythonil{0.023e-20} becomes \pythonil{2.3e-22}.
+Similarly, \pythonil{0.023e-20} becomes \pythonil{2.3e-22}.%
+\FloatBarrier%
 \endhsection%
 %
 \hsection{Limits and Special Floating Point Values: Infinity and \inQuotes{Not a Number}}%
 \label{sec:float:special}%
 %
 %
 \gitEvalPython{float_very_small}{}{simple_datatypes/float_very_small.py}%
-\listingBox{exec:float_very_small}{What happens with very small floating point numbers in \python?\pythonIdx{0.0}.}{,style=python_console_style}%
+\listingBox{exec:float_very_small}{What happens with very small floating point numbers in \python?\pythonIdx{0.0}}{,style=python_console_style}%
 %
 We already learned that the floating point type \pythonilIdx{float} can represent both very small and very large numbers.
 But we also know that it is internally stored as chunk of 64~bits.
@@ -360,24 +364,26 @@
 They become zero.
 
 \gitEvalPython{float_very_large}{}{simple_datatypes/float_very_large.py}%
-\listingBox{exec:float_very_large}{What happens with very large floating point numbers in \python?\pythonIdx{inf}.}{,style=python_console_style,literate={0}{0\-}1 {1}{1\-}1 {2}{2\-}1 {3}{3\-}1 {4}{4\-}1 {5}{5\-}1 {6}{6\-}1 {7}{7\-}1 {8}{8\-}1 {9}{9\-}1,breakatwhitespace=false,breaklines=true}
+\listingBox{exec:float_very_large}{What happens with very large floating point numbers in \python?\pythonIdx{inf}}{,style=python_console_style,literate={0}{0\-}1 {1}{1\-}1 {2}{2\-}1 {3}{3\-}1 {4}{4\-}1 {5}{5\-}1 {6}{6\-}1 {7}{7\-}1 {8}{8\-}1 {9}{9\-}1,breakatwhitespace=false,breaklines=true}
 
 But what happens to numbers that are too big for the available range?
 Again, according to the nice documentation of \pgls{Java}~\cite{O2024JPSEJDKV2AS:CD}, the maximum 64~bit double precision floating point number value is~$(2-2^{-52})*2^{1023}\approx1.797\decSep693\decSep134\decSep862\decSep315\decSep708\dots*10^{308}$.
 We can enter this value as \pythonilIdx{1.7976931348623157e+308}\pythonIdx{float!largest} and it indeed prints correctly in \cref{exec:float_very_large}.
 If we step it up a little bit and enter \pythonil{1.7976931348623158e+308}, due to the limited precision, we again get \pythonilIdx{1.7976931348623157e+308}\pythonIdx{float!largest}.
 However, if we try entering \pythonil{1.7976931348623159e+308} into the \python\ console, something strange happens:
 The output is \pythonilIdx{inf}.
-\pythonil{inf} means \emph{\inQuotes{too big to be represented as number with \pythonil{float},}} which obviously includes infinity~($+\infty$), but also simply all numbers bigger than~\pythonil{1.7976931348623158e+308}.
-
+\pythonil{inf} means \emph{\inQuotes{too big to be represented as number with \pythonil{float},}} which obviously includes infinity~($+\infty$), but also simply all numbers bigger than~\pythonil{1.7976931348623158e+308}.%
+%
+\begin{sloppypar}%
 \pythonil{-1.7976931348623159e+308} gives us \pythonilIdx{-inf}.
 Multiplying this value by two, i.e., computing \pythonil{-1.7976931348623157e+308 * 2}, still yields \pythonil{-inf}.
 Intuitively, based on its name, one would assume that \pythonilIdx{inf} stands for \inQuotes{infinity} or~$\infty$.
 However, it \emph{actually} means \emph{too big to represent as \pythonilIdx{float} or~$\infty$}.
 If we enter numbers that are too big or exceed the valid range of \pythonilIdx{float} by multiplication, addition, subtraction, or division, we simply get~\pythonilIdx{inf}.
 This does not actually mean \inQuotes{mathematical infinity,} because, while \pythonil{-1.7976931348623159e+308}\pythonIdx{float!largest} is very big, it is not infinitely big.
-It simply means that the number is too big to put it into a 64~bit \pythonilIdx{float}.
-
+It simply means that the number is too big to put it into a 64~bit \pythonilIdx{float}.%
+\end{sloppypar}%
+%
 Actually, the \pythonilIdx{int} type can represent larger numbers easily.
 \pythonilIdx{1.7976931348623157e+308}\pythonIdx{float!largest} is equivalent to \pythonil{17_976_931_348_623_157 * 10 ** 292}.
 This prints as a number with many zeros.
@@ -408,7 +414,7 @@
 \gitEvalPython{float_nan}{}{simple_datatypes/float_nan.py}%
 \listingBox{exec:float_nan}{Not a Number\pythonIdx{Not a Number}, i.e., \pythonilIdx{nan}.}{,style=python_console_style}%
 
-Now, \pythonilIdx{inf} not actually being~$\infty$ is a little bit weird.
+Now, \pythonilIdx{inf} not actually being~$\infty$ is a little bit counter-intuitive.
 But it can get even stranger, as you will see in \cref{exec:float_nan}.
 \pythonilIdx{inf} is a number which is too big to be represented as \pythonilIdx{float} \emph{or}~$\infty$.
 Once a variable has the value \pythonilIdx{inf}, however, it is treated as if it was actually infinity.
@@ -432,15 +438,48 @@
 However, \pythonilIdx{nan} is \emph{really} different from really \emph{anything}.
 Therefore, \pythonil{nan == nan}\pythonIdx{==} is \pythonilIdx{False} and \pythonil{nan != nan}\pythonIdx{"!=} is \pythonilIdx{True}!
 
-Interestingly, we said that \pythonil{inf} behaves more or less like~$\infty$ in computations.
-Except that \pythonil{inf == inf} is \pythonil{True}, which is strange, because \pythonil{inf - inf} is undefined.
-But OK, let's just accept that somethings are a bit strange and move on.
+Interestingly, we can said that \pythonil{inf} behaves more or less like~$\infty$ in computations.
+It is \pythonil{True} that \pythonil{inf == inf} which makes total sense from a programming perspective.
+It may  be considered a bit odd from a mathematical perspective, though, because infinity is not really a (single) value and there are different degrees of infinity: $\lim_{x\rightarrow\infty} x$~is different from~$\lim_{x\rightarrow\infty} x^2$ is different from~$\lim_{x\rightarrow\infty} \numberE^x$, for example.
+Then again, \pythonil{inf - inf} is undefined, which makes \inQuotes{more} mathematical sense, because we have no measure to know whether an \pythonil{inf} comes from something like \pythonil{1e308 * 2} or \pythonil{1e308 * 1e308}.
+But OK, let's just accept that somethings are a bit strange about \pythonil{inf} and move on.
 
 \gitEvalPython{float_check_finite}{}{simple_datatypes/float_check_finite.py}%
 \listingBox{exec:float_check_finite}{Checking for \pythonilIdx{nan} and \pythonilIdx{inf} via \pythonilIdx{isfinite}, \pythonilIdx{isinf}, and \pythonilIdx{isnan}.}{,style=python_console_style}%
 
 Either way, the possible occurrence \pythonilIdx{inf} and \pythonilIdx{nan} in floating point computations is a cumbersome issue.
-If we want to further process results of a computation, we often want to make sure that it is neither \pythonilIdx{inf} nor \pythonilIdx{-inf} nor \pythonilIdx{nan}.
+If you think about it:
+There hardly is any scenario where \pythonilIdx{inf} is a reasonable result of a computation.
+Looking back at \cref{exec:float_very_large,exec:float_nan}, we had to do some rather strange wrenches to get them to occur.
+There are four probable reasons why these values could occur:%
+%
+\begin{enumerate}%
+%
+\item Because they make total sense and are the expected result of correct computations with correct data.
+Does this sound very likely to you?%
+%
+\item Because some of the input data of our computations is incorrect, corrupted, or faulty.%
+%
+\item Because we have some error in our computation, maybe a typo, maybe misplaced parentheses, maybe a mathematical misconception.%
+%
+\item Because someone deliberately sent corrupted data to the input of our computation in order to provoke unexpected or unintented behavior.%
+%
+\end{enumerate}%
+%
+The first possible reasons indeed seems to be unlikely.
+There probably are few situations where \pythonilIdx{nan} is a value that you would expect and want to get and work with.
+Very often, if such values occur, something went wrong.
+Maybe some input value was wrong.
+Maybe some value was supplied that was too large or too small to be reasonable.
+Maybe a 0 occured in a place where no 0 should occur.
+Maybe we just made an error when writing down the formula.
+
+Also, let's not just consider \inQuotes{errors} here.
+It is not entirely impossible that someone tried to \emph{intentionally} and maliciously manipulate the input of our program.
+Maybe someone tries to trigger some otherwise impossible behavior of our code\dots
+Values like \pythonilIdx{nan} can be a real security concern~\cite{C2026ROT2UCCAOONPA}.
+
+Therefore, if we want to further process results of a computation where such a thing might happen for one reasone or another, we often want to make sure that it is neither \pythonilIdx{inf} nor \pythonilIdx{-inf} nor \pythonilIdx{nan}.
 This can be done via the function \pythonilIdx{isfinite}, which we can import from the \pythonilIdx{math} module\pythonIdx{import}\pythonIdx{from}, as you can see in \cref{exec:float_check_finite}.
 \pythonil{1e34} is a large number, but \pythonil{isfinite(1e34)} is certainly \pythonilIdx{True}.
 \pythonil{isfinite(inf)} and \pythonil{isfinite(nan)} are both \pythonilIdx{False}.