
Boost : 
From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 20070429 16:01:32
Anthony Williams wrote:
> I've just implemented some 64bit (35.28, signed) fixedpoint 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 poweroftwo 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 fixedpoint 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk