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

Re: [Pharo-dev] [Pharo 7.0-dev] Build #273: 20661-Fixing-test-from-debugger-should-mark-test-as-green-when-proceed-

by Stephane Ducasse

Thanks for this!!!!!! Stef On Thu, Nov 9, 2017 at 2:57 PM, <ci-pharo-ci-jenkins2(a)inria.fr> wrote: > There is a new Pharo build available! > > The status of the build #273 was: SUCCESS. > > The Pull Request #456 was integrated: "20661-Fixing-test-from-debugger-should-mark-test-as-green-when-proceed-" > Pull request url: https://github.com/pharo-project/pharo/pull/456 > > Issue Url: https://pharo.fogbugz.com/f/cases/20661 > 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

2017-11-09 20:10 GMT+01:00 Raffaello Giulietti < raffaello.giulietti(a)lifeware.ch>: > On 2017-11-09 19:04, Nicolas Cellier wrote: > >> >> >> 2017-11-09 18:02 GMT+01:00 Raffaello Giulietti < >> raffaello.giulietti(a)lifeware.ch <mailto:raffaello.giulietti@lifeware.ch >> >>: >> >> >> >> >> 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... >> >> >> >> a = b evaluates to false in this example, so no wonder (a - b) >> evaluates to a big number. >> >> >> Writing a = b with floating point is rarely a good idea, so asking about >> the context which could justify such approach makes sense IMO. >> >> > Simple contexts, like the one which is the subject of this trail, are the > one we should strive at because they are the ones most likely used in > day-to-day working. Having useful properties and regularity for simple > cases might perhaps cover 99% of the everyday usages (just a dishonestly > biased estimate ;-) ) > > Complex contexts, with heavy arithmetic, are best dealt by numericists > when Floats are involved, or with unlimited precision numbers like > Fractions by other programmers. > > > This differs from my experience. Float strikes in the most simple place were we put false expectation because of a different mental representation > > > > But the example is not plain old arithmetic. >> >> Here, 0.1, 0.2, 0.3 are just a shorthands to say "the Floats closest >> to 0.1, 0.2, 0.3" (if implemented correctly, like in Pharo as it >> seems). Every user of Floats should be fully aware of the implicit >> loss of precision that using Floats entails. >> >> >> Yes, it makes perfect sense! >> But precisely because you are aware that 0.1e0 is "the Float closest to >> 0.1" and not exactly 1/10, you should then not be surprised that they are >> not equal. >> >> > Indeed, I'm not surprised. But then > 0.1 - (1/10) > shall not evaluate to 0. If it evaluates to 0, then the numbers shall > compare as being equal. > > The surprise lies in the inconsistency between the comparison and the > subtraction, not in the isolated operations. > > > > >> I agree that following assertion hold: >> self assert: a ~= b & a isFloat & b isFloat & a isFinite & b >> isFinite ==> (a - b) isZero not >> >> > The arrow ==> is bidirectional even for finite Floats: > > self assert: (a - b) isZero not & a isFloat & b isFloat & a isFinite & b > isFinite ==> a ~= b > > > > But (1/10) is not a Float and there is no Float that can represent it >> exactly, so you can simply not apply the rules of FloatingPoint on it. >> >> When you write (1/10) - 0.1, you implicitely perform (1/10) asFloat - 0.1. >> It is the rounding operation asFloat that made the operation inexact, so >> it's no more surprising than other floating point common sense >> > > See above my observation about what I consider surprising. > > As already said, it's a false expectation in the context of mixed arithmetic. > > > >> >> In the case of mixed-mode Float/Fraction operations, I personally >> prefer reducing the Fraction to a Float because other commercial >> Smalltalk implementations do so, so there would be less pain porting >> code to Pharo, perhaps attracting more Smalltalkers to Pharo. >> >> Mixed arithmetic is problematic, and from my experience mostly happens in >> graphics in Smalltalk. >> >> If ever I would change something according to this principle (but I'm not >> convinced it's necessary, it might lead to other strange side effects), >> maybe it would be how mixed arithmetic is performed... >> Something like exact difference like Martin suggested, then converting to >> nearest Float because result is inexact: >> ((1/10) - 0.1 asFraction) asFloat >> >> This way, you would have a less surprising result in most cases. >> But i could craft a fraction such that the difference underflows, and the >> assertion a ~= b ==> (a - b) isZero not would still not hold. >> Is it really worth it? >> Will it be adopted in other dialects? >> >> >> > As an alternative, the Float>>asFraction method could return the Fraction > with the smallest denominator that would convert to the receiver by the > Fraction>>asFloat method. > > So, 0.1 asFraction would return 1/10 rather than the beefy Fraction it > currently returns. To return the beast, one would have to intentionally > invoke asExactFraction or something similar. > > This might cause less surprising behavior. But I have to think more. > > > No the goal here was to have a non null difference because we need to preserve inequality for other features. Answering anything but a Float at a high computation price goes against primary purpose of Float (speed, efficiency) If that's what we want, then we shall not use Float in the first place. That's why I don't believe in such proposal The minimal Fraction algorithm is an intersting challenge though. Not sure how to find it... Coming back to a bit of code, we have only minimal decimal (with only powers of 2 & 5 at denominator): {[Float pi asFraction]. [Float pi asMinimalDecimalFraction]} collect: #bench. > > > But the main point here, I repeat myself, is to be consistent and to >> have as much regularity as intrinsically possible. >> >> >> >> I think we have as much as possible already. >> Non equality resolve more surprising behavior than it creates. >> It makes the implementation more mathematically consistent (understand >> preserving more properties). >> Tell me how you are going to sort these 3 numbers: >> >> {1.0 . 1<<60+1/(1<<60). 1<<61+1/(1<<61)} sort. >> >> tell me the expectation of: >> >> {1.0 . 1<<60+1/(1<<60). 1<<61+1/(1<<61)} asSet size. >> >> > A clearly stated rule, consistently applied and known to everybody, helps. > > In presence of heterogeneous numbers, the rule should state the common > denominator, so to say. Hence, the numbers involved in mixed-mode > arithmetic are either all converted to one representation or all to the > other: whether they are compared or added, subtracted or divided, etc. One > rule for mixed-mode conversions, not two. > > > Having an economy of rules is allways a good idea. If you can obtain a consistent system with 1 single rule rather than 2 then go. But if it's at the price of sacrificing higher expectations, that's another matter. Languages that have a simpler arithmetic model, bounded integer, no Fraction, may stick to a single rule. More sofisticated models like you'll find in Lisp and Scheme have exact same logic as Squeak/Pharo. We don't have 2 rules gratuitously as already explained. - Total relation order of non nan values so as to be a good Magnitude citizen imply non equality - Producing Float in case of mixed arithmetic is for practicle purpose: speed (What are those damn Float for otherwise?) it's also justified a posteriori by (exact op: inexact) -> inexact What are you ready to sacrifice/trade? > > tell me why = is not a relation of equivalence anymore (not associative) >> >> >> > Ensuring that equality is an equivalence is always a problem when the > entities involved are of different nature, like here. This is not a new > problem and not inherent in numbers. (Logicians and set theorists would > have much to tell.) Even comparing Points and ColoredPoints is problematic, > so I have no final answer. > > In Smalltalk, furthermore, implementing equality makes it necessary to > (publicly) expose much more internal details about an object than in other > environments. > > > Let's focus on Number. Loosing equivalence is loosing ability to mix Numbers in Set. But not only Numbers... Anything having a Number somewhere in an inst var, like (1/10)@0 and 0.1@0.

Nov. 9, 2017

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

by Stephane Ducasse

On Thu, Nov 9, 2017 at 5:34 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Note that this started a long time ago and comes up episodically > http://forum.world.st/Fraction-equality-and-Float-infinity-problem-td48323.… > http://forum.world.st/BUG-Equality-should-be-transitive-tc1404335.html > https://lists.gforge.inria.fr/pipermail/pharo-project/2009-July/010496.html > > A bit like a "marronnier" (in French, a subject that is treated periodically > by newspapers and magazines) Hi nicolas except that now we could a chapter describing some of the answers :)

Nov. 9, 2017

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

by Stephane Ducasse

There is nice little Chapter about Float based on previous discussions with Nicolas :) In deep into pharo. Stef On Thu, Nov 9, 2017 at 3:50 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > 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@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

Metacello we need automated conflict resolution between Baselines and Configurations

by Peter UhnÃ¡k

Hi, as people are increasingly starting to move to git and baselines, it is becoming more and more common that there are loading issues: A depends on B and C B depends on ConfigurationOfX C depends on BaselineOfX and then loading fails on MetacelloConflictingProjectError: Load Conflict between existing BaselineOfStateSpecs [baseline] from github://dionisiydk/StateSpecs:v2.4.x and ConfigurationOfStateSpecs stable from http://www.smalltalkhub.com/mc/dionisiy/StateSpecs/main I imagine that this will become more and more common. Can this be resolved in some automated fashion? Thanks, Peter

Nov. 9, 2017

Re: [Pharo-dev] CRC checks of downloads fail really often

by Stephane Ducasse

Thanks Marcus. For 200 Euros I can even offering to the community. I'm sad that our inria infrastructure is not at the right level. Stef On Thu, Nov 9, 2017 at 7:18 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > As a first step of a new instrastructure I have added a mirror: > > https://mirror.pharo.org > > update is not yet working for files that keep the same name yet change > content. > This will be added I hope tomorrow. > > Marcus > > On 9 Nov 2017, at 18:33, Norbert Hartl <norbert(a)hartl.name> wrote: > > Yes, this drives me crazy. You cannot do much or invite people to use it > because the download does not work. Sometimes it is really ridiculous. > > Norbert > > Am 09.11.2017 um 10:28 schrieb Guillermo Polito <guillermopolito(a)gmail.com > >: > > Hi, > > In the travis jobs of many projects (pillar, ossubprocess), I see often > this failure: > > image.eqoxhz/Pharo7.0-32bit-b648168.image bad CRC 298b4e64 (should be > 85ee6276) > > This is happening all the time for large builds, generally in 1 out of 4 > jobs: > > https://travis-ci.org/marianopeck/OSSubprocess/builds/299269491 > https://travis-ci.org/pillar-markup/pillar/jobs/298538119 > > Of course restarting the job (to retry the download) solves the problem > eventually. > > Is this because of the inria infrastructure working funny? > > > -- > > Guille Polito > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > CRIStAL - UMR 9189 > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr/>* > > *Web:* *http://guillep.github.io* <http://guillep.github.io/> > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> > > > >

Nov. 9, 2017

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

by Raffaello Giulietti

On 2017-11-09 19:04, Nicolas Cellier wrote: > > > 2017-11-09 18:02 GMT+01:00 Raffaello Giulietti > <raffaello.giulietti(a)lifeware.ch <mailto:raffaello.giulietti@lifeware.ch>>: > > > > > 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... > > > > a = b evaluates to false in this example, so no wonder (a - b) > evaluates to a big number. > > > Writing a = b with floating point is rarely a good idea, so asking about > the context which could justify such approach makes sense IMO. > Simple contexts, like the one which is the subject of this trail, are the one we should strive at because they are the ones most likely used in day-to-day working. Having useful properties and regularity for simple cases might perhaps cover 99% of the everyday usages (just a dishonestly biased estimate ;-) ) Complex contexts, with heavy arithmetic, are best dealt by numericists when Floats are involved, or with unlimited precision numbers like Fractions by other programmers. > But the example is not plain old arithmetic. > > Here, 0.1, 0.2, 0.3 are just a shorthands to say "the Floats closest > to 0.1, 0.2, 0.3" (if implemented correctly, like in Pharo as it > seems). Every user of Floats should be fully aware of the implicit > loss of precision that using Floats entails. > > > Yes, it makes perfect sense! > But precisely because you are aware that 0.1e0 is "the Float closest to > 0.1" and not exactly 1/10, you should then not be surprised that they > are not equal. > Indeed, I'm not surprised. But then 0.1 - (1/10) shall not evaluate to 0. If it evaluates to 0, then the numbers shall compare as being equal. The surprise lies in the inconsistency between the comparison and the subtraction, not in the isolated operations. > > I agree that following assertion hold: > Â Â Â self assert: a ~= b & a isFloat & b isFloat & a isFinite & b > isFinite ==> (a - b) isZero not > The arrow ==> is bidirectional even for finite Floats: self assert: (a - b) isZero not & a isFloat & b isFloat & a isFinite & b isFinite ==> a ~= b > But (1/10) is not a Float and there is no Float that can represent it > exactly, so you can simply not apply the rules of FloatingPoint on it. > > When you write (1/10) - 0.1, you implicitely perform (1/10) asFloat - 0.1. > It is the rounding operation asFloat that made the operation inexact, so > it's no more surprising than other floating point common sense See above my observation about what I consider surprising. > > > In the case of mixed-mode Float/Fraction operations, I personally > prefer reducing the Fraction to a Float because other commercial > Smalltalk implementations do so, so there would be less pain porting > code to Pharo, perhaps attracting more Smalltalkers to Pharo. > > Mixed arithmetic is problematic, and from my experience mostly happens > in graphics in Smalltalk. > > If ever I would change something according to this principle (but I'm > not convinced it's necessary, it might lead to other strange side effects), > maybe it would be how mixed arithmetic is performed... > Something like exact difference like Martin suggested, then converting > to nearest Float because result is inexact: > Â Â Â ((1/10) - 0.1 asFraction) asFloat > > This way, you would have a less surprising result in most cases. > But i could craft a fraction such that the difference underflows, and > the assertion a ~= b ==> (a - b) isZero not would still not hold. > Is it really worth it? > Will it be adopted in other dialects? > > As an alternative, the Float>>asFraction method could return the Fraction with the smallest denominator that would convert to the receiver by the Fraction>>asFloat method. So, 0.1 asFraction would return 1/10 rather than the beefy Fraction it currently returns. To return the beast, one would have to intentionally invoke asExactFraction or something similar. This might cause less surprising behavior. But I have to think more. > But the main point here, I repeat myself, is to be consistent and to > have as much regularity as intrinsically possible. > > > > I think we have as much as possible already. > Non equality resolve more surprising behavior than it creates. > It makes the implementation more mathematically consistent (understand > preserving more properties). > Tell me how you are going to sort these 3 numbers: > > {1.0 . 1<<60+1/(1<<60).Â 1<<61+1/(1<<61)} sort. > > tell me the expectation of: > > {1.0 . 1<<60+1/(1<<60). 1<<61+1/(1<<61)} asSet size. > A clearly stated rule, consistently applied and known to everybody, helps. In presence of heterogeneous numbers, the rule should state the common denominator, so to say. Hence, the numbers involved in mixed-mode arithmetic are either all converted to one representation or all to the other: whether they are compared or added, subtracted or divided, etc. One rule for mixed-mode conversions, not two. > tell me why = is not a relation of equivalence anymore (not associative) > > Ensuring that equality is an equivalence is always a problem when the entities involved are of different nature, like here. This is not a new problem and not inherent in numbers. (Logicians and set theorists would have much to tell.) Even comparing Points and ColoredPoints is problematic, so I have no final answer. In Smalltalk, furthermore, implementing equality makes it necessary to (publicly) expose much more internal details about an object than in other environments.

Nov. 9, 2017

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

by Andres Valloud

Because by definition, a floating point value is of the form +/- 2^e * m for some 0 <= m < M, and e in some range of values (some positive, some negative). There are other special cases that don't matter here, such as NaN, INF, denormals, etc. So now set up the equality you want. Since it's positive we can skip the sign. Hence, 2^e * m = 1/10 Or, rather, 10 * 2^e * m = 1 The Fundamental Theorem of Arithmetic shows this is impossible. Andres. On 11/9/17 6:48 , Tudor Girba wrote: > 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] CRC checks of downloads fail really often

by Marcus Denker

As a first step of a new instrastructure I have added a mirror: https://mirror.pharo.org <https://mirror.pharo.org/> update is not yet working for files that keep the same name yet change content. This will be added I hope tomorrow. Marcus > On 9 Nov 2017, at 18:33, Norbert Hartl <norbert(a)hartl.name> wrote: > > Yes, this drives me crazy. You cannot do much or invite people to use it because the download does not work. Sometimes it is really ridiculous. > > Norbert > >> Am 09.11.2017 um 10:28 schrieb Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>>: >> >> Hi, >> >> In the travis jobs of many projects (pillar, ossubprocess), I see often this failure: >> >> image.eqoxhz/Pharo7.0-32bit-b648168.image bad CRC 298b4e64 (should be 85ee6276) >> >> This is happening all the time for large builds, generally in 1 out of 4 jobs: >> >> https://travis-ci.org/marianopeck/OSSubprocess/builds/299269491 <https://travis-ci.org/marianopeck/OSSubprocess/builds/299269491> >> https://travis-ci.org/pillar-markup/pillar/jobs/298538119 <https://travis-ci.org/pillar-markup/pillar/jobs/298538119> >> >> Of course restarting the job (to retry the download) solves the problem eventually. >> >> Is this because of the inria infrastructure working funny? >> >> >> -- >> >> Guille Polito >> Research Engineer >> >> Centre de Recherche en Informatique, Signal et Automatique de Lille >> CRIStAL - UMR 9189 >> French National Center for Scientific Research - http://www.cnrs.fr <http://www.cnrs.fr/> >> >> Web: http://guillep.github.io <http://guillep.github.io/> >> Phone: +33 06 52 70 66 13 >

Nov. 9, 2017

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

by Nicolas Cellier

2017-11-09 18:02 GMT+01:00 Raffaello Giulietti < raffaello.giulietti(a)lifeware.ch>: > On 2017-11-09 15:50, Nicolas Cellier wrote: > >> This is out of context. >> There is no such thing as Fraction type covered by IEEE 754 standard. >> >> > Yes, I agree. But we should still strive to model arithmetic embracing the > principle of least surprise. That's why in every arithmetic system I'm > aware of (with the exception of very old CPUs dating back several decades), > for finite x, y the > x = y if and only if x - y = 0 > property holds. > > Let's put it in another perspective: what's the usefulness of having > x = y > evaluate to false just to discover that > x - y > evaluates to 0, or the other way round? > > > > > > > > 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... >> >> >> > a = b evaluates to false in this example, so no wonder (a - b) evaluates > to a big number. > > Writing a = b with floating point is rarely a good idea, so asking about the context which could justify such approach makes sense IMO. But the example is not plain old arithmetic. > > Here, 0.1, 0.2, 0.3 are just a shorthands to say "the Floats closest to > 0.1, 0.2, 0.3" (if implemented correctly, like in Pharo as it seems). Every > user of Floats should be fully aware of the implicit loss of precision that > using Floats entails. > > Yes, it makes perfect sense! But precisely because you are aware that 0.1e0 is "the Float closest to 0.1" and not exactly 1/10, you should then not be surprised that they are not equal. > So, using Floats to represent decimal numbers is the real culprit in this > example, not the underlying Float arithmetic, which is very well defined > from a mathematical point of view. In other words, using Floats to emulate > decimal arithmetic will frustrate anybody because Floats work with limited > precision binary arithmetic. Users wanting to engage in decimal arithmetic > should simply not use Floats. (That's the reason for the addition of > limited precision decimal arithmetic and numbers in the IEEE 754-2008 > standard.) > > That said, this does not mean we should give up useful properties like the > one discussed above. Since we *can* ensure this property, we also should, > in the spirit of the principle of least surprise. > > What's problematic in Pharo is that comparison works in one way while > subtraction works in another way but, mathematically, these operations are > essentially the same. So let's be consistent. > > I agree that following assertion hold: self assert: a ~= b & a isFloat & b isFloat & a isFinite & b isFinite ==> (a - b) isZero not But (1/10) is not a Float and there is no Float that can represent it exactly, so you can simply not apply the rules of FloatingPoint on it. When you write (1/10) - 0.1, you implicitely perform (1/10) asFloat - 0.1. It is the rounding operation asFloat that made the operation inexact, so it's no more surprising than other floating point common sense In the case of mixed-mode Float/Fraction operations, I personally prefer > reducing the Fraction to a Float because other commercial Smalltalk > implementations do so, so there would be less pain porting code to Pharo, > perhaps attracting more Smalltalkers to Pharo. > > Mixed arithmetic is problematic, and from my experience mostly happens in graphics in Smalltalk. If ever I would change something according to this principle (but I'm not convinced it's necessary, it might lead to other strange side effects), maybe it would be how mixed arithmetic is performed... Something like exact difference like Martin suggested, then converting to nearest Float because result is inexact: ((1/10) - 0.1 asFraction) asFloat This way, you would have a less surprising result in most cases. But i could craft a fraction such that the difference underflows, and the assertion a ~= b ==> (a - b) isZero not would still not hold. Is it really worth it? Will it be adopted in other dialects? > But the main point here, I repeat myself, is to be consistent and to have > as much regularity as intrinsically possible. > > > I think we have as much as possible already. Non equality resolve more surprising behavior than it creates. It makes the implementation more mathematically consistent (understand preserving more properties). Tell me how you are going to sort these 3 numbers: {1.0 . 1<<60+1/(1<<60). 1<<61+1/(1<<61)} sort. tell me the expectation of: {1.0 . 1<<60+1/(1<<60). 1<<61+1/(1<<61)} asSet size. tell me why = is not a relation of equivalence anymore (not associative)

Nov. 9, 2017