1788-2015 compliance

[lucaferranti]

I added the code to generate the ITL tests of reverse functions in ITF1788.jl. Here is an initial summary (I need to double check a few things

• General:

• The test suite has two "methods" for each function, one with the correct number of inputs as specified by the standard and one with one input less, which assumes that x= [-Inf, Inf] e.g. both abs_rev(a, x) and abs_rev(a) = abs_rev(a, entireinterval(). I need to check fro the standard whether these are required or optional, but in general it does not hurt to have those? From what I can tell, sqr_rev is the only one which has also the method with one less input

• according to the standard, those functions should return one output. The current implementation returns multiple outputs and the "standard result" is generally the second one. Is this intentional? Should the number of outputs conform to the standard?

• docstrings missing.

• libieeep1788_rev.itl

  • No support for decorated intervals.
  • power_rev fails in 16 tests with negative exponent, the returned result is a little wider than the expected one
  • 33 cases failing with mul_rev_IEEE1788

• pow_rev.itl

  • the functions powRev1 and powRev2 are required by the standard, they are currently implemented but not exported
  • all tests for powRev2 fail, due to a typo in the source code (lob should be log)
  • several tests for powRev1 and powRev2fail, e.g. powRev1 [-infinity,-1.0] [entire] [-infinity,0.0] = [empty];, the current Julia implementation evaluates to [0, 0].

• libieep1788_mul_rev.itl

  • mul_rev_to_pair missing

• Missing tests

  • the functions atan2Rev1 and atan2Rev1 are required by the standard, but even in ITF1788 there are no tests for these

[lbenet]

according to the standard, those functions should return one output. The current implementation returns multiple outputs and the "standard result" is generally the second one. Is this intentional? Should the number of outputs conform to the standard?

In IntervalContractors, there are some functions with IEEE1788 in their name (e.g., mul_rev_IEEE1788), which returns only one result. We should include such functions (also in the tests), which would fulfill the requirements of the standard, keeping the other functions as well. this obviously imposes documenting all functions thoroughly.

[lucaferranti]

feels a little pedantic though. wouldn't it be enough to keep the functions as they are and document that the output expected by the standard is the second one? The only reason for mul_rev_IEEE1788 and mul_rev is that they have the input arguments in different order 😅