
Boost : 
Subject: Re: [boost] [fixed_point] First presentation from GSoC 2015 and more
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 20161013 13:18:45
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^m2^(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 tradeoffs 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 32bit or 64bit 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 32bit, 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 runtime?
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.openstd.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_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
>
>
>
> _______________________________________________
> 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