On Sun, Mar 29, 2015 at 7:59 AM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> On Sun, Mar 29, 2015 at 5:34 AM, Gavin Flower
> <GavinFlower(at)archidevsys(dot)co(dot)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.
So, attached is a patch that does 1) and 2) to make clear to the user
how numeric and double precision behave regarding rounding. I am
adding it to CF 2015-06 to keep track of it...
--
Michael