1. ESL - math.e - rounding
Hi all,
here are some thoughts concerning ESL rounding functions.
Any function for rounding a number should take a second argument that
denotes the number of digital places that we want the result to have,
e.g.
round(77.123456, 3) = 77.123
There is an IEEE standard for rounding. A *different* way of rounding
is what we call in German "kaufmaennisches Runden".
Translated word by word to English, this would be "commercial rounding".
Does this (or a similar) term exist in English?
round_half_even(x,n) -- according to IEEE
round_half_up(x,n) -- "kaufmaennisches Runden"
Both functions sometimes return different results, when the (n+1)th
decimal place of x equals 5:
round_half_even() -- rounds to nearest even value
round_half_up() -- always rounds up ( surprise! 
)
-- Example
x = 7.125
round_half_even(x,2) --> 7.12
round_half_up(x,2) --> 7.13
x = 7.135
round_half_even(x,2) --> 7.14
round_half_up(x,2) --> 7.14
What do you all think?
Regards,
Juergen
--
Have you read a good program lately?
2. Re: ESL - math.e - rounding
Juergen Luethje wrote:
>
> Hi all,
>
> here are some thoughts concerning ESL rounding functions.
>
> Any function for rounding a number should take a second argument that
> denotes the number of digital places that we want the result to have,
> e.g.
> round(77.123456, 3) = 77.123
>
> There is an IEEE standard for rounding. A *different* way of rounding
> is what we call in German "kaufmaennisches Runden".
> Translated word by word to English, this would be "commercial rounding".
> Does this (or a similar) term exist in English?
> round_half_even(x,n) -- according to IEEE
> round_half_up(x,n) -- "kaufmaennisches Runden"
>
>
> Both functions sometimes return different results, when the (n+1)th
> decimal place of x equals 5:
> round_half_even() -- rounds to nearest even value
> round_half_up() -- always rounds up ( surprise! )
>
> -- Example
> x = 7.125
> round_half_even(x,2) --> 7.12
> round_half_up(x,2) --> 7.13
>
> x = 7.135
> round_half_even(x,2) --> 7.14
> round_half_up(x,2) --> 7.14
>
>
> What do you all think?
>
round_half_up() would be roof() in qb.
There's also a function called floor() in qb, which always rounds down.
I quite often end up coding my own implementations of these.
Regards, Alexander Toresson
3. Re: ESL - math.e - rounding
Juergen Luethje wrote:
>
> Hi all,
>
> here are some thoughts concerning ESL rounding functions.
>
> Any function for rounding a number should take a second argument that
> denotes the number of digital places that we want the result to have,
> e.g.
> round(77.123456, 3) = 77.123
>
> There is an IEEE standard for rounding. A *different* way of rounding
> is what we call in German "kaufmaennisches Runden".
> Translated word by word to English, this would be "commercial rounding".
> Does this (or a similar) term exist in English?
> round_half_even(x,n) -- according to IEEE
> round_half_up(x,n) -- "kaufmaennisches Runden"
>
>
> Both functions sometimes return different results, when the (n+1)th
> decimal place of x equals 5:
> round_half_even() -- rounds to nearest even value
> round_half_up() -- always rounds up ( surprise! )
>
> -- Example
> x = 7.125
> round_half_even(x,2) --> 7.12
> round_half_up(x,2) --> 7.13
>
> x = 7.135
> round_half_even(x,2) --> 7.14
> round_half_up(x,2) --> 7.14
>
>
> What do you all think?
>
> Regards,
> Juergen
>
> --
> Have you read a good program lately?
>
>
Not being a memember of the IEEE standards committee, round_half_up() would be
the behavior I expect from a rounding function. That was the way I was always
taught to round.
Except, how does it work for negative numbers? Does it round towards + or -?
Alexander Toresson wrote:
> round_half_up() would be roof() in qb.
> There's also a function called floor() in qb, which always rounds down.
It would be nice to have different words for this. For one Euphoria already has
a floor() function, for two it sounds like I'm building a house instead of a
program.
Just like peek() and poke() make me feel like a pervert.
How about
round_up(num, places)
round_down(num, places)
round_even(num, places)
Also, how do these functions work on numbers with very large exponents? Such as
7.135e15? Are they only for numbers within 15 significant figures of 0?
=====================================
Too many freaks, not enough circuses.
j.
4. Re: ESL - math.e - rounding
On Wed, 03 Aug 2005 14:53:22 +0200, Juergen Luethje <j.lue at gmx.de>
wrote:
>Both functions sometimes return different results, when the (n+1)th
>decimal place of x equals 5:
> round_half_even() -- rounds to nearest even value
> round_half_up() -- always rounds up ( surprise! )
>
>What do you all think?
UK VAT law would allow either, or round_half_down.
Another function to consider is knock_on_round(), for example if you
have a column of 100 7.125's, then they should be 7.12, 7.13, 7.12...
so that the sum of the rounded amounts is 712.50, not 712.00.
A clear_knock_on_round function would be an absolute necessity, or a
get/set pair for maximum flexibility.
Pete
5. Re: ESL - math.e - rounding
Jason Gade wrote:
>
> Juergen Luethje wrote:
> >
> > Hi all,
> >
> > here are some thoughts concerning ESL rounding functions.
> >
> > Any function for rounding a number should take a second argument that
> > denotes the number of digital places that we want the result to have,
> > e.g.
> > round(77.123456, 3) = 77.123
> >
> > There is an IEEE standard for rounding. A *different* way of rounding
> > is what we call in German "kaufmaennisches Runden".
> > Translated word by word to English, this would be "commercial rounding".
> > Does this (or a similar) term exist in English?
> > round_half_even(x,n) -- according to IEEE
> > round_half_up(x,n) -- "kaufmaennisches Runden"
> >
> >
> > Both functions sometimes return different results, when the (n+1)th
> > decimal place of x equals 5:
> > round_half_even() -- rounds to nearest even value
> > round_half_up() -- always rounds up ( surprise! )
> >
> > -- Example
> > x = 7.125
> > round_half_even(x,2) --> 7.12
> > round_half_up(x,2) --> 7.13
> >
> > x = 7.135
> > round_half_even(x,2) --> 7.14
> > round_half_up(x,2) --> 7.14
> >
> >
> > What do you all think?
> >
> > Regards,
> > Juergen
> >
> > --
> > Have you read a good program lately?
> >
> >
> Not being a memember of the IEEE standards committee, round_half_up() would be
> the
> behavior I expect from a rounding function. That was the way I was always
> taught to
> round.
>
> Except, how does it work for negative numbers? Does it round towards + or -?
>
>
> Alexander Toresson wrote:
> > round_half_up() would be roof() in qb.
> > There's also a function called floor() in qb, which always rounds down.
>
> It would be nice to have different words for this. For one Euphoria already
> has a floor()
> function, for two it sounds like I'm building a house instead of a program.
Oh, yes, it's round() (which rounds to the nearest integer) and roof() that I
always have to reimplement.
> Just like peek() and poke() make me feel like a pervert.
Lol, yes, and peek4u() is even worse :)
> How about
> round_up(num, places)
> round_down(num, places)
> round_even(num, places)
That's a good propotion.
> Also, how do these functions work on numbers with very large exponents? Such
> as 7.135e15?
> Are they only for numbers within 15 significant figures of 0?
>
Well, I don't think it would work very well to round 7.135e15 to the nearest
integer, because 64-bit floats are starting to become inaccurate with that many
decimals. I recommend checking out the following great article about the
bottlenecks of floats:
http://www.cfxweb.net/modules.php?name=News&file=article&sid=1312&mode=&order=0&thold=0
Regards, Alexander Toresson
6. Re: ESL - math.e - rounding
Pete Lomax wrote:
>
> On Wed, 03 Aug 2005 14:53:22 +0200, Juergen Luethje <j.lue at gmx.de>
> wrote:
>
> >Both functions sometimes return different results, when the (n+1)th
> >decimal place of x equals 5:
> > round_half_even() -- rounds to nearest even value
> > round_half_up() -- always rounds up ( surprise! )
> >
> >What do you all think?
>
> UK VAT law would allow either, or round_half_down.
>
> Another function to consider is knock_on_round(), for example if you
> have a column of 100 7.125's, then they should be 7.12, 7.13, 7.12...
> so that the sum of the rounded amounts is 712.50, not 712.00.
>
> A clear_knock_on_round function would be an absolute necessity, or a
> get/set pair for maximum flexibility.
>
> Pete
>
>
What is it (knock_on_round) used for? I mean, if I have a hundred numbers with 3
significant digits then I would add them up *before* rounding them. You wouldn't
want to lose precision before getting your final answer, would you?
Would it take a sequence of numbers and round the odd list elements up and then
the even list elements down?
Are there similar functions in spreadsheets?
=====================================
Too many freaks, not enough circuses.
j.
7. Re: ESL - math.e - rounding
Jason Gade wrote:
>
> Pete Lomax wrote:
> >
> > On Wed, 03 Aug 2005 14:53:22 +0200, Juergen Luethje <j.lue at gmx.de>
> > wrote:
> >
> > >Both functions sometimes return different results, when the (n+1)th
> > >decimal place of x equals 5:
> > > round_half_even() -- rounds to nearest even value
> > > round_half_up() -- always rounds up ( surprise! )
> > >
> > >What do you all think?
> >
> > UK VAT law would allow either, or round_half_down.
> >
> > Another function to consider is knock_on_round(), for example if you
> > have a column of 100 7.125's, then they should be 7.12, 7.13, 7.12...
> > so that the sum of the rounded amounts is 712.50, not 712.00.
> >
> > A clear_knock_on_round function would be an absolute necessity, or a
> > get/set pair for maximum flexibility.
> >
> > Pete
> >
> >
> What is it (knock_on_round) used for? I mean, if I have a hundred numbers with
> 3 significant
> digits then I would add them up *before* rounding them. You wouldn't want to
> lose precision
> before getting your final answer, would you?
>
That may not be practical.
Say the total before (knock_on_round) is what you payed for x amount of units.
When you total the amount sold the next day by the cost of each individual
unit (there would be some 7.12 and some 7.13 then the total cost of sales
would be more accurate.
Don Cole,
SF
8. Re: ESL - math.e - rounding
Jason Gade wrote:
> Juergen Luethje wrote:
>>
>> Hi all,
>>
>> here are some thoughts concerning ESL rounding functions.
>>
>> Any function for rounding a number should take a second argument that
>> denotes the number of digital places that we want the result to have,
>> e.g.
>> round(77.123456, 3) = 77.123
>>
>> There is an IEEE standard for rounding. A *different* way of rounding
>> is what we call in German "kaufmaennisches Runden".
>> Translated word by word to English, this would be "commercial rounding".
>> Does this (or a similar) term exist in English?
>> round_half_even(x,n) -- according to IEEE
>> round_half_up(x,n) -- "kaufmaennisches Runden"
>>
>>
>> Both functions sometimes return different results, when the (n+1)th
>> decimal place of x equals 5:
>> round_half_even() -- rounds to nearest even value
>> round_half_up() -- always rounds up ( surprise! )
>>
>> -- Example
>> x = 7.125
>> round_half_even(x,2) --> 7.12
>> round_half_up(x,2) --> 7.13
>>
>> x = 7.135
>> round_half_even(x,2) --> 7.14
>> round_half_up(x,2) --> 7.14
>>
>>
>> What do you all think?
>
>
> Not being a memember of the IEEE standards committee, round_half_up()
> would be the behavior I expect from a rounding function. That was the
> way I was always taught to round.
Same for me. That was the only way of rounding that I learned at
school. But there actually is the IEEE standard that I mentioned.
And for instance PowerBASIC's round() function works according to it.
> Except, how does it work for negative numbers? Does it round towards + or -?
Sorry, I forgot about that. As far as I know (math experts might want to
correct me) round_half_even() works the same as for positive numbers,
and round_half_up() always rounds up the absolute value:
-- Example
x = -7.125
round_half_even(x,2) --> -7.12
round_half_up(x,2) --> -7.13
x = -7.135
round_half_even(x,2) --> -7.14
round_half_up(x,2) --> -7.14
------------------------------------------------------------------------
> Alexander Toresson wrote:
>> round_half_up() would be roof() in qb.
>> There's also a function called floor() in qb, which always rounds down.
Alexander, what do you mean with "qb"? QBasic? Quick Basic?
In all languages that I know which have a floor() function, floor() does
the same as Euphoria's floor() does. The opposite of floor() normally is
called ceil().
It sounds to me that we are talking about different things here.
> It would be nice to have different words for this. For one Euphoria
> already has a floor() function, for two it sounds like I'm building a
> house instead of a program.
>
> Just like peek() and poke() make me feel like a pervert.
>
> How about
> round_up(num, places)
> round_down(num, places)
> round_even(num, places)
For almost all cases, there are rules when to round up, and when to
round down, which a round function should know and apply automatically.
The only problem arises when the (n+1)th digit is '5', and no more
digits are following. I never heard of a function round_half_down().
And this should not be confused with floor() or ceil().
> Also, how do these functions work on numbers with very large exponents?
> Such as 7.135e15? Are they only for numbers within 15 significant
> figures of 0?
Both proposed rounding functions normally work the way probably everyone
would expect a rounding function to work. The only interesting point is,
when the (n+1)th digit is '5', and no more digits are following.
*If* Euphoria works with 15 decimal places internally (this is just a
guess), then of course it wouldn't make sense to write e.g.
? round_half_up(x, 20)
Regards,
Juergen
9. Re: ESL - math.e - rounding
Pete Lomax wrote:
> On Wed, 03 Aug 2005 14:53:22 +0200, Juergen Luethje wrote:
>
>> Both functions sometimes return different results, when the (n+1)th
>> decimal place of x equals 5:
>> round_half_even() -- rounds to nearest even value
>> round_half_up() -- always rounds up ( surprise! )
>>
>> What do you all think?
>
> UK VAT law would allow either, or round_half_down.
Oh, interesting. Then we probably should have all three functions.
> Another function to consider is knock_on_round(), for example if you
> have a column of 100 7.125's, then they should be 7.12, 7.13, 7.12...
> so that the sum of the rounded amounts is 712.50, not 712.00.
I have the same question here as Jason.
> A clear_knock_on_round function would be an absolute necessity, or a
> get/set pair for maximum flexibility.
Regards,
Juergen
10. Re: ESL - math.e - rounding
Juergen Luethje wrote:
> > Alexander Toresson wrote:
> >> round_half_up() would be roof() in qb.
> >> There's also a function called floor() in qb, which always rounds down.
>
> Alexander, what do you mean with "qb"? QBasic? Quick Basic?
> In all languages that I know which have a floor() function, floor() does
> the same as Euphoria's floor() does. The opposite of floor() normally is
> called ceil().
> It sounds to me that we are talking about different things here.
We're talking about the same things. I'm just being a little confused.
Regards, Alexander Toresson
11. Re: ESL - math.e - rounding
> Date: Wed, 03 Aug 2005 14:53:22 +0200
> From: "Juergen Luethje" <j.lue at gmx.de>
> Subject: ESL - math.e - rounding
>
>
> Hi all,
>
> here are some thoughts concerning ESL rounding functions.
>
> Any function for rounding a number should take a second argument that
> denotes the number of digital places that we want the result to have,
> e.g.
> round(77.123456, 3) = 77.123
>
> There is an IEEE standard for rounding. A *different* way of rounding
> is what we call in German "kaufmaennisches Runden".
> Translated word by word to English, this would be "commercial rounding".
> Does this (or a similar) term exist in English?
> round_half_even(x,n) -- according to IEEE
> round_half_up(x,n) -- "kaufmaennisches Runden"
>
>
> Both functions sometimes return different results, when the (n+1)th
> decimal place of x equals 5:
> round_half_even() -- rounds to nearest even value
> round_half_up() -- always rounds up ( surprise! )
>
> -- Example
> x = 7.125
> round_half_even(x,2) --> 7.12
> round_half_up(x,2) --> 7.13
>
> x = 7.135
> round_half_even(x,2) --> 7.14
> round_half_up(x,2) --> 7.14
>
>
> What do you all think?
>
> Regards,
> Juergen
>
In theory, we need the 4 rounding modes below. And the Intel FP
architecture supports them all.
[Quoting from Intel FPU documentation]
Table 4-8. Rounding Modes and Encoding of Rounding Control (RC) Field
--------------------------------------------------------------------
Rounding ! RC Field ! Setting Description
Mode ! !
---------------+----------+----------------------------------------
! ! Rounded result is the closest to the
Round to ! 00B ! infinitely precise result. If two values
nearest (even) ! ! are equally close, the result is the even
! ! value (that is, the one with the
! ! least-significant bit of zero). Default
---------------+----------+------------------------------------------
Round down ! ! Rounded result is closest to but no greater
(toward =E2=88=92=E2=88=9E) ! 01B !than the infinitely precise resu=
lt.
---------------+----------+------------------------------------------
Round up ! ! Rounded result is closest to but no less
(toward +=E2=88=9E) ! 10B !than the infinitely precise result.
---------------+----------+------------------------------------------
Round toward ! ! Rounded result is closest to but no greater
zero (Truncate)! 11B !in absolute value than the infinitely precise
! !result.
---------------------------------------------------------------------
Commercial rounding is just rounding up, while scientific calculations
use round to nearst more often.
CChris
12. Re: ESL - math.e - rounding
Alexander Toresson wrote:
> Juergen Luethje wrote:
>>> Alexander Toresson wrote:
>>>> round_half_up() would be roof() in qb.
>>>> There's also a function called floor() in qb, which always rounds down.
I was *not* talking about a function which always rounds down.
>> Alexander, what do you mean with "qb"? QBasic? Quick Basic?
I still don't know what you mean with "qb".
>> In all languages that I know which have a floor() function, floor() does
>> the same as Euphoria's floor() does. The opposite of floor() normally is
>> called ceil().
>> It sounds to me that we are talking about different things here.
>
> We're talking about the same things. I'm just being a little confused.
I don't think so.
Regards,
Juergen
13. Re: ESL - math.e - rounding
Juergen Luethje wrote:
>
> Alexander Toresson wrote:
>
> > Juergen Luethje wrote:
> >>> Alexander Toresson wrote:
> >>>> round_half_up() would be roof() in qb.
> >>>> There's also a function called floor() in qb, which always rounds down.
>
> I was *not* talking about a function which always rounds down.
Hmm
> >> Alexander, what do you mean with "qb"? QBasic? Quick Basic?
>
> I still don't know what you mean with "qb".
Yep, QBasic/QuickBasic
> >> In all languages that I know which have a floor() function, floor() does
> >> the same as Euphoria's floor() does. The opposite of floor() normally is
> >> called ceil().
> >> It sounds to me that we are talking about different things here.
> >
> > We're talking about the same things. I'm just being a little confused.
>
> I don't think so.
>
Then I don't think so either.
Regards, Alexander Toresson
14. Re: ESL - math.e - rounding
Alexander Toresson wrote:
> Juergen Luethje wrote:
>
>> Alexander Toresson wrote:
>>
>>> Juergen Luethje wrote:
>>>>> Alexander Toresson wrote:
>>>>>> round_half_up() would be roof() in qb.
>>>>>> There's also a function called floor() in qb, which always rounds down.
>>
>> I was *not* talking about a function which always rounds down.
>
> Hmm
When you read again my original post in this thread, and then read the
documentation of Euphoria's floor(), you'll probably see the difference
concerning syntax *and* meaning between my suggested functions and e.g.
floor().
<snip>
Regards,
Juergen
15. Re: ESL - math.e - rounding
Juergen Luethje wrote:
>
> Alexander Toresson wrote:
>
> > Juergen Luethje wrote:
> >
> >> Alexander Toresson wrote:
> >>
> >>> Juergen Luethje wrote:
> >>>>> Alexander Toresson wrote:
> >>>>>> round_half_up() would be roof() in qb.
> >>>>>> There's also a function called floor() in qb, which always rounds down.
> >>
> >> I was *not* talking about a function which always rounds down.
> >
> > Hmm
>
> When you read again my original post in this thread, and then read the
> documentation of Euphoria's floor(), you'll probably see the difference
> concerning syntax *and* meaning between my suggested functions and e.g.
> floor().
>
I have never stated that floor() would be equal to round_half_even() or
round_half_up().
Regards, Alexander Toresson
16. Re: ESL - math.e - rounding
- Posted by "Juergen Luethje" <j.lue at gmx.de>
Aug 03, 2005
-
Last edited Aug 04, 2005
Alexander Toresson wrote:
> Juergen Luethje wrote:
>>
>> Alexander Toresson wrote:
>>
>>> Juergen Luethje wrote:
>>>
>>>> Alexander Toresson wrote:
>>>>
>>>>> Juergen Luethje wrote:
>>>>>>> Alexander Toresson wrote:
>>>>>>>> round_half_up() would be roof() in qb.
>>>>>>>> There's also a function called floor() in qb, which always rounds down.
>>>>
>>>> I was *not* talking about a function which always rounds down.
>>>
>>> Hmm
>>
>> When you read again my original post in this thread, and then read the
>> documentation of Euphoria's floor(), you'll probably see the difference
>> concerning syntax *and* meaning between my suggested functions and e.g.
>> floor().
>
> I have never stated that floor() would be equal to round_half_even() or
> round_half_up().
I know.
BTW: In case you are interested in the topic, you might want to read my
original post, and you might want to read it carefully.
Regards,
Juergen
Regards,
Juergen
17. Re: ESL - math.e - rounding
Juergen Luethje wrote:
>
> Alexander Toresson wrote:
>
> > Juergen Luethje wrote:
> >>
> >> Alexander Toresson wrote:
> >>
> >>> Juergen Luethje wrote:
> >>>
> >>>> Alexander Toresson wrote:
> >>>>
> >>>>> Juergen Luethje wrote:
> >>>>>>> Alexander Toresson wrote:
> >>>>>>>> round_half_up() would be roof() in qb.
> >>>>>>>> There's also a function called floor() in qb, which always rounds
> >>>>>>>> down.
> >>>>
> >>>> I was *not* talking about a function which always rounds down.
> >>>
> >>> Hmm
> >>
> >> When you read again my original post in this thread, and then read the
> >> documentation of Euphoria's floor(), you'll probably see the difference
> >> concerning syntax *and* meaning between my suggested functions and e.g.
> >> floor().
> >
> > I have never stated that floor() would be equal to round_half_even() or
> > round_half_up().
>
> I know.
>
> BTW: In case you are interested in the topic, you might want to read my
> original post, and you might want to read it carefully.
>
I was stating that I missed that kind of functions after I switched from another
language. That was just some random thoughts. I'm so sorry if I violated the
almighty Topic (c). Now I'll stfu.
Regards, Alexander Toresson
(PS. I'll really stfu, cos I'm going on holiday for 10 days. All replies to any
of my recent posts will be redirected to /dev/null, or at least have a hugde
delay. kthxbye.)
18. Re: ESL - math.e - rounding
Christian Cuvier wrote:
<snip>
> In theory, we need the 4 rounding modes below.
I think we should have all 4 rounding modes in the ESL, shouldn't we?
> And the Intel FP architecture supports them all.
>
> [Quoting from Intel FPU documentation]
>
> Table 4-8. Rounding Modes and Encoding of Rounding Control (RC) Field
>
> --------------------------------------------------------------------
> Rounding ! RC Field ! Setting Description
> Mode ! !
> ---------------+----------+----------------------------------------
> ! ! Rounded result is the closest to the
> Round to ! 00B ! infinitely precise result. If two values
> nearest (even) ! ! are equally close, the result is the even
> ! ! value (that is, the one with the
> ! ! least-significant bit of zero). Default
> ---------------+----------+------------------------------------------
> Round down ! ! Rounded result is closest to but no greater
> (toward =E2=88=92=E2=88=9E) ! 01B !than the infinitely precise resu=
> lt.
> ---------------+----------+------------------------------------------
> Round up ! ! Rounded result is closest to but no less
> (toward +=E2=88=9E) ! 10B !than the infinitely precise result.
> ---------------+----------+------------------------------------------
> Round toward ! ! Rounded result is closest to but no greater
> zero (Truncate)! 11B ! in absolute value than the infinitely precise
>
> ! ! result.
> ---------------------------------------------------------------------
Interesting, thanks for the information.
It looks as if this must be programmed by using special FP assembler
instructions. So this is no job for me ...
> Commercial rounding is just rounding up, while scientific calculations
> use round to nearst more often.
>
> CChris
Regards,
Juergen
19. Re: ESL - math.e - rounding
Juergen Luethje wrote:
>
> Christian Cuvier wrote:
>
> <snip>
>
> > In theory, we need the 4 rounding modes below.
>
> I think we should have all 4 rounding modes in the ESL, shouldn't we?
>
> > And the Intel FP architecture supports them all.
> >
> > [Quoting from Intel FPU documentation]
> >
> > Table 4-8. Rounding Modes and Encoding of Rounding Control (RC) Field
> >
> > --------------------------------------------------------------------
> > Rounding ! RC Field ! Setting Description
> > Mode ! !
> > ---------------+----------+----------------------------------------
> > ! ! Rounded result is the closest to the
> > Round to ! 00B ! infinitely precise result. If two values
> > nearest (even) ! ! are equally close, the result is the even
> > ! ! value (that is, the one with the
> > ! ! least-significant bit of zero). Default
> > ---------------+----------+------------------------------------------
> > Round down ! ! Rounded result is closest to but no greater
> > (toward =E2=88=92=E2=88=9E) ! 01B !than the infinitely precise resu=
> > lt.
> > ---------------+----------+------------------------------------------
> > Round up ! ! Rounded result is closest to but no less
> > (toward +=E2=88=9E) ! 10B !than the infinitely precise result.
> > ---------------+----------+------------------------------------------
> > Round toward ! ! Rounded result is closest to but no greater
> > zero (Truncate)! 11B ! in absolute value than the infinitely precise
> >
> > ! ! result.
> > ---------------------------------------------------------------------
>
> Interesting, thanks for the information.
> It looks as if this must be programmed by using special FP assembler
> instructions. So this is no job for me ...
>
> > Commercial rounding is just rounding up, while scientific calculations
> > use round to nearst more often.
> >
> > CChris
>
> Regards,
> Juergen
>
>
We don't have to implement it in assembler. Just use the functions provided by
the hardware as a guide to what functions ESL should provide.
=====================================
Too many freaks, not enough circuses.
j.
20. Re: ESL - math.e - rounding
I thought that ESL was going to be discussed on UBOARD
and on SourceForge ?
Bernie
My files in archive:
w32engin.ew mixedlib.e eu_engin.e win32eru.exw
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
21. Re: ESL - math.e - rounding
> Date: Thu, 04 Aug 2005 17:32:04 +0200
> From: "Juergen Luethje" <j.lue at gmx.de>
> Subject: Re: ESL - math.e - rounding
>
>
> Christian Cuvier wrote:
>
> <snip>
>
>>> In theory, we need the 4 rounding modes below.
>
>
> I think we should have all 4 rounding modes in the ESL, shouldn't we?
>
>
>>> And the Intel FP architecture supports them all.
>>>
>>> [Quoting from Intel FPU documentation]
>>>
>>> Table 4-8. Rounding Modes and Encoding of Rounding Control (RC) Field
>>>
>>> --------------------------------------------------------------------
>>> Rounding ! RC Field ! Setting Description
>>> Mode ! !
>>> ---------------+----------+----------------------------------------
>>> ! ! Rounded result is the closest to the
>>> Round to ! 00B ! infinitely precise result. If two values
>>> nearest (even) ! ! are equally close, the result is the even
>>> ! ! value (that is, the one with the
>>> ! ! least-significant bit of zero). Default
>>> ---------------+----------+------------------------------------------
>>> Round down ! ! Rounded result is closest to but no greater
>>> (toward =E2=88=92=E2=88=9E) ! 01B !than the infinitely precise resu=
>>> lt.
>>> ---------------+----------+------------------------------------------
>>> Round up ! ! Rounded result is closest to but no less
>>> (toward +=E2=88=9E) ! 10B !than the infinitely precise result.
>>> ---------------+----------+------------------------------------------
>>> Round toward ! ! Rounded result is closest to but no greater
>>> zero (Truncate)! 11B ! in absolute value than the infinitely precise
>>>
>>> ! ! result.
>>> ---------------------------------------------------------------------
>
>
> Interesting, thanks for the information.
> It looks as if this must be programmed by using special FP assembler
> instructions. So this is no job for me ...
>
Yes and no.
The rounding modes described above may apply to two different things:
the internal operation of the FPU and the programmer-level functions.
For the former, you have to play with the fstcw ax and fldcw ax machine
instructions, by setting the appropriate bits in the ax register in between.
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().
CChris
>
>>> Commercial rounding is just rounding up, while scientific calculations
>>> use round to nearst more often.
>>>
>>> CChris
>
>
> Regards,
> Juergen
22. Re: ESL - math.e - rounding
Bernie Ryan wrote:
>
>
> I thought that ESL was going to be discussed on UBOARD
> and on SourceForge ?
>
> Bernie
>
> My files in archive:
> w32engin.ew mixedlib.e eu_engin.e win32eru.exw
>
> Can be downloaded here:
> <a
> href="http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan">http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan</a>
>
We do have a sourceforge mailing list that is active.
https://lists.sourceforge.net/lists/listinfo/esl-discussion
=====================================
Too many freaks, not enough circuses.
j.
23. Re: ESL - math.e - rounding
Bernie Ryan wrote:
> I thought that ESL was going to be discussed on UBOARD
> and on SourceForge ?
What is the reason for this question?
Regards,
Juergen
24. Re: ESL - math.e - rounding
Juergen Luethje wrote:
>
> Bernie Ryan wrote:
>
> > I thought that ESL was going to be discussed on UBOARD
> > and on SourceForge ?
>
> What is the reason for this question?
>
Juergen:
If 400 users all discussed every include file that they are
going to write or are writing; then there would be no room or
or time for anyone else that needs help or has a question.
Bernie
My files in archive:
w32engin.ew mixedlib.e eu_engin.e win32eru.exw
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
25. Re: ESL - math.e - rounding
- Posted by cklester <cklester at yahoo.com>
Aug 04, 2005
-
Last edited Aug 05, 2005
Bernie Ryan wrote:
>
>
> If 400 users all discussed every include file that they are
> going to write or are writing; then there would be no room or
> or time for anyone else that needs help or has a question.
Given the traffic this list generates, it's amusing for you to be concerned
that somebody will get lost in the off-topic noise. :D
-=ck
"Programming in a state of EUPHORIA."
http://www.cklester.com/euphoria/
26. Re: ESL - math.e - rounding
- Posted by "Juergen Luethje" <j.lue at gmx.de>
Aug 04, 2005
-
Last edited Aug 05, 2005
Bernie Ryan wrote:
> Juergen Luethje wrote:
>>
>> Bernie Ryan wrote:
>>
>>> I thought that ESL was going to be discussed on UBOARD
>>> and on SourceForge ?
>>
>> What is the reason for this question?
>>
>
> Juergen:
>
> If 400 users all discussed every include file that they are
> going to write or are writing; then there would be no room or
> or time for anyone else that needs help or has a question.
I think it's rather unlikely that 400 users will all discuss every file
of ESL.
ESL should be a valuable tool for all Eu programmers, so I think it makes
sense to discuss several things here.
On the ESL mailing list there are only 5 or 6 people AFAIK. Here are far
more people around, and some of them with much knowledge. So our small
ESL project group probably can learn from people in this forum. This
will lead to an increased quality of ESL, and so in principle will be of
use to every Eu programmer.
I firstly posted a similar message concerning rounding to the ESL
mailing list, but didn't get any reply.
Regards,
Juergen
27. Re: ESL - math.e - rounding
Christian Cuvier wrote:
>> From: "Juergen Luethje"
>>
>> Christian Cuvier wrote:
>>
>> <snip>
>>
>>>> In theory, we need the 4 rounding modes below.
>>
>> I think we should have all 4 rounding modes in the ESL, shouldn't we?
>>
>>>> And the Intel FP architecture supports them all.
>>>>
>>>> [Quoting from Intel FPU documentation]
>>>>
>>>> Table 4-8. Rounding Modes and Encoding of Rounding Control (RC) Field
>>>>
>>>> --------------------------------------------------------------------
>>>> Rounding ! RC Field ! Setting Description
>>>> Mode ! !
>>>> ---------------+----------+----------------------------------------
>>>> ! ! Rounded result is the closest to the
>>>> Round to ! 00B ! infinitely precise result. If two values
>>>> nearest (even) ! ! are equally close, the result is the even
>>>> ! ! value (that is, the one with the
>>>> ! ! least-significant bit of zero). Default
>>>> ---------------+----------+------------------------------------------
>>>> Round down ! ! Rounded result is closest to but no greater
>>>> (toward =E2=88=92=E2=88=9E) ! 01B !than the infinitely precise
>>>> resu=
>>>> lt.
>>>> ---------------+----------+------------------------------------------
>>>> Round up ! ! Rounded result is closest to but no less
>>>> (toward +=E2=88=9E) ! 10B !than the infinitely precise result.
>>>> ---------------+----------+------------------------------------------
>>>> Round toward ! ! Rounded result is closest to but no greater
>>>> zero (Truncate)! 11B ! in absolute value than the infinitely precise
>>>>
>>>> ! ! result.
>>>> ---------------------------------------------------------------------
>>
>>
>> Interesting, thanks for the information.
>> It looks as if this must be programmed by using special FP assembler
>> instructions. So this is no job for me ...
>>
>
> Yes and no.
>
> The rounding modes described above may apply to two different things:
> the internal operation of the FPU and the programmer-level functions.
>
> For the former, you have to play with the fstcw ax and fldcw ax machine
> instructions, by setting the appropriate bits in the ax register in between.
In the table above there often is the term "infinitely precise result".
Euphoria has a limited precision, and therefore doesn't know
the infinitely precise result. That's why I assumed it must be done by
using special assembler/machine instructions.
> 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!!!
-- 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).
-- 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.
<snip>
Regards,
Juergen
28. Re: ESL - math.e - rounding
> Date: Fri, 05 Aug 2005 09:26:03 +0200 From: "Juergen Luethje" <j.lue at
> gmx.de> Subject: Re: ESL - math.e - rounding Christian Cuvier wrote:
>
>>>>> From: "Juergen Luethje"
>>>>>
>>>>> Christian Cuvier wrote:
>>>>>
>>>>> <snip>
>>>>>
>>>
>>>>>>>>> In theory, we need the 4 rounding modes below.
>>>
>>>>>
>>>>> I think we should have all 4 rounding modes in the ESL, shouldn't we?
>>>>>
>>>
>>>>>>>>> And the Intel FP architecture supports them all.
>>>>>>>>>
>>>>>>>>> [Quoting from Intel FPU documentation]
>>>>>>>>>
>>>>>>>>> Table 4-8. Rounding Modes and Encoding of Rounding Control (RC) Field
>>>>>>>>>
>>>>>>>>> --------------------------------------------------------------------
>>>>>>>>> Rounding ! RC Field ! Setting Description
>>>>>>>>> Mode ! !
>>>>>>>>> ---------------+----------+----------------------------------------
>>>>>>>>> ! ! Rounded result is the closest to the
>>>>>>>>> Round to ! 00B ! infinitely precise result. If two values
>>>>>>>>> nearest (even) ! ! are equally close, the result is the even
>>>>>>>>> ! ! value (that is, the one with the
>>>>>>>>> ! ! least-significant bit of zero). Default
>>>>>>>>> ---------------+----------+------------------------------------------
>>>>>>>>> Round down ! ! Rounded result is closest to but no
>>>>>>>>> greater
>>>>>>>>> (toward =E2=88=92=E2=88=9E) ! 01B !than the infinitely precise
>>>>>>>>> resu=
>>>>>>>>> lt.
>>>>>>>>> ---------------+----------+------------------------------------------
>>>>>>>>> Round up ! ! Rounded result is closest to but no less
>>>>>>>>> (toward +=E2=88=9E) ! 10B !than the infinitely precise result.
>>>>>>>>> ---------------+----------+------------------------------------------
>>>>>>>>> Round toward ! ! Rounded result is closest to but no
>>>>>>>>> greater
>>>>>>>>> zero (Truncate)! 11B ! in absolute value than the infinitely
>>>>>>>>> precise
>>>>>>>>>
>>>>>>>>> ! ! result.
>>>>>>>>> ---------------------------------------------------------------------
>>>
>>>>>
>>>>> Interesting, thanks for the information.
>>>>> It looks as if this must be programmed by using special FP assembler
>>>>> instructions. So this is no job for me ...
>>>>>
>>
>>> Yes and no.
>>>
>>> The rounding modes described above may apply to two different things:
>>> the internal operation of the FPU and the programmer-level functions.
>>>
>>> For the former, you have to play with the fstcw ax and fldcw ax machine
>>> instructions, by setting the appropriate bits in the ax register in between.
>
>
> In the table above there often is the term "infinitely precise result".
> Euphoria has a limited precision, and therefore doesn't know
> the infinitely precise result. That's why I assumed it must be done by
> using special assembler/machine instructions.
>
Well, computers are finite state machines, so they never achieve
infinite precision.
What Inetl calls "infinite precision result" is a reusult stored with
all available bits (80, versus 64 for a double precision floating number).
If you want strict conformance with IEEE when rounding large atoms in
any rounding mode, then you may need the asm tweak. And due to the
overhead of call() in Euphoria (yet another thorn), that won't be too
efficient. But is strict conformance with IEEE a real concern?
Note that the asm tweak could be optimised if the ESL could be shipped
with a .so/.dll implementing these sorts of machine dependent stuff. Not
sure it is a good idea at all (could be however if such issues start
cropping up), and certainly not for a first release!
CChris
>
>>> 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!!!
>
> -- 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).
>
>
> -- 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.
>
> <snip>
>
> Regards,
> Juergen
29. Re: ESL - math.e - rounding
Juergen Luethje wrote:
<snip the table>
> In the table above there often is the term "infinitely precise result".
> Euphoria has a limited precision, and therefore doesn't know
> the infinitely precise result. That's why I assumed it must be done by
> using special assembler/machine instructions.
The way I understood "infinitely precise result" is as a term of mathematics,
not as a computer precision term.
Assume you have the real number x which has 20 significant digits. The computer
can represent numbers only with 15 significant digits greater than x or less than
x. You can round either way.
The infinitely precise result is if your number could be represented exactly
with an infinite number of significant figures, or an infinite number of zeros
trailing.
>
> > 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!!!
>
> -- 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 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.
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.
>
> <snip>
>
> Regards,
> Juergen
>
>
================================================================
"Actually, I'm sitting on my butt staring at a computer screen."
- Tom Tomorrow
j.
30. Re: ESL - math.e - rounding
Can we move this thread back to ESL-discussions? I think we're getting caught up
in implementation details that better belong there than here.
================================================================
"Actually, I'm sitting on my butt staring at a computer screen."
- Tom Tomorrow
j.
31. Re: ESL - math.e - rounding
On Wed, 03 Aug 2005 07:01:29 -0700, Jason Gade
<guest at RapidEuphoria.com> wrote:
>What is it (knock_on_round) used for? I mean, if I have a hundred
>numbers with 3 significant digits then I would add them up *before*
>rounding them. You wouldn't want to lose precision before getting your
>final answer, would you?
Imagine you buy a box of 10 network cards for 71.25, so that figure
appears somewhere on your accounts. But those cards are installed in
several different departments (Sales, Accounts, Despatch, Training,
etc) and you decide to record the costs against those departments.
If they are all 7.12 or all 7.13, your bottom line will be out by 5p.
The only way to avoid this is to make some 7.12 and some 7.13.
Whether or not this is common enough to appear in the ESL is a
different question, it was just a suggestion.
>Are there similar functions in spreadsheets?
Probably, I'm not sure though.
Regards,
Pete
32. Re: ESL - math.e - rounding
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!!!
>>
>> -- 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.
Regards,
Juergen
--
/"\ ASCII ribbon campain | Money is the root of all evil.
\ / against HTML in | Send 20 Dollars for more info.
X e-mail and news, |
/ \ and unneeded MIME | http://home.arcor.de/luethje/prog/
33. Re: ESL - math.e - rounding
Jason Gade wrote:
> Can we move this thread back to ESL-discussions?
It's not possible to move it "back", because it never has been there.
On 2005-07-31, I posted a message concerning rounding to the ESL
mailing list (similar to my original message in this thread), but I didn't
get any reply.
> I think we're getting caught up in implementation details that better
> belong there than here.
I don't want to discuss implementation details here.
But this rounding stuff is not trivial (as this thread confirmes again),
so I'd like to get "input" from people on this list, too (and there
already have been important posts from people who are not on the ESL
mailing-list).
Also ESL should be a valuable tool for all Eu programmers, so they
should have the possibility to tell us what they want.
When the idea of a Euphoria Standard Library came up recently, I liked
it, and I wanted to participate. I had a vision:
<http://esl.sourceforge.net/goals.htm>.
However, given some recent comments here it seems that people feel
bothered by discussions about ESL here, and given the fact that there
are only a handful participants in the project, I'm beginning to wonder,
how many people in this community actually would appreciate such a
Standard Library. I'll have to think about it more in depth, because I
know several other ways to spend my time, which are much more fun.
Regards,
Juergen
34. Re: ESL - math.e - rounding
On Sun, 07 Aug 2005 12:07:03 +0200, Juergen Luethje <j.lue at gmx.de>
wrote:
>> 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.
I would favour a plain round(v), with setRoundPlaces(2) and
setRoundType(EVEN), or maybe pp(), ppOpt(), ppEx() style.
Most users could then add a few lines right after the include
statement and just use round() throughout.
> But what is that function supposed to do, I mean what kinds
>of 'type' should be allowed?
>Allowing all 6 types would probably be too confusing IMHO.
>
I can imagine some code which uses round, and then either for
experiment or to re-use most of that code for a slightly different
purpose, want all the round() to behave as floor()... Lots of options
are a good thing, the only proviso being that differences between them
are clearly stated, and it is very quick to dismiss those you have no
interest in.
Pete
35. Re: ESL - math.e - rounding
Juergen Luethje wrote:
>
>
> Jason Gade wrote:
>
>
>>Can we move this thread back to ESL-discussions?
>
>
> It's not possible to move it "back", because it never has been there.
> On 2005-07-31, I posted a message concerning rounding to the ESL
> mailing list (similar to my original message in this thread), but I didn't
> get any reply.
>
Yes, I remember reading your original post and not responding. Sorry!
Maybe you are right because I think that it took a few responses to get
me to think about the issue a bit. But most of the responders have been
on the ESL list.
>
>>I think we're getting caught up in implementation details that better
>>belong there than here.
>
>
> I don't want to discuss implementation details here.
>
> But this rounding stuff is not trivial (as this thread confirmes again),
> so I'd like to get "input" from people on this list, too (and there
> already have been important posts from people who are not on the ESL
> mailing-list).
> Also ESL should be a valuable tool for all Eu programmers, so they
> should have the possibility to tell us what they want.
>
> When the idea of a Euphoria Standard Library came up recently, I liked
> it, and I wanted to participate. I had a vision:
> <http://esl.sourceforge.net/goals.htm>.
> However, given some recent comments here it seems that people feel
> bothered by discussions about ESL here, and given the fact that there
> are only a handful participants in the project, I'm beginning to wonder,
> how many people in this community actually would appreciate such a
> Standard Library. I'll have to think about it more in depth, because I
> know several other ways to spend my time, which are much more fun.
>
Only one person that I know of has complained and I didn't originally
recognize it as a complaint.
> Regards,
> Juergen
>
>
>
>
--
================================================================
"Actually, I'm sitting on my butt staring at a computer screen."
- Tom Tomorrow
j.
36. Re: ESL - math.e - rounding
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
37. Re: ESL - math.e - rounding
At 12:07 PM 8/7/05 +0200, Juergen wrote:
>
>
>Jason Gade wrote:
>
> > Can we move this thread back to ESL-discussions?
>
>It's not possible to move it "back", because it never has been there.
>On 2005-07-31, I posted a message concerning rounding to the ESL
>mailing list (similar to my original message in this thread), but I didn't
>get any reply.
<snip>
>When the idea of a Euphoria Standard Library came up recently, I liked
>it, and I wanted to participate. I had a vision:
><http://esl.sourceforge.net/goals.htm>.
>However, given some recent comments here it seems that people feel
>bothered by discussions about ESL here, and given the fact that there
>are only a handful participants in the project, I'm beginning to wonder,
>how many people in this community actually would appreciate such a
>Standard Library. I'll have to think about it more in depth, because I
>know several other ways to spend my time, which are much more fun.
>
>Regards,
> Juergen
I, for one, am looking forward to it. I think there may be some confusion
as to whether or not the active participants want comment here. I seem to
remember it was suggested that another list be created limited to 20 or so
members.
(Maybe my memory is bad.) That indicated to me that the new forum was the
place for discussion.
Bob
38. Re: ESL - math.e - rounding
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! 
39. Re: ESL - math.e - rounding
Sorry for the long post and the UTF-8 encoding. It mostly came out right.
For FE_UPWARD it should read: Round toward +infinity
For FE_DOWNWARD it should read Round toward -infinity
I don't care too much about the names, but this is my suggestion:
round(number, places) -- normal or "commercial" rounding
round_up(number, places) -- as FE_UPWARD, above
round_down(number, places) -- as FE_DOWNWARD, above
round_even(number, places) -- as "scientific" rounding
I don't know if round_zero(number, places) would be needed. Then there
would be 5 types of rounding.
I think round() would get the most use.
40. Re: ESL - math.e - rounding
Jason Gade wrote:
> 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.
Sorry, obviously I'm not good in expressing what I mean here. If my
previous posts didn't make it clear, I don't know how to express it
otherwise. I give up on this one.
Regards,
Juergen
41. Re: ESL - math.e - rounding
Juergen Luethje wrote:
>
>
> Jason Gade wrote:
>
>
>>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.
>
>
> Sorry, obviously I'm not good in expressing what I mean here. If my
> previous posts didn't make it clear, I don't know how to express it
> otherwise. I give up on this one.
Yeah, I'm in the same boat. I'm not trying to be offensive; for some
reason we don't seem to be meeting eye-to-eye and I don't quite
understand it.
> Regards,
> Juergen
>
>
>
>
--
================================================================
"Actually, I'm sitting on my butt staring at a computer screen."
- Tom Tomorrow
j.
42. Re: ESL - math.e - rounding
Jason Gade wrote:
> Juergen Luethje wrote:
>>
>> Jason Gade wrote:
>>
>>> 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.
>>
>> Sorry, obviously I'm not good in expressing what I mean here. If my
>> previous posts didn't make it clear, I don't know how to express it
>> otherwise. I give up on this one.
>
> Yeah, I'm in the same boat. I'm not trying to be offensive;
I know. No offense taken at all.
> for some reason we don't seem to be meeting eye-to-eye and I don't quite
> understand it.
Same for me.
Regards,
Juergen
