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

Subject: Re: [boost] [fixed_point] First presentation from GSoC 2015 and more
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2016-10-13 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^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_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
>
>     
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost