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.
> 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 http://Vyper.sourceforge.net download Interscript http://Interscript.sourceforge.net
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk