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

[Pharo 7.0-dev] Build #275: 20499-Examples-in-GlamourPresentationModel-should-have-no-gtExamplePragma

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

There is a new Pharo build available! The status of the build #275 was: SUCCESS. The Pull Request #455 was integrated: "20499-Examples-in-GlamourPresentationModel-should-have-no-gtExamplePragma" Pull request url: https://github.com/pharo-project/pharo/pull/455 Issue Url: https://pharo.fogbugz.com/f/cases/20499 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 9, 2017

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

by henry

ASN.1 encoding is a long standing encoding format and includes accepted encoding of Reals and Integers. I read this thread and decided to see what difference that ASN.1 Real encoding may report between this float and the fraction. It turns out it is the same, but not in an equality test with the fraction. That is due to conversion from Fraction to Float before encoding. Here is the results I found: ASN1OutputStream encode: (1/10). ASN1OutputStream encode: (0.1). bytes := #[9 9 128 201 12 204 204 204 204 204 205] This breaks down as in: ASN1InputStream decodeBytes: bytes. obj := (3602879701896397/36028797018963968) Which equals 0.1, but does not equal (1/10). Food for thought regarding ASN.1 encoding of Reals. - HH > -------- Original Message -------- > Subject: Re: [Pharo-dev] float & fraction equality bug > Local Time: November 9, 2017 9:48 AM > UTC Time: November 9, 2017 2:48 PM > From: tudor(a)tudorgirba.com > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > > Hi, > > Thanks for the answer. The example I provided was for convenience. > > I still do not understand why it is wrong to expect 0.1 = (1/10) to be true. > > Doru > >> On Nov 9, 2017, at 3:36 PM, Nicolas Cellier nicolas.cellier.aka.nice(a)gmail.com wrote: >> Nope, not a bug. >> If you use Float, then you have to know that (x -y) isZero and (x = y) are two different things. >> Example; Float infinity >> In your case you want to protect against (x-y) isZero, so just do that. >> 2017-11-09 15:15 GMT+01:00 Tudor Girba tudor(a)tudorgirba.com: >> Hi, >> I just stumbled across this bug related to the equality between fraction and float: >> https://pharo.fogbugz.com/f/cases/20488/x-y-iff-x-y-0-is-not-preserved-in-P… >> In essence, the problem can be seen that by doing this, you get a ZeroDivide: >> x := 0.1. >> y := (1/10). >> x = y ifFalse: [ 1 / (x - y) ] >> The issue seems to come from the Float being turned to a Fraction, rather than the Fraction being turned into a Float: >> Fraction(Number)>>adaptToFloat: rcvr andCompare: selector >> "If I am involved in comparison with a Float, convert rcvr to a >> Fraction. This way, no bit is lost and comparison is exact." >> rcvr isFinite >> ifFalse: [ >> selector == #= ifTrue: [^false]. >> selector == #~= ifTrue: [^true]. >> rcvr isNaN ifTrue: [^ false]. >> (selector = #< or: [selector = #'<=']) >> ifTrue: [^ rcvr positive not]. >> (selector = #> or: [selector = #'>=']) >> ifTrue: [^ rcvr positive]. >> ^self error: 'unknow comparison selector']. >> ^ rcvr asTrueFraction perform: selector with: self >> Even if the comment says that the comparison is exact, to me this is a bug because it seems to fail doing that. What do you think? >> Cheers, >> Doru >> -- >> www.tudorgirba.com >> www.feenk.com >> "Problem solving should be focused on describing >> the problem in a way that makes the solution obvious." > > www.tudorgirba.com > www.feenk.com > > "We are all great at making mistakes."

Nov. 9, 2017

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

by Nicolas Cellier

