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.
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. - 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. Some will argue that expression templates can be used to work around this, but that dramatically increases the complexity of the library. - There are also difficult decisions to make about implicit and explicit conversions. 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. Regards, Phil.