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. Much of my work is in the area of 4. This is also a good test of the limits of the C++ language via <cmath>-likefunctions with very few digits and very many digits.It's a true exercise in generic mathematical programming. In the area of 4., fixed_point tends to be slower thanhardware-supported FPU-based calculations, but reallycan outperform software-emulated floating-point libs.So we're really targeting other areas mentioned aboveand also cost-sensitive embedded systems with no FPU.Our docs describe these issues.
It is good that we are converging on <cmath>-like functions.
The only significant potential conflict that I can detectbetween SG14 fixed_point design and Bioost GSoCfixed_point design is the issue of bounded/unboundedmath that Vicente raised earlier in the thread.
As far as I can tell, SG14 design automatically widensor shrinkens the width of the fixed_point type formul/div via standard operator* and operator/.SG14 design offers bounded math through C-like namedfunctions. Whereas the Boost GSoC code uses exclusivelybounded math via operator+, operator-, operator*, operator/with no widening or shrinkening.
This difference in design strategy is becoming troubling to mebecause it would not be a good idea to have divergingdesign strategies in Boost and SG14. At the same time,I am somewhat hesitant to try and change our design becauseit is based on a hybrid of both the preliminary specificationsand popular use cases.
Best regards, Chris
On Wednesday, October 19, 2016 4:42 AM, Michael Marcin
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. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost