On 10/18/2016 6:51 PM, John McFarlane wrote:
I can only speak for P0037 although P0106 has also been reviewed by SG14. Adding <cmath>-like functions was discussed at our meeting in March. It's also briefly discussed in P0037: https://github.com/johnmcfarla ne/fixed_point/blob/master/doc/p0037r3.md#library-support
The proposal is quite tightly scoped. However, that doesn't stop me prototyping surrounding features in the reference implementation [ https://github.com/johnmcfarlane/fixed_point/] - especially if I think they might warrant standardization at a later date. These functions are quite a lot to bite off which is why I only supplied a few wrappers so far. I'm sure it's not easy to get better performance that FPU-supported floating-point variants. However, I am interested in seeing if I can make use of the algorithms in Boost.fixed_point.
I'm not sure what the target is. My game dev fixed-point usage falls into 4 broad categories: 1. deterministic reproducible game state representation/logic (eg stable replay format across multiple platforms/compilers/releases) 2. network/serialization formats 3. converting assets for use with GLES 1.x GPUs 4. embedded/mobile systems with no FPU, no GPU and sometimes no or limited software floating-point emulation Performance was not a major issue for fixed-point outside of the last case in which the std floating-point cmath routines were horribly slow and/or broken.