implementing real (floating point) number comparison tolerance as a compiler directive.

so, for example, if i do this:
     @setFloatingPointTolerance: 0.02 // effective in next 3 lines in this source only.
     if a == b // comparing two Double vars
     {
            SomeLibFunc(a) // has no effect on whatever is in SomeFunc()
    }
    @setFloatingPointToleranceOff

  coud you explain? I don’t understand, it would be just a compiler flag, working on where it is only.
Thanks
Ted

btw. the CC to swift-dev-request bounces back to me complaining about MIME parts?

···

On 04.03.2016, at 19:32, Stephen Canon <scanon@apple.com> wrote:

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@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@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@swift.org> a écrit :

On Mar 4, 2016, at 5:11 AM, Ted F.A. van Gaalen <tedvgiosdev@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution