Subject: Re: [boost] [fixed_point] First presentation from GSoC 2015 and more
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2016-10-10 03:00:16
Le 06/10/2016 à 12:07, Paul A. Bristow a écrit :
>
> https://dl.dropboxusercontent.com/u/43940943/modular-boost/libs/fixed_point/doc/html/index.html
>
> 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/doc/fixed_point.pdf
>
> 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/index.html
>
> 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<M,N> would be boost::fixed_point::negatable<M+1, -N> and
loss the smallest value.
*Symmetric range*
There is an additional difference. n3352 has symmetric range that merits
more attention. negatable<m,n>
* 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