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

Le 06/10/2016 à 12:07, Paul A. Bristow a écrit :

https://dl.dropboxusercontent.com/u/43940943/modular-boost/libs/fixed_point/...

but sadly this no longer works for reasons that so far escape me (but I suspect some change at Dropbox?).

Meanwhile here is a PDF version to whet your appetite until I get a html version publicly available.

https://dl.dropboxusercontent.com/u/43940943/modular-boost/libs/fixed_point/...

Boost.Fixed_point ? ===============

A partial implementation of fixed-point in a Boost-like style based on proposal N3352 is now available.

This work is the result of developments from 2013-2016, including efforts from GSoC 2015.

The source code is available at: https://github.com/BoostGSoC15/fixed_point

(The master branch will be stable for a while but the develop branch may be updated in the light of your feedback).

Preliminary docs are available at:

https://dl.dropboxusercontent.com/u/43940943/modular-boost/libs/fixed_point/...

We are potentially interested in submitting this work for inclusion in Boost.

We are now requesting comments and suggestions for improvements, corrections and any further test results if these become available.

Some key library features include:

* proper C++ header-only implementation * full numeric_limits and <cmath> functions * flexible template choice of split between resolution and range * automatic selection of underlying integral representation * portability and high efficiency for bare metal microcontrollers * interoperation with Boost.Math * seamless extension to high-precision using Boost.Multiprecision * extensive test suite

Hi, glad to see that you reached to get a review ready fixed point library. There are two fetures that I woudl like the documentation states more clearly: *Q format:** *I understand that you prefer the Q format, instead of the Range/Resolution format as described in n3352. Most of the people is using the Qm.n format in their products. However, I believe the library should name the type more explicitly, either q, q_negatable or q::negatable or fixed_point_q::negatable or something else. In the Qm.n format m is not the range and n is not the resolution as the documentation often use. It is quite close, but it is not the exactly that. For a given Q/m/./n/format, using an/m/+/n/+1 bit signed integer container with/n/fractional bits: * its range is{\displaystyle [-(2^{m}),2^{m}-2^{-n}]}[-(2^{m}),2^{m}-2^{-n}] * its resolution is{\displaystyle 2^{-n}}2^{-n} n3352 negatable would be boost::fixed_point::negatable and loss the smallest value. *Symmetric range* There is an additional difference. n3352 has symmetric range that merits more attention. negatable * its range is [-2^m, 2^m] * its resolution is2^N This has all the problems signed integers have. Negating an integer could result in overflow. I understand that a bit is a bit and in some environments this is the best choice. However, n3352 symmetric signed types are more robust. I will consider to spend an additional bit if I'm ready to use arbitrary precision. *Bounded versus unbounded *n3352 has unbounded arithmetic, while boost::fixed_point has bounded arithmetic. While I understand we could want bounded arithmetic for fixed points types that have a builtin representation, I believe that we want open arithmetic when we use arbitrary precision. *Very small and very large numbers * n3352 allows positive and negative range and resolution. The proposed boost::fixed_point doesn't. I don't know if this limitation of the Qm.n. format, a limitation of the proposed library or if it is by design. Anyway, I believe that very large numbers fixed point numbers are needed as well as very small ones. Thanks for your work, Vicente