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-11 16:17:30

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

> glad to see that you reached to get a review ready fixed point library.
Thank you Vicente. We appreciate your comments and experience.

> There are two features 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}

I am not sure if I completely understand your point. SoI believe that we need to take a closer look at thisnaming convention. At this time, I would prefer notto change anything, but let's take a closer look andtry to make sure that there are no big mistakesin the docs.

> 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

Again, I am not sure if I completely understand this.But I believe that the proposed boost::fixed_point codediffers from n3352 in this area at the moment.
One issue I also struggled with is if we should internallyuse the sign bit (as is done now)? Or should we usea dedicated Boolean member variable for sign information?There are trade-offs for either way.

> 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.
The cost of multiprecision is quite large. I would really prefernot to require this overhead for 32-bit or 64-bit fixed_points.

> *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.
Do you mean that the range and resolution should bedynamically changed at run-time?

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

It is by design choice.

> Anyway, I believe that very large numbers fixed point numbers are needed > as well as very small ones.
At the moment, the fixed_point negatable class extends tomultiprecision without limitation at compile time, as longas multiprecision backends are enabled. So you can havevery small and very large fixed_point numbers.
In fact, some of the examples and tests use just a few bits,while others use many thousands of bits.

> Thanks for your work,
> Vicente
Thank you for your comments and insightful suggestions.
Best regards, Chris
 

    On Monday, October 10, 2016 9:00 AM, Vicente J. Botet Escriba <vicente.botet_at_[hidden]> wrote:
 

 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

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