Boost logo

Boost :

From: John Max Skaller (skaller_at_[hidden])
Date: 2001-05-20 02:11:34

Howard Hinnant wrote:
> I'm not positive that a trait-based solution is not the way to go, but
> I'm not yet convinced it is yet either. One of the uses for rounding
> mode manipulation is to run a computation with it set two ways to get a
> feel for the roundoff error in the result. By making rounding mode a
> compile time decision one is mandating that such users will have twice
> the code size (than if it is a run time parameter).

        Use a template. Twice the generated code, only
one copy of the user test code. To my mind, the rounding mode
of a computation is a fundamental part of the semantics
and should be explicitly visible in the application
of the function. In other words, assuming we want
scale n * scale n -> scale n multiplication:


must be considered statically distinct functions: they have different

        The LIA-FP model isn't quite applicable here: it is intended
to model various hardware, emphasising _discovery_ of the rounding
mode used, and dynamically setting the mode of the hardware
(since that is often possible).

        Here, we're designing from scratch, so we can bypass
this nastiness and provide operations like multiply for
each rounding mode, allowing them to be easily mixed
within a calculation.

        Mixing is mandatory. A trivial example is:

        acc = acc + (principal[n] * rate[n])

where we use the bankers round for accumulation, and
round down on the multiply: both by specification
of business rules. You don't 'try out' these things
to see what 'feels nice': you follow the business rules
the accountant tells you to.

This is not 'numerical' programming where one balances
performance and precision, but business programming,
where one follows specified rules ( no matter how weird
they may be :-)

John (Max) Skaller, mailto:skaller_at_[hidden]
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper
download Interscript

Boost list run by bdawes at, gregod at, cpdaniel at, john at