2017-11-09 15:48 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > Thanks for the answer. The example I provided was for convenience. > > I still do not understand why it is wrong to expect 0.1 = (1/10) to be > true. > > Doru > > Because there are infinitely many different Fraction that would be "equal" to 0.1 then. The first effect is that you have a = b a = c b < c You are breaking the fact that you can sort these Numbers (are they Magnitude anymore?) You are breaking the fact that you can mix these Numbers as Dictionary keys (sometimes the dictionary would have 2 elements, sometimes 3, unpredictably). > > On Nov 9, 2017, at 3:36 PM, Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com> wrote: > > > > Nope, not a bug. > > > > If you use Float, then you have to know that (x -y) isZero and (x = y) > are two different things. > > Example; Float infinity > > > > In your case you want to protect against (x-y) isZero, so just do that. > > > > 2017-11-09 15:15 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > > Hi, > > > > I just stumbled across this bug related to the equality between fraction > and float: > > https://pharo.fogbugz.com/f/cases/20488/x-y-iff-x-y-0-is- > not-preserved-in-Pharo > > > > In essence, the problem can be seen that by doing this, you get a > ZeroDivide: > > x := 0.1. > > y := (1/10). > > x = y ifFalse: [ 1 / (x - y) ] > > > > The issue seems to come from the Float being turned to a Fraction, > rather than the Fraction being turned into a Float: > > > > Fraction(Number)>>adaptToFloat: rcvr andCompare: selector > > "If I am involved in comparison with a Float, convert rcvr to a > > Fraction. This way, no bit is lost and comparison is exact." > > > > rcvr isFinite > > ifFalse: [ > > selector == #= ifTrue: [^false]. > > selector == #~= ifTrue: [^true]. > > rcvr isNaN ifTrue: [^ false]. > > (selector = #< or: [selector = #'<=']) > > ifTrue: [^ rcvr positive not]. > > (selector = #> or: [selector = #'>=']) > > ifTrue: [^ rcvr positive]. > > ^self error: 'unknow comparison selector']. > > > > ^ rcvr asTrueFraction perform: selector with: self > > > > Even if the comment says that the comparison is exact, to me this is a > bug because it seems to fail doing that. What do you think? > > > > Cheers, > > Doru > > > > > > -- > > www.tudorgirba.com > > www.feenk.com > > > > "Problem solving should be focused on describing > > the problem in a way that makes the solution obvious." > > > > > > > > > > > > > > -- > www.tudorgirba.com > www.feenk.com > > "We are all great at making mistakes." > > > > > > > > > >

Nov. 9, 2017

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

by Nicolas Cellier

2017-11-09 15:44 GMT+01:00 Raffaello Giulietti < raffaello.giulietti(a)lifeware.ch>: > According to IEEE 754, the base of Pharo Float, *finite* values shall > behave like old plain arithmetic. > > > This is out of context. There is no such thing as Fraction type covered by IEEE 754 standard. Anyway relying upon Float equality should allways be subject to extreme caution and examination For example, what do you expect with plain old arithmetic in mind: a := 0.1. b := 0.3 - 0.2. a = b This will lead to (a - b) reciprocal = 3.602879701896397e16 If it is in a Graphics context, I'm not sure that it's the expected scale... > > On 2017-11-09 15:36, Nicolas Cellier wrote: > >> Nope, not a bug. >> >> If you use Float, then you have to know that (x -y) isZero and (x = y) >> are two different things. >> Example; Float infinity >> >> In your case you want to protect against (x-y) isZero, so just do that. >> >> 2017-11-09 15:15 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com <mailto: >> tudor(a)tudorgirba.com>>: >> >> >> Hi, >> >> I just stumbled across this bug related to the equality between >> fraction and float: >> https://pharo.fogbugz.com/f/cases/20488/x-y-iff-x-y-0-is-not >> -preserved-in-Pharo >> <https://pharo.fogbugz.com/f/cases/20488/x-y-iff-x-y-0-is-no >> t-preserved-in-Pharo> >> >> In essence, the problem can be seen that by doing this, you get a >> ZeroDivide: >> x := 0.1. >> y := (1/10). >> x = y ifFalse: [ 1 / (x - y) ] >> >> The issue seems to come from the Float being turned to a Fraction, >> rather than the Fraction being turned into a Float: >> >> Fraction(Number)>>adaptToFloat: rcvr andCompare: selector >> "If I am involved in comparison with a Float, convert rcvr to a >> Fraction. This way, no bit is lost and comparison is exact." >> >> rcvr isFinite >> ifFalse: [ >> selector == #= ifTrue: [^false]. >> selector == #~= ifTrue: [^true]. >> rcvr isNaN ifTrue: [^ false]. >> (selector = #< or: [selector = #'<=']) >> ifTrue: [^ rcvr positive not]. >> (selector = #> or: [selector = #'>=']) >> ifTrue: [^ rcvr positive]. >> ^self error: 'unknow comparison selector']. >> >> ^ *rcvr asTrueFraction perform: selector with: self* >> >> Even if the comment says that the comparison is exact, to me this is >> a bug because it seems to fail doing that. What do you think? >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com <http://www.tudorgirba.com> >> www.feenk.com <http://www.feenk.com> >> >> "Problem solving should be focused on describing >> the problem in a way that makes the solution obvious." >> >> >> >> >> >> >> > >

Nov. 9, 2017

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

by Tudor Girba

Hi, Thanks for the answer. The example I provided was for convenience. I still do not understand why it is wrong to expect 0.1 = (1/10) to be true. Doru > On Nov 9, 2017, at 3:36 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > Nope, not a bug. > > If you use Float, then you have to know that (x -y) isZero and (x = y) are two different things. > Example; Float infinity > > In your case you want to protect against (x-y) isZero, so just do that. > > 2017-11-09 15:15 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > I just stumbled across this bug related to the equality between fraction and float: > https://pharo.fogbugz.com/f/cases/20488/x-y-iff-x-y-0-is-not-preserved-in-P… > > In essence, the problem can be seen that by doing this, you get a ZeroDivide: > x := 0.1. > y := (1/10). > x = y ifFalse: [ 1 / (x - y) ] > > The issue seems to come from the Float being turned to a Fraction, rather than the Fraction being turned into a Float: > > Fraction(Number)>>adaptToFloat: rcvr andCompare: selector > "If I am involved in comparison with a Float, convert rcvr to a > Fraction. This way, no bit is lost and comparison is exact." > > rcvr isFinite > ifFalse: [ > selector == #= ifTrue: [^false]. > selector == #~= ifTrue: [^true]. > rcvr isNaN ifTrue: [^ false]. > (selector = #< or: [selector = #'<=']) > ifTrue: [^ rcvr positive not]. > (selector = #> or: [selector = #'>=']) > ifTrue: [^ rcvr positive]. > ^self error: 'unknow comparison selector']. > > ^ rcvr asTrueFraction perform: selector with: self > > Even if the comment says that the comparison is exact, to me this is a bug because it seems to fail doing that. What do you think? > > Cheers, > Doru > > > -- > www.tudorgirba.com > www.feenk.com > > "Problem solving should be focused on describing > the problem in a way that makes the solution obvious." > > > > > > -- www.tudorgirba.com www.feenk.com "We are all great at making mistakes."

Nov. 9, 2017

Re: [Pharo-dev] Zinc and Zodiac - Synching/Contributing

by Dale Henrichs

