- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Rectangle>>intersects: change Rationale

by Frank Shearar

On 14 February 2013 17:27, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > I don't want nothing, but you inherit from very specialized class > historically used to draw on pixel boundaries... > A rectangle that you cannot even rotate, common ;) You can't define a unique rectangle with only two points anyway, if you permit them to be rotated - consider the flipped version / reflected in the line between the two points. When you add the constraint that their sides must be horizontal/vertical you remove a degree of freedom, and then you get unique rectangles. frank > Nicolas > > 2013/2/14 Igor Stasenko <siguctua(a)gmail.com>: >> On 14 February 2013 18:10, Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> That means you probably need to change some graphics primitives. >>> >>> If you want to go this way (have mathematical geometric objects), then >>> I think you're on the step off Juan Morphic 3... >>> >> well, how you can reason about intersecting rectangles without using geometry? >> >> i do not want a rectangle which is not a rectangle in common sense, >> but rectangle in "our" sense, >> just because it fits us better. >> >> >>> Nicolas >> >> >> -- >> Best regards, >> Igor Stasenko. >> >

Feb. 14, 2013

Re: [Pharo-project] OneClick for 2.0 available again

by H. Hirzel

Yes, Marcus, it is Pharo 2.0 now starts fine in MSWindows when double-clicking on NBCog.exe. What now remains to be updated is the README.txt [1] Replace CogVM.exe --> NBCog.exe And probably remove 'Pharo 1.0' --Hannes [1] Current version or README.txt Pharo 1.0 - Mac: launch Pharo2.0-one-click.app - Linux: launch Pharo2.0-one-click.sh - Windows: launch CogVM.exe This distribution was built February 14, 2013. Please Note: ------------ Pharo does not yet natively run on a 64bits Linux. Just install the ia32/i386 runtime libraries and you should be fine. On Ubuntu and other debian-based systems, these libraries are named 'ia32-libs'. On 2/11/13, Marcus Denker <marcus.denker(a)inria.fr> wrote: > On Mon, Feb 11, 2013 at 12:32 PM, Torsten Bergmann <astares(a)gmx.de> wrote: >> Hannes wrote >>>Thorsten, >>> >>>reading what you have written, am I right that we just need a >>> NBCog.ini >>> >>>file for MSwindows? >> >> We already have an INI file in the Pharo 2.0 one-click. >> This INI file contains the correct entry about where to find the image >> file. >> >> But it is named "CogVM.ini" instead of "NBCog.ini" since according to the >> naming convention it has to be named like the VM (which is currently >> NBCog.exe). >> >> So as I wrote just rename CogVM.ini into NBCog.ini and it works. >> >> > I did this now and the next build should have the right ini > > Marcus > > -- > Marcus Denker -- denker(a)acm.org > http://www.marcusdenker.de > >

Feb. 14, 2013

Re: [Pharo-project] Rectangle>>intersects: change Rationale

by Igor Stasenko

On 14 February 2013 18:27, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > I don't want nothing, but you inherit from very specialized class > historically used to draw on pixel boundaries... > A rectangle that you cannot even rotate, common ;) > Well, from that perspective, then we should not touch anything and let it stink forever :) P.S. I think that we should revert the change to #intersects: -- Best regards, Igor Stasenko.

Feb. 14, 2013

Re: [Pharo-project] Rectangle>>intersects: change Rationale

by Nicolas Cellier

I don't want nothing, but you inherit from very specialized class historically used to draw on pixel boundaries... A rectangle that you cannot even rotate, common ;) Nicolas 2013/2/14 Igor Stasenko <siguctua(a)gmail.com>: > On 14 February 2013 18:10, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> That means you probably need to change some graphics primitives. >> >> If you want to go this way (have mathematical geometric objects), then >> I think you're on the step off Juan Morphic 3... >> > well, how you can reason about intersecting rectangles without using geometry? > > i do not want a rectangle which is not a rectangle in common sense, > but rectangle in "our" sense, > just because it fits us better. > > >> Nicolas > > > -- > Best regards, > Igor Stasenko. >

Feb. 14, 2013

Re: [Pharo-project] Rectangle>>intersects: change Rationale

by Frank Shearar

On 14 February 2013 17:22, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 14 February 2013 18:10, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> That means you probably need to change some graphics primitives. >> >> If you want to go this way (have mathematical geometric objects), then >> I think you're on the step off Juan Morphic 3... >> > well, how you can reason about intersecting rectangles without using geometry? I think Nicolas means intervals over discrete values - integers - versus intervals over continuous values - reals. frank > i do not want a rectangle which is not a rectangle in common sense, > but rectangle in "our" sense, > just because it fits us better. > > >> Nicolas > > > -- > Best regards, > Igor Stasenko. >

Feb. 14, 2013

Re: [Pharo-project] Rectangle>>intersects: change Rationale

by Igor Stasenko

On 14 February 2013 18:10, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > That means you probably need to change some graphics primitives. > > If you want to go this way (have mathematical geometric objects), then > I think you're on the step off Juan Morphic 3... > well, how you can reason about intersecting rectangles without using geometry? i do not want a rectangle which is not a rectangle in common sense, but rectangle in "our" sense, just because it fits us better. > Nicolas -- Best regards, Igor Stasenko.

Feb. 14, 2013

Re: [Pharo-project] Rectangle>>intersects: change Rationale

by Nicolas Cellier

That means you probably need to change some graphics primitives. If you want to go this way (have mathematical geometric objects), then I think you're on the step off Juan Morphic 3... Nicolas 2013/2/14 Igor Stasenko <siguctua(a)gmail.com>: > Yet another perspective.. is that if we state: > > Any two points form a rectangle.. > > Then, by construction it means that > > Rectangle origin: pt1 corner: pt2 > > should be equal to: > > Rectangle origin: pt2 corner: pt1 > > and here the evil part: if you use [) intervals > you not get what you want, because in one case > it will be rectangle which includes all points from pt1 to pt2 but not > including pt2 > while in another case, it will be rectangle which includes all points > from pt1 to pt2 but not including pt1.. > > and this is why i inclined to use [] intervals for defining the rectangles. > > -- > Best regards, > Igor Stasenko. >

Feb. 14, 2013

Re: [Pharo-project] Rectangle>>intersects: change Rationale

by Nicolas Cellier

Yes, I think it is a problem of reasonning as whole number of pixels Interval [ ) is for the case where (0@0 extent: 10@1) is exactly 10 pixels wide, and 1 pixel tall... The mail I cited above is using Rectangle as an abstraction of horizontal/vertical line segment (zero-width), in which case [a a) must still intersects... That must be conflicting with redrawing surfaces for which [a a) must not... Nicolas 2013/2/14 Igor Stasenko <siguctua(a)gmail.com>: > It is all about intervals.. > if you define a rectangle using pair of intervals (2-dimensional): > > [ a .. b ) > > then it contains all points between a and b, including a, but not including b > and therefore rectangles > [ a.. b ) and [b .. c ) (where c >b) do not intersect. > > if rectangle defined as pair of intervals: > > [ a .. b ] > > then it contains all points between a and b, including a AND b > and of course > [ a .. b ] and [b .. c ] (where c >b) will overlap. > > the problem is if you using [ ) intervals, then how you represent > degenerate (zero-width or zero-height) > rectangles.. > because interval [a .. a) holds a contradiction: it includes 'a', but > not includes 'a', which makes no sense. > > and then you have interesting questions, like do intervals > [a..a) and [a..b) overlap? > > While if using [a..a] there's no problem.. > [a..a] certainly overlaps with [a..b] > > But from other side, if we will use [...] intervals, then there is no > way to split interval to get two non-overlapping ones: > > [a..b] => [a..c] + [c..b] > (a<=c<=b) > > But i am not sure whether it will have significant impact or not. > > So, here my question: what interval type is better [) or [] ? > Existed implementation uses [) > > -- > Best regards, > Igor Stasenko. >

Feb. 14, 2013

Re: [Pharo-project] Rectangle>>intersects: change Rationale

by Igor Stasenko

Yet another perspective.. is that if we state: Any two points form a rectangle.. Then, by construction it means that Rectangle origin: pt1 corner: pt2 should be equal to: Rectangle origin: pt2 corner: pt1 and here the evil part: if you use [) intervals you not get what you want, because in one case it will be rectangle which includes all points from pt1 to pt2 but not including pt2 while in another case, it will be rectangle which includes all points from pt1 to pt2 but not including pt1.. and this is why i inclined to use [] intervals for defining the rectangles. -- Best regards, Igor Stasenko.

Feb. 14, 2013

Re: [Pharo-project] Rectangle>>intersects: change Rationale

by Igor Stasenko

It is all about intervals.. if you define a rectangle using pair of intervals (2-dimensional): [ a .. b ) then it contains all points between a and b, including a, but not including b and therefore rectangles [ a.. b ) and [b .. c ) (where c >b) do not intersect. if rectangle defined as pair of intervals: [ a .. b ] then it contains all points between a and b, including a AND b and of course [ a .. b ] and [b .. c ] (where c >b) will overlap. the problem is if you using [ ) intervals, then how you represent degenerate (zero-width or zero-height) rectangles.. because interval [a .. a) holds a contradiction: it includes 'a', but not includes 'a', which makes no sense. and then you have interesting questions, like do intervals [a..a) and [a..b) overlap? While if using [a..a] there's no problem.. [a..a] certainly overlaps with [a..b] But from other side, if we will use [...] intervals, then there is no way to split interval to get two non-overlapping ones: [a..b] => [a..c] + [c..b] (a<=c<=b) But i am not sure whether it will have significant impact or not. So, here my question: what interval type is better [) or [] ? Existed implementation uses [) -- Best regards, Igor Stasenko.

Feb. 14, 2013