
Boost : 
Subject: Re: [boost] [fixed_point] First presentation from GSoC 2015 and more
From: Christopher Kormanyos (e_float_at_[hidden])
Date: 20161011 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 tradeoffs 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 32bit or 64bit 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 runtime?
> *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/modularboost/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/modularboost/libs/fixed_point/doc/fixed_point.pdf
>
> Boost.Fixed_point ?
> ===============
>
> A partial implementation of fixedpoint in a Boostlike style based on proposal N3352 is now available.
>
> This work is the result of developments from 20132016, 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/modularboost/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++ headeronly 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 highprecision 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk