Re: [boost] Some follow-up on my fixed point code, and safe integers

From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2007-04-29 16:01:32

Anthony Williams wrote:
> I've just implemented some 64-bit (35.28, signed) fixed-point math functions: 
> exp, sqrt, sin, cos. I can post the code if you like.

Please do.

> I like the ability to specify the number of bits either side of the decimal 
> point, but this does get in the way for doing the math functions --- you need 
> a table with magic numbers in at the appropriate precision for exp and 
> sin/cos.

Presumably the tables could be computed at run time once per type.
There is also the question of what type the result should have.

John Femiani wrote:
> I wonder if either of you are
> willing to consider non power-of-two scaled values. For instance images
> are commonly stored using 8bit integers, but with the assumption that
> 255 is actually 'one'.

That's an interesting problem, and one that I have previously had to 
deal with myself.  However, I'm really keen to focus on the core idea 
of a fixed-point type.

I am a bit concerned that the nature of the Boost process could lead to 
a sort of "design by committee".  If I were to resist all suggestions 
for "feature creep", would I eventually find my offering rejected for 
"lack of features"?  Would only a "bloated" library be accepted?

When I was integrating my safe_int<> type with fixed<>, I encountered 
an interesting problem.  Recall that fixed has three template 
parameters giving the number of bits before and after the point and the 
implementation type.  The implementation type defaults to an integer 
provided by Boost.Integer, however you can provide an alternative such 
as safe_int.  My problem is what type should be used in the result of a 
function such as:

template<int XWB, int XFB, typename XIMPL, int YWB, int YFB, typename YIMPL>
fixed<XWB+YWB, XFB+YFB, ????> operator*(fixed<XWB,XFB,XIMPL> x, fixed<YWB,YFB,YIMPL>);

Putting aside the question of what to do when X and Y have different 
implementation types (e.g. one is overflow checking and one is not), 
what I need in the return type is something that is "like XIMPL (or 
YIMPL) but with n bits".  For example, if XIMPL is safe_int<XWB+XFB>, 
the return type should be safe_int<XWB+YWB+XFB+YFB>; if it's 
boost::int_t<XWB+XFB>::least, the return type should be 
boost::int_t<XWB+YWB+XFB+YFB>.  Any idea how to do that?

Regards,

Phil.