Boost logo

Boost :

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

Gabriel Dos Reis wrote:
> John Max Skaller <skaller_at_[hidden]> writes:
> | My 'gut feeling' on this is that the basic
> | calculations don't involve rounding at all.
> | They're exact.
> They are exact only if there is no overflow


> However, intermediate results can overflow whereas
> the exact final result could be represented in the given floating
> point datatype as you acknowledge it here:

        Yes, except I refer to an _integer_ not floating

> | ... One problem with this approach
> | is that overflow on multiply occurs before rounding:
> | if the rounding is 'built-in' to the multiply, it is possible
> | to avoid overflow in some cases:
> |
> | decimal<n> mul<n>(decimal<n> a, decimal<n> b)
> |
> | is more general and could avoid overflows (by, for example,
> | scaling the arguments first, before multiplying).
> And that situation is not uncommon.

        I agree.
> That is why a trait-based solution can give best of both worlds.

        I do not see how. My concern is that 'traits' are
global, and that rounding, etc, must in general be managed
locally. Perhaps I misunderstand what you mean by traits,
but I'm thinking of a global 'rounding mode' flag,
and that isn't something I like at all, because I don't
think that, for example, the rounding mode is something
that should be the same for all multiplications:
I don't see that the rounding mode is a property of the data,
it is property of each individual operation.

        Perhaps the traits can be used as a default for
an argument to the operation: but I like that even less
than a fixed universal rounding mode with an override:
I want to know what the code does by looking in one place.

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