November 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] summary of "float & fraction equality bug"

by Nicolas Cellier

2017-11-10 22:42 GMT+01:00 Florin Mateoc <fmateoc(a)gmail.com>: > On 11/10/2017 4:18 PM, Nicolas Cellier wrote: > > > > 2017-11-10 20:58 GMT+01:00 Martin McClure <martin(a)hand2mouse.com>: > >> On 11/10/2017 11:33 AM, raffaello.giulietti(a)lifeware.ch wrote: >> >>> Doing only Fraction->Float conversions in mixed mode won't preserve = as >>> an equivalence relation and won't enable a consistent ordering with <=, >>> which probably most Smalltalkers consider important and enjoyable >>> properties. >>> >> Good point. I agree that Float -> Fraction is the more desirable mode for >> implicit conversion, since it can always be done without changing the value. >> >>> Nicolas gave some convincing examples on why most >>> programmers might want to rely on them. >>> >>> >>> Also, as I mentioned, most Smalltalkers might prefer keeping away from >>> the complex properties of Floats. Doing automatic, implicit >>> Fraction->Float conversions behind the scenes only exacerbates the >>> probability of encountering Floats and of having to deal with their >>> weird and unfamiliar arithmetic. >>> >> One problem is that we make it easy to create Floats in source code >> (0.1), and we print Floats in a nice decimal format but by default print >> Fractions in their reduced fractional form. If we didn't do this, >> Smalltalkers might not be working with Floats in the first place, and if >> they did not have any Floats in their computation they would never run into >> an implicit conversion to *or* from Float. >> >> As it is, if we were to uniformly do Float -> Fraction conversion on >> mixed-mode operations, we would get things like >> >> (0.1 * (1/1)) printString --> >> '3602879701896397/36028797018963968' >> >> Not incredibly friendly. >> > > For those not practicing the litote: definitely a no go. > > >> Regards, >> -Martin >> >> > At the risk of repeating myself, unique choice for all operations is a > nice to have but not a goal per se. > > I mostly agree with Florin: having 0.1 representing a decimal rather than > a Float might be a better path meeting more expectations. > > But thinking that it will magically eradicate the problems is a myth. > > Shall precision be limited or shall we use ScaledDecimals ? > > With limited precision, we'll be back to having several Fraction > converting to same LimitedDecimal, so it won't solve anything wrt original > problem. > > > I don't think people have problems with understanding limited precision. > We do know that when we write 3.14.. we did not write Pi. > As long as it does not contradict the intuition that we developed early on > (and that's the problem with the binary representation of floats, not that > it is limited)... > > With illimted precision we'll have the bad property that what we print > does not re-interpret to the same ScaledDecimal (0.1s / 0.3s), but that's a > detail. > The worse thing is that long chain of operations will tend to produce > monster numerators denominators. > And we will all have long chain when resizing a morph with proportional > layout in scalable graphics. > > > But I did not propose to drop floats, just to change the visible > representation of literals: 0.1 would mean a ScaledDecimal literal and 0.1f > would mean a float literal. The extra "f" would be a constant reminder that > something special is going on (the dangers of interpreting the literal as > an exact representation in base 10). > > We will then have to insert rounding operations manually for mitigating > the problem, and somehow reinvent a more inconvenient Float... > > > I don't think we would have to reinvent Float - this one would stay > exactly the same (other than printing the extra f (or d)). > But I agree that you raise an important point with precision/scale. We > would indeed need to make ScaledDecimal more complicated. > Because today 0.1s * 0.1s is printed as 0.0s1, even though 0.1s * 0.1s = > (1/100) evaluates to true, which is nice. > > It's boring to allways play the role of Cassandra, but why do you think > that Scheme and Lisp did not choose that path? > > Oh. come on, if Scheme and Lisp did it all already, why are we all here? :) > Not at all, here it what it means: We must analyze why some decisions were taken, and analyze what condition changed to enable different solutions. Maths did not change so much, so it must be something else... Fast CPU and huge memory could be a game changer, but how do the LargeInteger operations scale?

Nov. 10, 2017

Re: [Pharo-dev] summary of "float & fraction equality bug"

by Florin Mateoc

On 11/10/2017 4:42 PM, Florin Mateoc wrote: > On 11/10/2017 4:18 PM, Nicolas Cellier wrote: >> >> >> 2017-11-10 20:58 GMT+01:00 Martin McClure <martin(a)hand2mouse.com <mailto:martin@hand2mouse.com>>: >> >> On 11/10/2017 11:33 AM, raffaello.giulietti(a)lifeware.ch <mailto:raffaello.giulietti@lifeware.ch> wrote: >> >> Doing only Fraction->Float conversions in mixed mode won't preserve = as >> an equivalence relation and won't enable a consistent ordering with <=, >> which probably most Smalltalkers consider important and enjoyable >> properties. >> >> Good point. I agree that Float -> Fraction is the more desirable mode for implicit conversion, since it can >> always be done without changing the value. >> >> Nicolas gave some convincing examples on why most >> programmers might want to rely on them. >> >> >> Also, as I mentioned, most Smalltalkers might prefer keeping away from >> the complex properties of Floats. Doing automatic, implicit >> Fraction->Float conversions behind the scenes only exacerbates the >> probability of encountering Floats and of having to deal with their >> weird and unfamiliar arithmetic. >> >> One problem is that we make it easy to create Floats in source code (0.1), and we print Floats in a nice decimal >> format but by default print Fractions in their reduced fractional form. If we didn't do this, Smalltalkers might >> not be working with Floats in the first place, and if they did not have any Floats in their computation they >> would never run into an implicit conversion to *or* from Float. >> >> As it is, if we were to uniformly do Float -> Fraction conversion on mixed-mode operations, we would get things like >> >> (0.1 * (1/1)) printStringÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â --> >> '3602879701896397/36028797018963968' >> >> Not incredibly friendly. >> >> >> For those not practicing the litote: definitely a no go. >> >> >> Regards, >> -Martin >> >> >> At the risk of repeating myself, unique choice for all operations is a nice to have but not a goal per se. >> >> I mostly agree with Florin: having 0.1 representing a decimal rather than a Float might be a better path meeting more >> expectations. >> >> But thinking that it will magically eradicate the problems is a myth. >> >> Shall precision be limited or shall we use ScaledDecimals ? >> >> With limited precision, we'll be back to having several Fraction converting to same LimitedDecimal, so it won't solve >> anything wrt original problem. > > I don't think people have problems with understanding limited precision. We do know that when we write 3.14.. we did > not write Pi. > As long as it does not contradict the intuition that we developed early on (and that's the problem with the binary > representation of floats, not that it is limited)... > >> With illimted precision we'll have the bad property that what we print does not re-interpret to the same >> ScaledDecimal (0.1s / 0.3s), but that's a detail. >> The worse thing is that long chain of operations will tend to produce monster numerators denominators. >> And we will all have long chain when resizing a morph with proportional layout in scalable graphics. > > But I did not propose to drop floats, just to change the visible representation of literals: 0.1 would mean a > ScaledDecimal literal and 0.1f would mean a float literal. The extra "f" would be a constant reminder that something > special is going on (the dangers of interpreting the literal as an exact representation in base 10). > And there would still be a lot of places where we would continue to judiciously use floats, such as in morphic. Just like today people don't use fractions when they don't need their extra precision - ah, who am I kidding? There are a lot of developers out there who would go to great lengths to save an extra keystroke. :) Well, I think it could be made to work (e.g. one of the low-hanging fixes would be that multiplication of scaledDecimals would add their scales) and it would complement nicely Smalltalk's seamless and intuitive largeIntegers - just like largeIntegers liberate us from the tyranny of the hardware representation for integers, we should also not be prisoners to the hardware representation of floats. >> We will then have to insert rounding operations manually for mitigating the problem, and somehow reinvent a more >> inconvenient Float... > > I don't think we would have to reinvent Float - this one would stay exactly the same (other than printing the extra f > (or d)). > But I agree that you raise an important point with precision/scale. We would indeed need to make ScaledDecimal more > complicated. > Because today 0.1s * 0.1s is printed as 0.0s1, even though 0.1s * 0.1s = (1/100) evaluates to true, which is nice. > >> It's boring to allways play the role of Cassandra, but why do you think that Scheme and Lisp did not choose that path? >> > Oh. come on, if Scheme and Lisp did it all already, why are we all here? :) >

Nov. 10, 2017

Re: [Pharo-dev] summary of "float & fraction equality bug"

by Florin Mateoc

On 11/10/2017 4:18 PM, Nicolas Cellier wrote: > > > 2017-11-10 20:58 GMT+01:00 Martin McClure <martin(a)hand2mouse.com <mailto:martin@hand2mouse.com>>: > > On 11/10/2017 11:33 AM, raffaello.giulietti(a)lifeware.ch <mailto:raffaello.giulietti@lifeware.ch> wrote: > > Doing only Fraction->Float conversions in mixed mode won't preserve = as > an equivalence relation and won't enable a consistent ordering with <=, > which probably most Smalltalkers consider important and enjoyable > properties. > > Good point. I agree that Float -> Fraction is the more desirable mode for implicit conversion, since it can always > be done without changing the value. > > Nicolas gave some convincing examples on why most > programmers might want to rely on them. > > > Also, as I mentioned, most Smalltalkers might prefer keeping away from > the complex properties of Floats. Doing automatic, implicit > Fraction->Float conversions behind the scenes only exacerbates the > probability of encountering Floats and of having to deal with their > weird and unfamiliar arithmetic. > > One problem is that we make it easy to create Floats in source code (0.1), and we print Floats in a nice decimal > format but by default print Fractions in their reduced fractional form. If we didn't do this, Smalltalkers might > not be working with Floats in the first place, and if they did not have any Floats in their computation they would > never run into an implicit conversion to *or* from Float. > > As it is, if we were to uniformly do Float -> Fraction conversion on mixed-mode operations, we would get things like > > (0.1 * (1/1)) printStringÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â --> > '3602879701896397/36028797018963968' > > Not incredibly friendly. > > > For those not practicing the litote: definitely a no go. > > > Regards, > -Martin > > > At the risk of repeating myself, unique choice for all operations is a nice to have but not a goal per se. > > I mostly agree with Florin: having 0.1 representing a decimal rather than a Float might be a better path meeting more > expectations. > > But thinking that it will magically eradicate the problems is a myth. > > Shall precision be limited or shall we use ScaledDecimals ? > > With limited precision, we'll be back to having several Fraction converting to same LimitedDecimal, so it won't solve > anything wrt original problem. I don't think people have problems with understanding limited precision. We do know that when we write 3.14.. we did not write Pi. As long as it does not contradict the intuition that we developed early on (and that's the problem with the binary representation of floats, not that it is limited)... > With illimted precision we'll have the bad property that what we print does not re-interpret to the same ScaledDecimal > (0.1s / 0.3s), but that's a detail. > The worse thing is that long chain of operations will tend to produce monster numerators denominators. > And we will all have long chain when resizing a morph with proportional layout in scalable graphics. But I did not propose to drop floats, just to change the visible representation of literals: 0.1 would mean a ScaledDecimal literal and 0.1f would mean a float literal. The extra "f" would be a constant reminder that something special is going on (the dangers of interpreting the literal as an exact representation in base 10). > We will then have to insert rounding operations manually for mitigating the problem, and somehow reinvent a more > inconvenient Float... I don't think we would have to reinvent Float - this one would stay exactly the same (other than printing the extra f (or d)). But I agree that you raise an important point with precision/scale. We would indeed need to make ScaledDecimal more complicated. Because today 0.1s * 0.1s is printed as 0.0s1, even though 0.1s * 0.1s = (1/100) evaluates to true, which is nice. > It's boring to allways play the role of Cassandra, but why do you think that Scheme and Lisp did not choose that path? > Oh. come on, if Scheme and Lisp did it all already, why are we all here? :)

Nov. 10, 2017

Re: [Pharo-dev] feenk log

by Aliaksei Syrel

Hi Sean, Why not `anElement simulateClick`? Good question :) We indeed evaluated a possibility to have (BlElement >> #simulateClick) but then decided to make BlSpace class to be responsible for that. First we should realise that when we simulate a click we do literally simulate user's action which is: mouseDown at some global coordinate in space and then mouseUp. A process of handing mouse down/up events involves some complex event processing in order to detect what should happen, for example, with currently focused element or if we need to send double-click event. It is a mouse processor who is responsible for all these actions and it belongs to Space (inst. var in space). Not to mention some weird cases of overlapped elements, elements with custom elevation (zIndex), custom mouseDown/up event listeners that do some work too... That is why it is definitely not enough just to send a plain BlClickEvent directly to the element. Instead, we should involve a space in the process and actually simulate it by pushing mouseDown and mouseUp events to the event queue. Next what we realised it the fact that it is not nice to always create a temporary space and add our element to it in order to simulate a click. What if an element is already added to the space, what if not? To wrap up, we decided that it should be a responsibility of the Space *class* to create a new temporary instance of itself, add an element to it, simulate click event and then delete itself. In order to show the intent and a process behind we decided that it would be a good idea to actually write a code like this: BlSpace simulateClickOn: element. In english it is quite nice: "dear space class, could you, please, simulate a click event on a given element?" *It is a space who simulates event, not an element.* P.S. Users can still send a BlClickEvent directly (informs 'click'): element := BlElement new. element addEventHandlerOn: BlClickEvent do: [ self inform: 'click' ]. element fireEvent: BlClickEvent new Cheers, Alex On 10 November 2017 at 21:22, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Tudor Girba-2 wrote > > - support for programatic testing of bloc mouse events: > > https://twitter.com/feenkcom/status/925672206763511808 > > Why not `anElement simulateClick`? > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > >

Nov. 10, 2017

Re: [Pharo-dev] Alternative window manager

by Alistair Grant

Hi Thomas, On 10 November 2017 at 11:46, Thomas Dupriez <thomas.dupriez(a)ens-paris-saclay.fr> wrote: > Hello, > > Does an alternative window manager for pharo exist? > > For some reasons I always end up with a tangled mess of windows when using > the default one. My biggest gripe is that new windows tend to open on top of > other windows, blocking the view even if there is still empty space > elsewhere. > > I watched this video ( https://www.youtube.com/watch?v=Wx0eNaGzAZU ) about > the i3 window manager for linux and how it paves the screen with the windows > to optimise screen space and make things look less messy, and was wondering > whether something like that existed for pharo. > > Cheers, > Thomas Have you looked at Tiling Window Manager? It doesn't solve the problem of windows opening on top of each other, but makes it easy to position them: Metacello new baseline: 'TilingWindowManager'; repository: 'github://Pharophile/TilingWindowManager:master/packages'; load. If there's another window manager that is similar to i3 or Awesome I'd love to hear about it. :-) Cheers, Alistair

Nov. 10, 2017

Re: [Pharo-dev] summary of "float & fraction equality bug"

by Nicolas Cellier

2017-11-10 20:58 GMT+01:00 Martin McClure <martin(a)hand2mouse.com>: > On 11/10/2017 11:33 AM, raffaello.giulietti(a)lifeware.ch wrote: > >> Doing only Fraction->Float conversions in mixed mode won't preserve = as >> an equivalence relation and won't enable a consistent ordering with <=, >> which probably most Smalltalkers consider important and enjoyable >> properties. >> > Good point. I agree that Float -> Fraction is the more desirable mode for > implicit conversion, since it can always be done without changing the value. > >> Nicolas gave some convincing examples on why most >> programmers might want to rely on them. >> >> >> Also, as I mentioned, most Smalltalkers might prefer keeping away from >> the complex properties of Floats. Doing automatic, implicit >> Fraction->Float conversions behind the scenes only exacerbates the >> probability of encountering Floats and of having to deal with their >> weird and unfamiliar arithmetic. >> > One problem is that we make it easy to create Floats in source code (0.1), > and we print Floats in a nice decimal format but by default print Fractions > in their reduced fractional form. If we didn't do this, Smalltalkers might > not be working with Floats in the first place, and if they did not have any > Floats in their computation they would never run into an implicit > conversion to *or* from Float. > > As it is, if we were to uniformly do Float -> Fraction conversion on > mixed-mode operations, we would get things like > > (0.1 * (1/1)) printString --> > '3602879701896397/36028797018963968' > > Not incredibly friendly. > For those not practicing the litote: definitely a no go. > Regards, > -Martin > > At the risk of repeating myself, unique choice for all operations is a nice to have but not a goal per se. I mostly agree with Florin: having 0.1 representing a decimal rather than a Float might be a better path meeting more expectations. But thinking that it will magically eradicate the problems is a myth. Shall precision be limited or shall we use ScaledDecimals ? With limited precision, we'll be back to having several Fraction converting to same LimitedDecimal, so it won't solve anything wrt original problem. With illimted precision we'll have the bad property that what we print does not re-interpret to the same ScaledDecimal (0.1s / 0.3s), but that's a detail. The worse thing is that long chain of operations will tend to produce monster numerators denominators. And we will all have long chain when resizing a morph with proportional layout in scalable graphics. We will then have to insert rounding operations manually for mitigating the problem, and somehow reinvent a more inconvenient Float... It's boring to allways play the role of Cassandra, but why do you think that Scheme and Lisp did not choose that path?

Nov. 10, 2017

[Pharo 7.0-dev] Build #284: 20671-Extend-system-dependencies-tests-on-whole-image

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #284 was: SUCCESS. The Pull Request #464 was integrated: "20671-Extend-system-dependencies-tests-on-whole-image" Pull request url: https://github.com/pharo-project/pharo/pull/464 Issue Url: https://pharo.fogbugz.com/f/cases/20671 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 10, 2017

Re: [Pharo-dev] feenk log

by Sean P. DeNigris

Tudor Girba-2 wrote > - support for programatic testing of bloc mouse events: > https://twitter.com/feenkcom/status/925672206763511808 Why not `anElement simulateClick`? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Nov. 10, 2017

Re: [Pharo-dev] summary of "float & fraction equality bug"

by Martin McClure

On 11/10/2017 11:33 AM, raffaello.giulietti(a)lifeware.ch wrote: > Doing only Fraction->Float conversions in mixed mode won't preserve = as > an equivalence relation and won't enable a consistent ordering with <=, > which probably most Smalltalkers consider important and enjoyable > properties. Good point. I agree that Float -> Fraction is the more desirable mode for implicit conversion, since it can always be done without changing the value. > Nicolas gave some convincing examples on why most > programmers might want to rely on them. > > > Also, as I mentioned, most Smalltalkers might prefer keeping away from > the complex properties of Floats. Doing automatic, implicit > Fraction->Float conversions behind the scenes only exacerbates the > probability of encountering Floats and of having to deal with their > weird and unfamiliar arithmetic. One problem is that we make it easy to create Floats in source code (0.1), and we print Floats in a nice decimal format but by default print Fractions in their reduced fractional form. If we didn't do this, Smalltalkers might not be working with Floats in the first place, and if they did not have any Floats in their computation they would never run into an implicit conversion to *or* from Float. As it is, if we were to uniformly do Float -> Fraction conversion on mixed-mode operations, we would get things like (0.1 * (1/1)) printStringÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â --> '3602879701896397/36028797018963968' Not incredibly friendly. Regards, -Martin

Nov. 10, 2017

[Pharo 7.0-dev] Build #283: 20670-unused-var-in-generateDefaultFileOutResultsName

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #283 was: SUCCESS. The Pull Request #465 was integrated: "20670-unused-var-in-generateDefaultFileOutResultsName" Pull request url: https://github.com/pharo-project/pharo/pull/465 Issue Url: https://pharo.fogbugz.com/f/cases/20670 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 10, 2017