To break down the ASN.1 encoding of 0.1 we have the following: sign * mantissa * (2 raisedTo: scalingFactor) * (base raisedTo: exponent).
And in this case the values for 0.1 are as follows: self assert: sign = 1. self assert: mantissa = 3602879701896397. self assert: scalingFactor = 0. self assert: base = 2. self assert: exponent = -55. Just to close it up... - HH > -------- Original Message -------- > Subject: Re: [Pharo-dev] float & fraction equality bug > Local Time: November 9, 2017 10:13 AM > UTC Time: November 9, 2017 3:13 PM > From: [email protected] > To: Pharo Development List <[email protected]> > > 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: [email protected] >> To: Pharo Development List <[email protected]> >> >> 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 >>> [email protected] 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 [email protected]: >>> 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."
