From: nt_consulting64@yahoo.com
"Raoul Watson" wrote in message
news:IIPWl.1145$u86.308@nwrddc01.gnilink.net...
> Ralph wrote:
> ....
> >> we just have a different view as to what constitutes a
> > "bug". If something that is documented to behave a particular way, and
does
> > so consistently for some thirty years, I don't see how the fact you feel
it
> > should behave differently is in any way a "bug".
> ..
>
> You are absolutely right, our view differs. If round 0.585 produces the
> erroneous 0.58 as I have shown with the sample code, and we accepted MS
> explanation about the IEEE floating point issues for the past 30 years,
> then it is on us. MS has the ability to fix this issue. Anything that
> can be fixed but it's broken in code, I call a bug, you can call it
> whatever you want.
You keep harping on "MS", but if you check you will find "Banker's Rounding"
isn't a Microsoft invention. Accounting and 'Rounding Rules' (identified as
an assortment of names) existed long before computers, long before IEEE, and
long before Microsoft.
As I noted before there are many kinds of "Rounding" each with its own
'Business Rule', but what you continue to do, is to state "My rounding rule
is the only One True Rounding Rule and all else is an abomination before
me".
Your original response was useful - any time a programmer deals with
floating point numbers he must take precision under consideration, and work
out the business rules appropriate for his problem domain in order to
maintain that precision. A programmer must subsequently appreciate that not
all routines, functions, or methods provided by various libraries will in
fact be using the same rules, or even consistent between themselves. A
simple way to insure the programmer's BRs and expectations are upheld is to
provide his own custom routines.
-ralph
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
