-----Original Message----- From: inkscape-devel-bounces@lists.sourceforge.net [mailto:inkscape-devel-bounces@lists.sourceforge.net] On Behalf Of Bob Jamison Sent: maandag 1 september 2008 6:40 To: bulia byak; inkscape Subject: Re: [Inkscape-devel] Win32 nightly builds don't work since Aug 16
bulia byak wrote:
On Sun, Aug 31, 2008 at 2:24 PM, Alvin
Penner<penner@...1856...> wrote:
Investigation showed the following inequality throws the
exception:
(136.653830 , -638.496893) == (136.653830 , -638.496893)
which in hex looks like:
(406114EC2CAB84D2 , C083F3F9A32A10A6) == (406114EC2CAB84D2 , C083F3F9A32A10A7)
would it not be desirable to (instead) put some tolerance for round-off error into the 2geom routine, since the
difference between
these two points is clearly negligible ?
I second that. It's never a good idea to test two floating point numbers for equality. You should always have an epsilon to
account for
rounding errors.
I disagree. In the case of paths, the current curve's final point is exactly the same data as the next curve's initial point. 2geom has this built-in redundancy in path data because it simplifies things a lot. But it is important to maintain this data duplication. Therefore, these points should be exactly (binary) equivalent.
I noticed in point.h, == is overloaded like this:
inline bool operator==(Point const &a, Point const &b) { return (a[X] == b[X]) && (a[Y] == b[Y]); }
This should be "abs(a-b) < epsilon", however, maybe nathan has a faster way.
For this purpose we have "bool are_near(Typename a, Typename b)". So when one checks point1 == point2, one knows whether they are exactly the same.
We are working on a proper fix.
Johan