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

...

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

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 wrote: 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost