On Sun, Mar 29, 2015 at 5:34 AM, Gavin Flower
<GavinFlower@archidevsys.co.nz> wrote:
> On 28/03/15 21:58, Dean Rasheed wrote:
> [...]
>>
>>
>> Andrew mentioned that there have been complaints from people doing
>> calculations with monetary data that we don't implement
>> round-to-nearest-even (Banker's) rounding. It's actually the case that
>> various different financial calculations demand different specific
>> rounding modes, so it wouldn't be enough to simply change the default
>> - we would have to provide a choice of modes.
>
> [...]
>
> Could the 2 current round functions have cousins that included an extra char
> parameter (or string), that indicated the type of rounding?
>
> So we don't end up with an explosion of rounding functions, yet could cope
> with a limited set of additional rounding modes initially, and possibly
> others in the future.
Instead of extending round, isn't what we are looking at here a new
data type? I have doubts that we only want to have a way to switch
round() between different modes. Hence, what we could do is:
1) Mention in the docs that numeric does round-half-away-from-zero
2) Add regression tests for numeric(n,m) and round(numeric)
3) Add a TODO item for something like numeric2, doing rounding-at-even
(this could be an extension as well), but with the number of
duplication that it may have with numeric, an in-core type would make
sense, to facilitate things exposing some of structures key structures
would help.
Regards,
--
Michael
