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.: [email protected] corner: [email protected] you get a truncated answer that is completely outside the original rectangle! On Thu, Apr 22, 2010 at 2:55 PM, Alexandre Bergel <[email protected]> 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: 1...@10) containsPoint: 5...@5. => true > (1...@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 "(1...@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 "(1...@10 > corner: 0...@0) containsPoint: 5...@5" returns true or not permitting a > rectangle > "(1...@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 > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
