13 Oct
2016
13 Oct
'16
5:18 p.m.
Le 11/10/2016 à 22:17, Christopher Kormanyos a écrit : >>> 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: Sorry for the format: For a given Qm.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} * its range is [-(2^m), 2^m-2^(-n)] * its resolution is 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. The problem is using the same name that have different meaning than the referenced proposal. > >> 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. here it is where I don't agree. > 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. I believe that the use the sign bit is the correct way, yes. > >> 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. What I mean is that when boost::fixed_point is using Boost.MultiPrecission as representation type, there is no reason to don't be symetric. When the representation is a 32-bit, n3352 lost a value (the smalles one) to be able to be symetric. [-128,127] versus [-127,127] > >> *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? No at all. I mean that the range and resolution of the result of an operation depend on the operands and the operation it self (of course). IIUC the addition results in a fixed point with the same representation and the better resolution. This results already in overflow. While I can understand that this is the way to work on some domains when the representations must be a fixed builtin integral type, it is less clear the advantage when we use a multiprecision representation. When I use arbitrary I mean that the class is able to represent any number of bits. The result of a+b can have more bits. In p0106r0/ N3352 <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3352.html> operation result range result resolution a+b max($a,$b)+1 min(@a,@b) > >> *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. With p0106r0 I can represent numbers in the range [-1/32, 1/32] in steps of 1/128 and also number in the range [-1024*1024*1024, 1024*1024*1024] in steps of 32*1024. This is due because p0106r0 allows negative and positive powers of 2 for the range and resolution. Your Boost.FixedPoint doesn't allow to work with these numbers IIUC. > >> 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. See above for what I consider very small and very big. > >> Thanks for your work, >> Vicente > Thank you for your comments and insightful suggestions. > Best regards, Chris > Hoping I've clarified a little bit my concerns, about the symmetry, the closed and open arithmetic and the positive and negative powers of two. Best, Vicente > > On Monday, October 10, 2016 9:00 AM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> 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 > > > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost