OpenEuphoria

Re: ESL - math.e - rounding

• Posted by Jason Gade <jaygade at gmail.com> Aug 09, 2005
• 579 views

Hi, Juergen. I snipped all of the quoting because it was getting kind of=

confusing... I was having a difficult time knowing where to put my
comments. I'll try to start at the beginning.

At first you pointed out the difference between "commercial rounding"
which is this:
To round to n decimal places, look at the digit at position n+1. If it
is between 0 and 4 then truncate all digits past n. If it is between 5
and 9 then add one to the digit at n and truncate all digits past n.

And "scientific rounding" which is this:
To round to n decimal places, look at the digit at position n+1. If it
is between 0 and 4 then truncate all digits past n. If it is between 5
and 9 then add one to the digit at n and truncate all digits past n. If
it is exactly 5 (and some references say that n+2 should be 0) then add
1 to the digit at n only if that makes the digit at n even.

Looking at a number line, you can see why "commercial rounding" makes
sense. Scientific rounding makes sense because statistically "commercial=

rounding" can add a slight positive bias to data. Going to an even
number reduces that bias.

So your proposal was to have round_half_up() to represent the first case=

and round_half_even() to represent the second.

Then we started discussing round_up() and round_down() based on
Christian's post regarding Intel FP hardware.

Then there was some confusion on what all this means. After some
research, here's what I think.

I think round() should act like expected and use "commercial rounding".
I looked in MS Excel (hardly a reference standard, but useful) and that
is how the round function in it works. It doesn't have a corresponding
"scientific rounding" mode.

Or round could take a third parameter defining *how* it should work
corresponding to the Intel FP table. Relating GNU C library here is what=

I found that I think explains it a little better:

--quote from=20
http://www.gnu.org/software/libc/manual/html_node/Rounding.html#Rounding
Round to nearest.
     This is the default mode. It should be used unless there is a
specific need for one of the others. In this mode results are rounded to=

the nearest representable value. If the result is midway between two
representable values, the even representable is chosen. Even here means
the lowest-order bit is zero. This rounding mode prevents statistical
bias and guarantees numeric stability: round-off errors in a lengthy
calculation will remain smaller than half of FLT_EPSILON.
Round toward plus Infinity.
     All results are rounded to the smallest representable value which
is greater than the result.
Round toward minus Infinity.
     All results are rounded to the largest representable value which is=

less than the result.
Round toward zero.
     All results are rounded to the largest representable value whose
magnitude is less than that of the result. In other words, if the result=

is negative it is rounded up; if it is positive, it is rounded down.

fenv.h defines constants which you can use to refer to the various
rounding modes. Each one will be defined if and only if the FPU supports=

the corresponding rounding mode.

FE_TONEAREST
     Round to nearest.


FE_UPWARD
     Round toward +=E2=88=9E.


FE_DOWNWARD
     Round toward -=E2=88=9E.


FE_TOWARDZERO
     Round toward zero.
--end quote

You can see that their standard rounding mode is the "scientific" style.

In the example in my last message I was trying to demonstrate what
Christian's table meant by "infinitely precise" value. I guess that
wasn't very clear. Hopefully this table is.

In conclusion I don't see 6 different rounding modes but only 4 types.

I don't really have a preference except to say that I think adding the
word "half" in the middle of the routine names seems clumsy and
confusing to me. But after all this discussion *I'll* certainly know
what it means if that is the way it ends up!