ITF1788 compliance

[lucaferranti]

I have recently created the package ITF1788.jl which translates ITL to julia tests, runs the tests and marks the failing ones as broken. This should make it easier to see what is missing. Here is a summary (except for reverse functions, I will open an issue for those in IntervalContractors.jl soonish).

• fi_lib.itl

  • [x] 1. some problems with acot (Luis pointed out that this function is recommended and is also missing from MPFR, indeed the name of the file suggests these were tests for FiLib library, not for the standard).
  • [x] 2. some problems with acoth (same of above)

• ieee1788-exceptions.itl

  • [x] 3. b-textToInterval "[+infinity]" = [empty] signal UndefinedOperation; fixed in #522

  • [ ] 4. Interval part of NaI should return the empty interval, now it returns [NaN, NaN]

  • [x] 5. b-textToInterval "[1.0000000000000001, 1.0000000000000002]" = [1.0, 0x1.0000000000001p+0] signal PossiblyUndefinedOperation; fixed in #522

  • ieee1788-class.itl

  • [x] 6. invalid inputs should return an empty interval for bare intervals #457 and #461 e.g.

    b-numsToInterval NaN NaN = [empty] signal UndefinedOperation;
    b-numsToInterval 1.0 -1.0 = [empty] signal UndefinedOperation;
    b-numsToInterval -infinity -infinity = [empty] signal UndefinedOperation;
    b-numsToInterval infinity infinity = [empty] signal UndefinedOperation;

  • [x] 7. invalid strings should return an empty interval fixed in #522

  • [x] 8. some problems in parsing intervals from strings, probably due to current implementation being case sensitive fixed in #522

  • [x] 9. in some cases same problem due to #464

  • [ ] 10. a few tests failing when constructing decorated intervals.

• ieee1788-elem

  • [x] 11. ~roundTiesToAway and roundTiesToEven missing~, they are implemented, I just didn't notice those before.

• ieee1788-num

  • [x] 12. one failing test, but I strongly suspect here the issue is in the ITL source code, because the test is midRad [nai] [nai] = NaN NaN;, I don't understand why midRad would take two intervals as input, indeed it does not for other tests in the same test block. edit: I think this is so obviously a typo in the ITL source code, that I dare marking this as done. I also opened an issue in the original repository

• ieee1788-overlap

  • [x] 13. all tests failing since the function is not implemented. However, if I recall correctly, this function is optional and not required, do we want it? Solved in #518

• ieee1788-reduction :

  • The standard (Section 12.12.12) defines reduction operations sum, dot, sumSquare, sumAbs
  • [ ] 14. The functions sumSquare and sumAbs can be easily implemented in julia, e.g. sumSquare(x) = sum(x.^2) . However the point of those functions is to have accurate summation, ITF has only trivial tests for those
  • [ ] 15. One test failing for dot product: dot_nearest {0x10000000000001p0, 0x1p104} {0x0fffffffffffffp0, -1.0} = -1.0;. Using floating point arithmetic, the result is 0, using bigfloats the result is -1, could be solved using the Oishi-Rump-Ogita accurate dot product from AccurateArithmetic.jl.

• reverse functions

  • [ ] 16. Issue opened in the IntervalContractors.jl package, since reverse functions are implemented there. Anyway, the standard requires those to be implemented in an interval arithmetic software, I guess this would be ok if we advertise ValidatedNumerics as compliant software?

[lbenet]

@lucaferranti Some comments your list:

• Regarding 1 and 2: they are solved by #517. Should we backport them to master?

• Regarding 10: I think we should emit a warning, as it is currently done in master.

• Regarding 13: they are implemented in 1.0-dev branch. I followed your suggestion, and now it returns enum elements that are of type OverlapType; see #518