Document estimated rounding errors

[monty241]

Related to #4.

The current code uses single precision numbers. But even with arbitrary precision numbers, cumulative errors can be introduced when executing many calculation steps and using the output of previous steps as input to next steps. Programmers typically need to take care that numeric errors do lead to outcomes with an accuracy outside of the pre-established required accuracy.

The current code does not ground-up document the rounding errors in terms of precision lost during the process; it may be documented elsewhere.

Also, it seems that during the evolution from the historical code into the current version the scope has been extended to a finer matrix resolution. Maybe the original code was checked for rounding errors, but such a scope change may require additional checks. These might also have been done outside of the code.

A little overly dramatic sample of the past when still studying at EUT was the Patriot software issue as documented on https://hownot2code.com/2016/11/09/r-17-vs-patriot-a-rounding-issue-bugs-in-a-missile-defense-system/.

Suggestion is to extend each method by some documentation assessing the precision loss, allowing top level determination of the accuracy boundaries of the model and whether they fall within the acceptable range.