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
<[email protected]> wrote:
>
>
> 2017-11-09 15:44 GMT+01:00 Raffaello Giulietti
> <[email protected]>:
>>
>> 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 <[email protected]
>>> <mailto:[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
>>>
>>> <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 <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."
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>

Reply via email to