Deterministic or not? about fixed_point

[johnmcfarlane]

I would not like to make any guarantees about fixed-point trig functions because float hardware solutions on Intel/ARM platforms are likely to be hard to beat. However, it is possible to generate constexpr lookup tables for some of these which will do a pretty good job. Note that multiplication should also be on par with the underlying integer type but division does not try to be optimal as integer division is not a good fit for fixed-point.

There are no compiler switches to make rounding faster as this would alter integer arithmetic behavior significantly. I am currently converting the fixed_point library to a new library, CNL, which contains everything from fixed_point plus other types such as a precise_integer type which performs custom rounding behavior during division, float conversion and right-shift.

When used instead of built-in integers to specialize fixed_point, e.g. fixed_point<precise_integer<int>, N>, precise_integer should provide a solution to the inaccuracies of int rounding. Optimizing that type will involve trying to harness platform-specific features. However, one problem is that this will often prevent operations from being constexpr.

For the performance user who can tolerate minor statistical biases, I expect just built-in integers to be used with high enough precision. Without full integer rounding support from a CPU and compiler, I fear that this is an inevitable trade-off.

[johnmcfarlane]

Hi David,

In general, the fixed_point type is deterministic but the trig functions such as sin and cos are placeholder functions. They rely on floating-point arithmetic because I have not gotten around to writing bespoke fixed-point versions yet. The other mentions of float should be mostly related to conversion to and from floating-point types.

If you are concerned about determinism, either avoid the sin, cos, exp and pow or be careful to compile your code with higher precision, i.e. /fp:precise on MSVC++ and similar options on GCC and Clang.

All arithmetic operators etc. should essentially be wrappers around integer behavior so instantiate fixed_point with int32_t and you should get a type whose behavior is portable, deterministic and commutative.

If there is any particular functionality you need, please feel free to request it in an issue or submit a pull request.

Thanks
John

[ddovod]

Thank you John, now it is much clear for me!

[Causeless]

Just another couple questions here:

I've been investigating this library to look at using for a real-time deterministic simulation and I'm wondering how the performance stacks up next to native ints and floats. Presumably for basic addition/subtraction we can expect to see near native int performance? When sin/cos/exp/pow are implemented, what kind of performance can we expect next to floats? How about sqrt - can a faster approximate sqrt function be created?

Also, are there any compile-time switches - e.g rounding settings that could speed up computation? The proposal mentions that a hardware shift-right that rounds instead of dropping would be a key performance boost. As this is a purely emulated library with no dedicated hardware I realize certain approximations for the sake of performance ignoring strict numerical correctness could be made here.