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@tudorgirba.com To: Pharo Development List <pharo-dev@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@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@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-Ph... 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."