
Boost : 
Subject: Re: [boost] [boostcon][proto] Suggestion for LIAW session: fixedpointnumbers
From: Gruenke, Matt (mgruenke_at_[hidden])
Date: 20110315 21:45:49
I wrote a similar class, years ago. The signature was simply:
template<
SignProperty is_signed,
int int_bits, //!< Number of integer bits.
int frac_bits //!< Number of fractional bits.
>
class CFixed;
The way I structured it was to discard information only on assignment (unless the maximum internal storage had overflowed, of course). While I agree that it's tempting to just use int64 for storage, the size and speed implications of creating large arrays of them provides a strong argument against this approach.
Since the most common use of fixedpoint arithmetic is for speed, the priority is speed over safety. For example, never assume that overflow checking is performed. Furthermore, operatorns supported by the class are primarily designed to avoid unnecessary arithmetic, while minimizing surprises.
The general policies were:
* No virtual functions! Fixedpoint types must be as fast
and small as handcoded fixedpoint arthmetic, using
builtin types.
* Converting constructor is implicit, since conversions (such
as reductions in precision) are so common, in fixedpoint
arithmetic.
* add/subtract return the greater of the int_bits and
frac_bits (independently) of the operands.
* add/subtract returns signedness of the type with the
greater range (choosing unsigned, in the event of a tie).
* multiply returns a type in which the int and frac bits
are the sum of the corresponding values of the operands.
The result is signed, unless both operands are unsigned.
* The return type of divide is equivalent to multiplying
the numerator by the inverse of the denominator.
* inverse returns a type with one fewer frac bits than the
operand had int bits and one more int bits than the
operand had frac bits. This sacrifice of precision is
necessary to avoid overflow.
I like the idea of abstracting the assigner, but I guess I don't really see what you'd want to vary besides perhaps rounding behavior.
One area in which I spent a fair amount of time was fast conversion to/from IEEE floatingpoint. In trying to use the roundingbyadding trick, I got slightly burned by differences in FPU configuration of Linux vs. Windows. With x87 arithmetic, the default FPU configuration keeps different amounts of intermediate precision.
Optimized formatted string conversion was another time sink.
Matt
________________________________
From: boostbounces_at_[hidden] on behalf of Ravi
Sent: Sun 3/13/2011 5:24 PM
To: boost_at_[hidden]
Subject: [boost] [boostcon][proto] Suggestion for LIAW session: fixedpointnumbers
Hi,
Are there any protobased ideas for the libraryinaweek sessions? If not,
would building a fixedpoint data type be of interest? The domain is narrow
enough that something useful can be accomplished in 4 sessions, but of large
enough scope to present opportunities for exploring proto in depth. A fairly
simple design follows representing a number:
fixed_number<int width,
int ulp, // 2^{ulp} is the smallest increment possible
bool signed,
template assigner<first, last, signed> >
'assigner' handles rounding/truncation/wrapping/etc when assigning another
number (floatingpoint or fixedpoint) to the current one. Internally, each
fixedpoint number would be represented by a boost::uint64_t or a
boost::int64_t (limiting the maximum precision allowed). As an example,
fixed_number<5, 3, false>
would represent a data type that would go from 0 to 3.875 in steps of 0.125.
Proto would be used for creating all arithmetic operations since the return
type of a+b could be different from the type of either a or b. A bonus would
involve getting the fixedpoint data type to play well with std::complex (and,
yes, I am aware that std::complex is not designed to work with anything other
than double and float, and will require specialization in the std namespace).
If there is sufficient interest, I could even provide a starting point with
+,,* implemented; / would take more time. The design above is intended as a
starting point for discussion and I am most definitely not wedded to it. I am
a tyro when it comes to proto, and hence would need someone with more proto
expertise to guide the discussion.
Regards,
Ravi
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk