problem with RoundTo
in...@albanosoftware.it
see this function
#include <math.hpp>
x=RoundTo(1234,445,-2);
if i round 1234,445 the function return 1234,44 .... wrong i must to round
the number to 1234,45 with euro....
Can help me anyone ????
Thank Giorgio
Remy Lebeau (TeamB)
<in...@albanosoftware.it> wrote in message
news:44055dfc$1...@newsgroups.borland.com...
> if i round 1234,445 the function return 1234,44 .... wrong
Not wrong. That is what RoundTo() is supposed to do. There is even an
example of that in the documentation:
RoundTo(1.245, -2) -> 1.24
Gambit
Unknown
double x=RoundTo(1004.445,-2); // gives 1004,45 right
double x=RoundTo(2004.445,-2); // gives 2004,44 wrong
double x=RoundTo(4.445,-2); // gives 4,45 right
double x=RoundTo(225.445,-2); // gives 225,44 wrong
double x=RoundTo(226.445,-2); // gives 226,44 wrong
can you try other values to verify it ?
Ο <in...@albanosoftware.it> έγραψε στο μήνυμα
news:44055dfc$1...@newsgroups.borland.com...
Unknown
I had never use before this function(doesn't exist in BCB 5 ). The
documentation explains the behavior as Remy said.
So cancel my answer .
Ο "HF" <(min_charATyahooPUTADOTgr)(HellenicFire)> έγραψε στο μήνυμα
news:4405...@newsgroups.borland.com...
Thorsten Kettner
"HF" <(min_charATyahooPUTADOTgr)(HellenicFire)> wrote:
>> Smell of bug ! I tried with other values
>>
>> double x=RoundTo(1004.445,-2); // gives 1004,45 right
>> double x=RoundTo(2004.445,-2); // gives 2004,44 wrong
>> double x=RoundTo(4.445,-2); // gives 4,45 right
>> double x=RoundTo(225.445,-2); // gives 225,44 wrong
>> double x=RoundTo(226.445,-2); // gives 226,44 wrong
>>
>> can you try other values to verify it ?
>
As far as I read the help RoundTo uses Bankers Rounding, i.e. as
the rounding occurs with a five it must be rounded to a positive
digit. That means whatever number ends on .445 and gets rounded
to two decimal places must become .44. So you seem right, there
must be a bug - only that whenever you wrote "right" it's wrong
and vice versa ;-)
As far as it concerns the OP's question: Gambit is right, his
number 1234.445 gets rounded correctly to 1234.44. But your
investigations show that he was just "lucky" to get the correct
result which he regarded as wrong.
The bug may have to do with the approximation of floating point
numbers, i.e. 4.445 may be 4.4449999999999 internally, right?
Unknown
> As far as I read the help RoundTo uses Bankers Rounding, i.e. as
> the rounding occurs with a five it must be rounded to a positive
> digit. That means whatever number ends on .445 and gets rounded
> to two decimal places must become .44. So you seem right, there
> must be a bug - only that whenever you wrote "right" it's wrong
> and vice versa ;-)
I thought .445 had to be .45 but in help writes
Note:
The behavior of RoundTo can be affected by the Set8087CW procedure or
SetRoundMode function.
I have to make a small program to check it and understand how it works with
different TFPURoundingMode .
Thanks
Palle Meinert
/Palle
Remy Lebeau (TeamB)
"Thorsten Kettner" <ANSWERBYthor...@otto.de> wrote in message
news:44059172$1...@newsgroups.borland.com...
> As far as I read the help RoundTo uses Bankers Rounding, i.e.
> as the rounding occurs with a five it must be rounded to a
> positive digit.
Here is what the documentation actually says:
"RoundTo uses 'Banker's Rounding' to determine how to round values that
are exactly midway between the two values that have the desired number of
significant digits. This method rounds to an even number in the case that
AValue is not nearer to either value."
If you look up the definition of "Banker's Rounding" online, you will see
something like the following:
"When you add rounded values together, always rounding .5 in the same
direction results in a bias that grows with the more numbers you add
together. One way to minimize the bias is with banker's rounding.
"Banker's rounding rounds .5 up sometimes and down sometimes. The
convention is to round to the nearest even number, so that both 1.5 and 2.5
round to 2, and 3.5 and 4.5 both round to 4. Banker's rounding is symmetric.
"
Gambit
Remy Lebeau (TeamB)
"HF" <(min_charATyahooPUTADOTgr)(HellenicFire)> wrote in message
news:4405...@newsgroups.borland.com...
> I thought .445 had to be .45
Not under the "Banker's Rounding" algorithm, it doesn't.
Gambit
Thorsten Kkettner
"Remy Lebeau \(TeamB\)" <no....@no.spam.com> wrote:
>"Banker's rounding rounds .5 up sometimes and down sometimes.
>The convention is to round to the nearest even number, so that
>both 1.5 and 2.5 round to 2, and 3.5 and 4.5 both round to 4.
>Banker's rounding is symmetric."
Yes. And ?????.445 rounds to ?????.44. Which is what I said. And
which is what RoundTo fails to do sometimes, as HF found out.
Unknown
rmTruncate }
verifies both examples of help Documentation
RoundTo(1.235, -2) 1.24
RoundTo(1.245, -2) 1.24
I got the following
1,235 -> 1,24 rmNearest Help says : Rounds to the closest value
1,245 -> 1,25 rmNearest Help says : Rounds to the closest value
1,235 -> 1,23 rmDown Help says : Rounds toward negative infinity
1,245 -> 1,24 rmDown Help says : Rounds toward negative infinity
1,235 -> 1,24 rmUp Help says : Rounds toward positive infinity
1,245 -> 1,25 rmUp Help says : Rounds toward positive infinity
1,235 -> 1,23 rmTruncate Help says : Truncates the value, rounding
positive numbers down and negative numbers up
1,245 -> 1,24 rmTruncate Help says : Truncates the value, rounding
positive numbers down and negative numbers up
-minas
in...@albanosoftware.it
and RoundTo i cannot work. I saw the documentation but i think that this is
a bad bug......
"Palle Meinert" <N...@Spam.com> ha scritto nel messaggio
news:4405b630$1...@newsgroups.borland.com...
Thorsten Ketttner
"HF" <(min_charATyahooPUTADOTgr)(HellenicFire)> wrote:
>Hi again, which value of TFPURoundingMode { rmNearest,
>rmDown, rmUp, >rmTruncate } verifies both examples of help
>Documentation
>
>RoundTo(1.235, -2) 1.24
>RoundTo(1.245, -2) 1.24
As your test shows, rmDown works fine (it lowers the number),
rmUp works fine (it enlarges the number) and rmTruncate works
fine too (it truncates the number). Only the standard setting
of rmNearest which should do Banker's Rounding and give you
exactly the values you mention above fails to work correctly.
So the standard setting of rmNearest would be the right choice,
but RoundTo is buggy. Hence, if one really needs Banker's
Rounding instead of SimpleRoundTo, I'd suggest to write a
function for that manually.