Re: [boost] [fixed_point] First presentation from GSoC 2015 and more

Subject: Re: [boost] [fixed_point] First presentation from GSoC 2015 and more
From: Christopher Kormanyos (e_float_at_[hidden])
Date: 2016-10-19 15:33:48

>> 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 <mike.marcin_at_[hidden]> wrote:
 

 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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost