OpenEuphoria

Re: ESL - math.e - rounding

• Posted by "Juergen Luethje" <j.lue at gmx.de> Aug 08, 2005
• 777 views

Jason Gade wrote:

> Juergen Luethje wrote:
>
>>
>> Jason Gade wrote:
>>
>>
>>> Juergen Luethje wrote:
>>>
>>>> Christian Cuvier wrote:
>>
>>
>> <snip>
>>
>>>>> For programmer level functions, there's hardly any need to tweak the FPU
>>>>> directly, except in extreme cases.
>>>>>
>>>>> A function generic_round(atom what, integer places,integer mode), which
>>>>> would be wrapped in various ways, would return as follows:
>>>>>
>>>>> what=7.126, places=2
>>>>> mode 0 -> 7.13
>>>>>      1 -> 7.12
>>>>>      2 -> 7.13
>>>>>      3 -> 7.12
>>>>>
>>>>> what=-7.126, places=2
>>>>> mode 0 -> -7.13
>>>>>      1 -> -7.13
>>>>>      2 -> -7.12
>>>>>      3 -> -7.12
>>>>>
>>>>> Everything can be done using floor(), sgn() and abs(), except that it is
>>>>> a bit tedious to write the wrappers and RDS doesn't provide abs() nor
>>>>> sgn().
>>>>
>>>> Thanks for your precise example above. Now I see, that we are talking
>>>> about different functions here. I'll try to clarify what I meant:
>>>>
>>>> I was meaning the functions
>>>>   round_half_up  (what, places)
>>>>   round_half_even(what, places)
>>>>   round_half_down(what, places)
>>>>
>>>> which in almost all cases return the same results!!!

E.g. Christian's function round_up() [as I understand it] *always*
rounds up, regardless of the value of the following digits,
his function round_down() *always* rounds down, regardless of the value
of the following digits. These are IMHO something like "advanced ceil()
and floor() functions", not what I normally consider rounding.
My functions round depending on the value of the following digits.

Example of Christian's functions [as I understand them]:

what = 7.126, places = 2
round_up  (what, places)  ->  7.13
round_even(what, places)  ->  7.12
round_down(what, places)  ->  7.12

what = -7.126, places = 2
round_up  (what, places)  ->  -7.13
round_even(what, places)  ->  -7.12
round_down(what, places)  ->  -7.12


My functions:

>>>> -- Example 1
>>>> what = 7.126, places = 2
>>>> round_half_up  (what, places)  ->  7.13
>>>> round_half_even(what, places)  ->  7.13
>>>> round_half_down(what, places)  ->  7.13
>>>>
>>>> what = -7.126, places = 2
>>>> round_half_up  (what, places)  ->  -7.13
>>>> round_half_even(what, places)  ->  -7.13
>>>> round_half_down(what, places)  ->  -7.13
>>>>
>>>>
>>>> The functions only might return different results, when the
>>>> (places+1)th digit is '5', and no more digits are following.
>>>> That's why there is the word 'half' in their names. I deliberately
>>>> did *not* name them
>>>>   round_up  ()
>>>>   round_even()
>>>>   round_down()
>>>> (as someone previously had assumed).
>>>
>>> That was me. I was reading the lines above and I thought the word 'half'
>>> was redundant until I noticed the qualifier "(places+1)th digit is '5',
>>> and no more digits are following."
>>>
>>> I still kind of think that the word 'half' is not needed.
>>
>>
>> I agree that it's probably not needed in the final name(s) of the
>> function(s) in ESL. But in the context of the current discussion here,
>> the word 'half' is important do distinguish my proposed functions
>>    round_half_up  ()
>>    round_half_even()
>>    round_half_down()
>>
>> from Christian's proposed functions
>>    round_up  ()
>>    round_even()
>>    round_down()
>>
>> because they work in different ways!
>>
>>
>>> I liked the suggestion earlier in the thread of having
>>> round(what, places, type) where type is the kind of rounding
>>> UP, DOWN, or NEAREST/EVEN.
>>
>>
>> I also think that a global function round(what, places, type) would
>> be elegant. But what is that function supposed to do, I mean what kinds
>> of 'type' should be allowed?
>>
>>    HALF_UP
>>    HALF_EVEN
>>    HALF_DOWN
>> according to my suggestion, or
>>
>>    UP
>>    EVEN
>>    DOWN
>> according to Christian's suggestion?
>>
>> Allowing all 6 types would probably be too confusing IMHO.
>>
>>
>>> Or even round(what, {places, type}) where if the second argument is an
>>> atom then type is the default (whatever that should be).
>>>
>>>
>>>> -- Example 2
>>>> what = 7.125, places = 2
>>>> round_half_up  (what, places)  ->  7.13
>>>> round_half_even(what, places)  ->  7.12
>>>> round_half_down(what, places)  ->  7.12
>>>>
>>>> what = -7.125, places = 2
>>>> round_half_up  (what, places)  ->  -7.13
>>>> round_half_even(what, places)  ->  -7.12
>>>> round_half_down(what, places)  ->  -7.12
>>>>
>>>>
>>>> -- Example 3
>>>> what = 7.135, places = 2
>>>> round_half_up  (what, places)  ->  7.14
>>>> round_half_even(what, places)  ->  7.14
>>>> round_half_down(what, places)  ->  7.13
>>>>
>>>> what = -7.135, places = 2
>>>> round_half_up  (what, places)  ->  -7.14
>>>> round_half_even(what, places)  ->  -7.14
>>>> round_half_down(what, places)  ->  -7.13
>>>>
>>>>
>>>> For instance PowerBASIC's round() function works like
>>>> the round_half_even() function. This is according to
>>>> IEEE standards.
>>
> Okay, I guess that I am unclear on how Christian's suggestions differ
> from your proposal.

See my attempt of explanation above.

> round_up(7.125, 2) = 7.13 -- closest to but not less than
> 7.12500000000000...

Sorry, I don't understand. Please explain more in detail what you mean.

> round_down(7.125, 2) = 7.12 -- closest to but not more than
> 7.12500000000000...
>
> round_even(7.125, 2) = 7.12 -- closest to 7.12500000000000... but even
>
> truncate(7.125, 2) = 7.12 -- closest to 7.12500000000000...
> truncate(-7.125, 2) = -7.12 -- closest to but not greater than (absolute
> value) -7.12500000000000...
>
> What am I missing?

Regards,
   Juergen