I noticed this too when developing a system whose coordinates are not laid out the same as a computer screen. My solution was to change my coordinate translation of the domain to conform to a computer-screen. :-( Another limitation of Rectangles that isn't obvious is that they are coded to assume their coordinates are all integral. I had been confounded by a bug that ended up being that, when I asked for the #center of a Rectangle with Float coordinates, i.e.: 50.1234@50.9876 corner: 41.1234@41.9876 you get a truncated answer that is completely outside the original rectangle! On Thu, Apr 22, 2010 at 2:55 PM, Alexandre Bergel <alexandre@bergel.eu> wrote:
Dear List,
I spend quite some time in tracking down a bug in Mondrian. I found it. The source of it stems from the following behavior in Pharo: -=-=-=-=-=-= (0@0 corner: 10@10) containsPoint: 5@5. Â => true (10@10 corner: 0@0) containsPoint: 5@5. Â => false -=-=-=-=-=-=
I find the latter a bit surprising. VW returns false as well. I would expect the second expression to return true. There is also "(10@0 corner: 0@10) containsPoint: 5@5. => false"
I looked in the Pharo mailing list archive, and apparently this hasn't been discussed yet.
The class Rectangle is central. Modifying it (either by making "(10@10 corner: 0@0) containsPoint: 5@5" returns true or not permitting a rectangle "(10@10 corner: 0@0)" to be valid) may have some serious impact.
What do you think?
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel  http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project