Boost logo

Boost :

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 :
> 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.
> 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:
> (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:
> 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

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

*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
  * 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

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,

Boost list run by bdawes at, gregod at, cpdaniel at, john at