This is the mail archive of the mailing list for the Mauve project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]


On Wed, 2004-09-01 at 21:30, Sven de Marothy wrote:
> Nice! Thanks, that's great work. 
> Some of these are real bugs, and I'll try and fix them.

Glad to be of assistance!

> Now, some others I'm not so sure of. Firstly, I'm not certain
> contains() should really return true on any edges. (For instance,
> having recently done Ellipse2D, I know for an Ellipse2D(0,0,10,10)
> contains() will return false on the edge points (5,0),(5,10),
> (0,5),(10,5))

There is a definition of which points lie "inside" a shape in the
description of the Shape interface:

It more or less says that points on the left/top edges are "in" and
points on the right/bottom edges are "out".  Now *somewhere* I read a
justification for this (maybe something to do with unions of
non-intersecting shapes?) but I don't recall where. 

> So I'm thinking the first test case should really return false too.
> (Sun's contains() methods aren't very consistent in these cases.. And
> for some classes, like Arc2D they're often simply wrong.)

I haven't spotted any inconsistencies based on the above definitions,
but I'll review them again.  If you have some cases where Sun's
implementation is wrong, it would be great to get some checks included
for them.

> Second, since the other tests rely on contains() working like Sun's on
> edges, it makes it difficult to know what causes the error. Wouldn't it
> make sense to use intersects() instead, where the behavior is more
> reliable and well-defined?

Yes, I can probably change the tests without losing any coverage.

> Some of the behavior here is also intentional. The method used for
> contains() is the line-crossing algorithm, checking the number of 
> intersections along the positive x-axis, with the test-point at the
> origin. The caveat here is if a vertex is exactly on the axis, the
> count will be off, and all points with a smaller x than the vertex and a
> smaller y will get false results. I've seen this happen with
> the Sun JDK (but not for Area though). 
> I guess I'll have to re-think that workaround in this case.

There certainly seems to be enough traps and pitfalls in this geometry
stuff.  I'm looking through your source code and as my understanding
increases, hopefully I'll be able to add some further checks for special



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]