On 10/28/17 3:27 AM, Sven Van Caekenberghe wrote: > >> On 28 Oct 2017, at 11:39, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> >> >>> Am 28.10.2017 um 11:21 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >>> >>> Torsten, >>> >>>> On 26 Oct 2017, at 19:12, Torsten Bergmann <astares(a)gmx.de> wrote: >>>> >>>> Hi Sven, >>>> >>>> for Zinc there is a new issue: >>>> >>>> >>>> 1. Zinc is using #asBytesDescription. It should not be used as it is deprecated >>>> >>>> https://github.com/pharo-project/pharo/pull/401 >>> This change was applied upstream: >>> >>> === >>> Name: Zinc-HTTP-SvenVanCaekenberghe.470 >>> Author: SvenVanCaekenberghe >>> Time: 28 October 2017, 11:10:06.068769 am >>> UUID: 1d831c82-f918-0d00-9306-5dc70a8677c5 >>> Ancestors: Zinc-HTTP-SvenVanCaekenberghe.469 >>> >>> Follow an API change in Pharo: use #humanReadableSIByteSize instead of #asByteDescription in ZnUtils>>#signalProgress:total: >>> === >>> >>>> there is also >>>> >>>> 2. https://pharo.fogbugz.com/f/cases/20557 which is not yet integrated. >>> This is waiting for an integrator, I believe people are working on it. >>> >>>> I also proposed some simple but necessary cleanups for Zodiac in Pharo 7: >>>> >>>> 3. Proper categorization in Zodiac-Tests package >>>> - to use "test" category instead of "testing" and better group the tests written >>>> >>>> https://github.com/pharo-project/pharo/pull/355/files >>>> >>>> Also it looks like the #setUp in Zodiac tests never send a "super setUp". Which >>>> should be fixed too. >>> Hmm, these are more cosmetic changes, I will have a look at them later on. >>> >>>> I've noticed that both Zinc/Zodiac are not hosted on STHub. You seem to use your own custom >>>> hosting server on >>>> >>>> http://mc.stfx.eu/Zodiac >>>> http://mc.stfx.eu/ZincHTTPComponents >>> I would not call that a custom hosting solution, it is just Monticello. Note that there are also a copies on StHub. >>> >>>> as well as github: >>>> >>>> https://github.com/svenvc/zinc >>>> https://github.com/svenvc/zodiac >>>> >>>> If we just merge the changes from 3. into Pharo 7 they may later be overwritten when >>>> synching also Zodiac again as in 2. >>> Yes, that is true. I have to follow upstream. The GitHub versions also lag a bit sometimes. >>> >>>> So how can we contribute from community side to both projects? Should I fork >>>> https://github.com/svenvc/zodiac and send a PR to it so that you can integrate? >>> Zinc/Zodiac are integral parts of Pharo that are managed externally. The goal is to simultaneously support many Pharo versions, not just the latest. Most production deploys of Pharo use version 4, 5 or 6, but they still need good HTTP(S) support. That is what I am trying to do. >>> >>> The older MC repositories are public, so others can contribute in the proven MC way. I have nothing against git, but I have not yet fully switched, nor do I think that I can if I want to support older Pharo versions. >>> >> You can move to git and commit from time to time in smalltalkhub. Or even automatically. > I am not yet ready for that. > > Hell, I haven't even contributed to Pharo 7 yet. It seems like things are still in flux all the time. Now it seems the whole filetree will go away. FileTree is not going away ... you can't install Tonel without FileTree:) FileTree and Tonel are different disk formats and other than making the choice about which disk format you prefer ... FileTree gives you fine-grained version history at the method level at the cost of consuming more disk space (because of minimum disk block sizes) ... Tonel gives you less granularity for version history (class instead of method) with the benefit of greatly reducing disk costs and providing a more readable format for the source outside of the standard Smalltalk environment ... Personally i will continue to use metadatfull FileTree for all cross platform/version projects (Tonel will probably not be back-ported to older versions of Pharo) and Tonel for the newer projects that are aimed at platforms where Tonel support is present ... I am going to toy with the idea of using both formats to distribute Metacello ... Tonel to be disk-space friendly and FileTree for older platforms ... I would keep both formats in sync ... eventually I suppose I will stop porting new features to the older platforms, but the project will continue to be avialable in a form that older platforms can continue to use it ... Dale

Nov. 9, 2017

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

by Raffaello Giulietti

According to IEEE 754, the base of Pharo Float, *finite* values shall behave like old plain arithmetic. On 2017-11-09 15:36, Nicolas Cellier wrote: > Nope, not a bug. > > If you use Float, then you have to know that (x -y) isZero and (x = y) > are two different things. > Example; Float infinity > > In your case you want to protect against (x-y) isZero, so just do that. > > 2017-11-09 15:15 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com > <mailto:tudor@tudorgirba.com>>: > > Hi, > > I just stumbled across this bug related to the equality between > fraction and float: > https://pharo.fogbugz.com/f/cases/20488/x-y-iff-x-y-0-is-not-preserved-in-P… > <https://pharo.fogbugz.com/f/cases/20488/x-y-iff-x-y-0-is-not-preserved-in-P…> > > In essence, the problem can be seen that by doing this, you get a > ZeroDivide: > xÂ :=Â 0.1. > y :=Â (1/10). > x =Â y ifFalse:Â [Â 1Â /Â (xÂ -Â y)Â ] > > The issue seems to come from the Float being turned to a Fraction, > rather than the Fraction being turned into a Float: > > Fraction(Number)>>adaptToFloat: rcvr andCompare: selector > "If I am involved in comparison with a Float, convert rcvr to a > Fraction. This way, no bit is lost and comparison is exact." > > rcvr isFinite > ifFalse: [ > selector == #= ifTrue: [^false]. > selector == #~= ifTrue: [^true]. > rcvr isNaN ifTrue: [^ false]. > (selector = #< or: [selector = #'<=']) > ifTrue: [^ rcvr positive not]. > (selector = #> or: [selector = #'>=']) > ifTrue: [^ rcvr positive]. > ^self error: 'unknow comparison selector']. > > ^ *rcvr asTrueFraction perform: selector with: self* > > Even if the comment says that the comparison is exact, to me this is > a bug because it seems to fail doing that. What do you think? > > Cheers, > Doru > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > www.feenk.com <http://www.feenk.com> > > "Problem solving should be focused on describing > the problem in a way that makes the solution obvious." > > > > > >

Nov. 9, 2017

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

by Nicolas Cellier

2017-11-09 15:34 GMT+01:00 Martin McClure <martin(a)hand2mouse.com>: > On 11/09/2017 06:15 AM, Tudor Girba wrote: > > Hi, > > I just stumbled across this bug related to the equality between fraction > and float: > https://pharo.fogbugz.com/f/cases/20488/x-y-iff-x-y-0-is- > not-preserved-in-Pharo > > In essence, the problem can be seen that by doing this, you get a > ZeroDivide: > x := 0.1. > y := (1/10). > x = y ifFalse: [ 1 / (x - y) ] > > The issue seems to come from the Float being turned to a Fraction, rather > than the Fraction being turned into a Float: > > Fraction(Number)>>adaptToFloat: rcvr andCompare: selector > "If I am involved in comparison with a Float, convert rcvr to a > Fraction. This way, no bit is lost and comparison is exact." > > rcvr isFinite > ifFalse: [ > selector == #= ifTrue: [^false]. > selector == #~= ifTrue: [^true]. > rcvr isNaN ifTrue: [^ false]. > (selector = #< or: [selector = #'<=']) > ifTrue: [^ rcvr positive not]. > (selector = #> or: [selector = #'>=']) > ifTrue: [^ rcvr positive]. > ^self error: 'unknow comparison selector']. > > ^ *rcvr asTrueFraction perform: selector with: self* > > Even if the comment says that the comparison is exact, to me this is a bug > because it seems to fail doing that. What do you think? > > > I think exact comparison is the best thing to do here (even though ANSI > says otherwise). And an exact comparison will answer false, because there > is no float that is exactly equal to 1/10 -- it is an infinitely repeating > decimal in binary. > > For consistency, though, it might be better to compute x - y by converting > the Float to a Fraction rather than the other way around (though this would > also contravene ANSI) since Fraction is the more general format (every > Float can be represented exactly as a Fraction, but the reverse is not > true). > > The POV is that Float are potentially inexact (some quantity rounded to nearest representable Float). While Fraction are exact. If you mix exact quantity with inexact, then the result is inexact (thus Float). It does not hurt that this choice is CPU friendly. Regards, > -Martin >

Nov. 9, 2017

[Pharo 7.0-dev] Build #274: 20662-displaying-method-versions-in-Nautilus-causes-DNU

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

There is a new Pharo build available! The status of the build #274 was: SUCCESS. The Pull Request #457 was integrated: "20662-displaying-method-versions-in-Nautilus-causes-DNU" Pull request url: https://github.com/pharo-project/pharo/pull/457 Issue Url: https://pharo.fogbugz.com/f/cases/20662 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 9, 2017

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

by Nicolas Cellier

Nope, not a bug. If you use Float, then you have to know that (x -y) isZero and (x = y) are two different things. Example; Float infinity In your case you want to protect against (x-y) isZero, so just do that. 2017-11-09 15:15 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > I just stumbled across this bug related to the equality between fraction > and float: > https://pharo.fogbugz.com/f/cases/20488/x-y-iff-x-y-0-is- > not-preserved-in-Pharo > > In essence, the problem can be seen that by doing this, you get a > ZeroDivide: > x := 0.1. > y := (1/10). > x = y ifFalse: [ 1 / (x - y) ] > > The issue seems to come from the Float being turned to a Fraction, rather > than the Fraction being turned into a Float: > > Fraction(Number)>>adaptToFloat: rcvr andCompare: selector > "If I am involved in comparison with a Float, convert rcvr to a > Fraction. This way, no bit is lost and comparison is exact." > > rcvr isFinite > ifFalse: [ > selector == #= ifTrue: [^false]. > selector == #~= ifTrue: [^true]. > rcvr isNaN ifTrue: [^ false]. > (selector = #< or: [selector = #'<=']) > ifTrue: [^ rcvr positive not]. > (selector = #> or: [selector = #'>=']) > ifTrue: [^ rcvr positive]. > ^self error: 'unknow comparison selector']. > > ^ *rcvr asTrueFraction perform: selector with: self* > > Even if the comment says that the comparison is exact, to me this is a bug > because it seems to fail doing that. What do you think? > > Cheers, > Doru > > > -- > www.tudorgirba.com > www.feenk.com > > "Problem solving should be focused on describing > the problem in a way that makes the solution obvious." > > > > > >

Nov. 9, 2017