[swift-evolution] implementing real (floating point) number comparison tolerance as a compiler directive.
ted van gaalen
tedvgiosdev at gmail.com
Tue Mar 1 16:45:53 CST 2016
? I don't see transivity requirement broken here, because -within a comparison tolerance- they still are true.
ted van gaalen it services
Professional App development for
Apple IOS, Windows & Android
tablets and mobile phones
based on > 30 yrs of IT experience.
Web design & programming.
IBM Mainframe application programming.
www.tedvg.com
Ted F.A. van Gaalen
Hauptstr. 19/3
D-88636 Illmensee
Germany
T: 49 7558 92 17 840
M: 49 174 7707 422
> On 01 Mar 2016, at 20:39, Pyry Jahkola <pyry.jahkola at iki.fi> wrote:
>
>> On 01 Mar 2016, at 20:28, ted van gaalen via swift-evolution <swift-evolution at swift.org> wrote:
>>
>> in relation to my message about handling floating point number comparisation tolerance in e.g. a .stride function, wouldn't this be better handled by a compiler directive?
>>
>> For example:
>>
>> @floatingPointComparisonTolerance = 0.001
>
> I don't think it's a good idea. That directive would break the transitivity requirement of Equatable (the last line below):
>
> /// **Equality is an equivalence relation**
> ///
> /// - `x == x` is `true`
> /// - `x == y` implies `y == x`
> /// - `x == y` and `y == z` implies `x == z`
>
> You might want to define another operator or function for approximately equal instead.
>
>
> (Not like equality wasn't already broken for floats because of NaN, but at least we can try to keep the remaining semantics sane.)
>
> — Pyry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160301/e1f279d8/attachment.html>
More information about the swift-evolution
mailing list