There seems to be a bug in the System.Windows.Rect structure. If you
create a new Rect with the following dimensions then the Right
property of the Rect has an invalid value which messes up comparison
code:
Rect rect = new Rect (123.677, 20.151, 39.523, 9.471);
This will create a Rect with a Right property of 163.20000000000002.
Any ideas?
The link that Larry gave you in his earlier response is the most definitive
explanation of the various issues faced by floating-point arithmetic on
computers that I've ever seen, and I thank him for putting it out there
again so that this time I could save the link for future questions of this
nature. But as the title of the document says it's directed toward computer
scientists. Someone who has taken a degree in computer science at a
university almost certainly has taken a class in computer hardware and has
been exposed to the pitfalls of floating-point computation, but most
programmers apparently don't have computer science degress or in the process
of getting one never actually got any exposure to computer hardware design
(do they even require a class like that anymore?)
The short answer is this: floating-point arithmetic is imprecise for most
computations. By most computations I mean those whose result cannot be
exactly represented in the binary representation that all modern computers
use for numbers. So if you're going to be doing comparisons on the results
you have to use techniques that allow for that imprecision. One way is to
round results to some suitable precision, another way is to not test for
exact equality but instead to test for nearness to the desired result. Yet a
third technique, suitable for such things as screen resolution questions, is
to merely convert the floating-point numbers to integers either by
truncation or rounding, whichever works best for your application, and then
compare the integers.
BTW, anybody remember the IBM 1620, which actually used variable-precision
decimal as its internal number representation?
Tom Dacon
Dacon Software Consulting
