[swift-evolution] implementing real (floating point) number comparison tolerance as a compiler directive.

Stephen Canon scanon at apple.com
Fri Mar 4 12:32:25 CST 2016


In particular, if you could effect how equality is defined for callee functions, you would break a lot of library code that expects equality to really be exact equality.  There are a wide variety of reasons for doing this in mathematical library code (zero as a sentinel value, working around singularities that really only effect a single value, etc).  Any approach to approximate equality that escapes scope would be a source of extremely hard-to-diagnose bugs.

– Steve

> On Mar 4, 2016, at 10:28 AM, Ted F.A. van Gaalen via swift-evolution <swift-evolution at swift.org> wrote:
> 
>   ? but it should only work on the source it compiles, not on what’s called.
> TedvG
>> On 04.03.2016, at 19:22, Félix Cloutier <felixcca at yahoo.ca <mailto:felixcca at yahoo.ca>> wrote:
>> 
>> Another problem that I perceive with the scoped approach (and global state) is that it can't reach inside C (or Objective-C) functions.
>> 
>> Félix
>> 
>>> Le 4 mars 2016 à 12:53:28, Joe Groff via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> a écrit :
>>> 
>>> 
>>>> On Mar 4, 2016, at 5:11 AM, Ted F.A. van Gaalen <tedvgiosdev at gmail.com <mailto:tedvgiosdev at gmail.com>> wrote:
>>>> 
>>>> Hi Joe,
>>>> 
>>>> to just fuzzy compare 2 floating point numbers,
>>>> the solution you describe uses
>>>> - 2 functions, with therein 6 calls to frexp, abs, max and scalb...
>>>> isn’t that overkill ? 
>>> 
>>> That's how APL-style tolerance is defined—the tolerance is scaled to the greater exponent of the operands. frexp, scalb, and fabs all reduce to bitwise operations on the float representation, so this should be possible to compile down to something cheap (if LLVM can't do it natively, then by hand, at least).
>>> 
>>>> I still think a compiler directive embedded in sources at desired locations as e.g.
>>>> 
>>>> @setFLoatingPointTolerance: 0.0001 
>>>>    . 
>>>>   if a == b 
>>>>   ...
>>>> @setFloatingPointToleranceOff
>>>>>>>> @setFLoatingPointTolerance: 0.04 
>>>>    . 
>>>>   if temperature == roomTemperature 
>>>>   ...
>>>> @setFloatingPointToleranceOff
>>>> 
>>>> So every floating point compare in source between these directives will be 
>>>> will be compiled differently.
>>>> Leave it to the compiler, so no special functions/ parameters are needed,
>>>> and would be far more efficient I think.
>>> 
>>> We don't do this anywhere else, and I'm not sure this narrow use case justifies such an invasive change to how functions work. There might be an interesting general purpose feature in supporting implicit context arguments (beyond the usual 'self' for methods).
>>> 
>>> -Joe
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160304/97353d9b/attachment.html>


More information about the swift-evolution mailing list