floor & ceil functions support in FPTaylor

[rospoly]

Hi Alexey,

This is not an issue. I would like to ask you a technical question.

Does FPTaylor support operations to round floating-point variables to integer? In other words, the equivalent of floor & ceil from C++. Similar question for casting operation like the static_cast<int>.

Also I am not sure what would be the error expression stemming from such operations.

Thank you for your time,
-- Rocco

[monadius]

Hi Rocco,

FPTaylor does not support integer types and operations which cast floating-point numbers to integers. As far as I know, PRECiSA supports such operations but it has a different approach for computing symbolic expressions for error terms.

In principle, floor and ceil operations could be implemented in FPTaylor. But I don't think that it will be possible to get good error bounds for them. Here is one possible implementation idea. Suppose that we have a Taylor form corresponding to a real-valued expression f(x): f(x) + g_1(x)e_1 + ... + g_k(x)e_k. Here, g_i(x) are some expressions and e_i are error intervals (i.e., e_i in [-eps, eps] for appropriate values of eps).

We want to compute a Taylor form corresponding to floor(f(x)). We can represent it as follows: floor(f(x)) + F(x)e_F where F(x) is an interval function and e_F = [-1, 1]. The simplest form of the function F(x) is F(x) = m where m >= ceil(|g_1(x)e_1 + ... g_k(x)e_k|) for all x. It just assumes the worst possible error for all inputs x. It is possible to improve its accuracy and compute the bound m for each input interval X at the global optimization stage. In other words, the expression ceil(|g_1(x)e_1 + ... g_k(x)e_k|) should be evaluated at the global optimization stage.

The main issue with this approach is that the error interval [-1, 1] is too wide. Any nonlinear operation will not be able to compute a good second-order error bound for Taylor forms with such wide intervals. So this approach for computing floor returns reasonable error bounds if floor is the last operation or if only linear operations are used after floor.

[monadius]

F(x) can be further improved by defining F(X) = 0 for an interval X if the interval f(X) + g_1(X)e_1 + ... + g_k(X)e_k does not contain integer values.

[rospoly]

Hi Alexey, thank you so much for your comments and for bringing up PRECiSA.

The error stemming from a floor/ceil operation when the input interval contains an integer is in the order of the units.
I believe this to be a pretty accurate behaviour. Please correct me if I am wrong.

For example, in case we have F(X) = floor(X) and X in [0,1], the error bound is 1, and I believe this to be exact (e.g., if we pick 0.9999999...9 it becomes 1 in any floating-point format while still 0 in the reals). After the floor operator, any further non-linear manipulation of F(X) (e.g. floor(X) * 1000) dramatically affects the magnitude of the error.

While the error bounds might be a little conservative, I like this behaviour from PRECiSA (or any worst-case error analysis supporting floor/ceil). The use of floor/ceil in the source code is very unpredictable when the input intervals contain any integer (which is pretty common), and the developer should be informed. Indeed, we inform the developer that particular care must be taken in a neighborhood of any integer in the input intervals (for example using + - eps).

Thank you again for your analysis.