[Pharo-dev] float & fraction equality bug

henry henry at callistohouse.club
Thu Nov 9 10:13:15 EST 2017


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 at tudorgirba.com
> To: Pharo Development List <pharo-dev at 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 at 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 at 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."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20171109/2a742ea5/attachment-0002.html>


More information about the Pharo-dev mailing list