[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