Hi Vicente,
Vicente J. Botet Escriba wrote:
the recent discussion on the MultiplePrecission Arithmetic library has show that some people has its ow fixed point library.
You might like to review old discussions of fixed point, e.g.:
http://thread.gmane.org/gmane.comp.lib.boost.devel/157744 http://thread.gmane.org/gmane.comp.lib.boost.devel/158019 http://thread.gmane.org/gmane.comp.lib.boost.devel/178257
and several other threads. Thanks for pointing to these threads. I will read them carefully.
Is there an interest in a Boost library having as base http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3352.html?
Thanks for pointing out that doc which I'd not seen before. I've not yet read it properly.
FWIW, my view is that:
- Some people conflate fixed point with features like saturation, which I would prefer to decouple. Fixed-point arithmetic without saturation is useful, as is integer arithmetic with saturation. So I'd prefer to make them orthogonal, but compatible, concepts. Would the overflow::ignore policy responds to your needs?
- There are difficult decisions to make about the result types of arithmetic operations, analogous to this:
int32_t a, b; int64_t c; c = a+b; // oops.
It is tempting to make the return type of e.g. operator+ large enough to accommodate the largest possible sum, and to truncate only when the assignment occurs. But I think this will have an unavoidable runtime overhead. Are you referring to the fact that a and b must be promoted before? or
Le 11/04/12 20:23, Phil Endecott a écrit : that the operation is done on the promoted type? Or maybe both? The promotion is not really needed always. For example fp<int64_t,32,0> a,b; fp<int64_t,33,0> c; c=a+b; No promotion needed in this case, but the operation is done on int64_t.
Some will argue that expression templates can be used to work around this, but that dramatically increases the complexity of the library.
An alternative is to define functions that have the result type as template parameter, so if what you want is fp<int32_t,32,0> a,b; fp<int32_t,32,0> c; c=a+b; you use instead c = plus<fp<int32_t,32,0>>(a,b); here plus could be optimized and don't promote to fp<int64_t,33,0>. I have not implemented this yet, but I expect this to be as efficient as if we did int32_t a, b; int32_t c; c = a+b; in the case overflow is ignored. Of course, and implementation should be needed to probe the expectations.
- There are also difficult decisions to make about implicit and explicit conversions. Are you referring to the conversion between fixed-point types with different rand or resolution? Yes, this is a conflicting point and has a deep impact on the design of the library. I don't know if we can manage by providing both.
My prototype as well as the C++ proposal allows implicit conversions when there is no loss of data and requires some kind of fixed point cast if information could be loss. { unsigned_number<2,-3> n1((index(1))); unsigned_number<2,-2,round::negative> n2; n2=number_cast<unsigned_number<2,-2,round::negative> >(n1); } An explicit convert function could also be used to avoid repeating the target type convert_to(n1, n2);
These are some of the same questions that you asked in your post. Different people will have different requirements. It is perhaps because of this that everyone tends to "roll their own", and no standard implementation has emerged.
You are surely right and perhaps we can not provide something that satisfy all the requirements. This was the main reason of my post, to know the expectations of the Boost community. I hope however that we can have a Boost library that solves some of the major issues, whether the library could be used as a base for standardization is something that we could discuss later, if a library emerge and is accepted in Boost. Thanks again, Vicente