Re: ESL - math.e - rounding
- Posted by Jason Gade <jaygade at yahoo.com> Aug 05, 2005
- 767 views
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.