Parsing of interval strings

[lbenet]

While trying to adapt the ITF1788 test suite to the tests using Base.Test in #205, I noticed that the test suite has been enlarged, and in particular it includes a new file, which yields some problems. These are related to the constructor parsing of interval strings used in @interval("[...]"), where the dots represent different forms. This issue is to notice some of those forms, currently not implemented (tables

While @interval("[1,2]") yields the expected result, @interval("[1]") does not, nor @interval("[-0x1.3p-1, 2/3]") or @interval("[Empty]"). Similarly, @decorated("[1,1e3]_com") yields the expected result, while @decorated("[1,1e3]_dac") fails to recognize the decoration. The following should make sense: @interval("3.56?1") (in our case, probably replacing ? by ±).

These are some of the examples, but not all. The relevant notes in the standard are: Sections 9.7.1 and 9.8, Table 9.4, Section 10.5.1, Section 11.3, Table 12.1 and Section 12.11.3.

Note that since #215, string parsing is found in src/parsing.jl.

Cc: @oheim

[dpsanders]

It's possibleprobable that we would prefer to use either the I"[1]" or @interval [1] syntax.

[oheim]

Does this library implement exceptions from the IEEE standard? If yes, you can now use ITF1788 to check for signaled exceptions as well:

testcase exceptions {
    b-textToInterval "[+infinity]" = [empty] signal UndefinedOperation;
    b-numsToInterval +infinity -infinity = [empty] signal UndefinedOperation;
    intervalPart [nai] = [empty] signal IntvlPartOfNaI;
    b-textToInterval "[1.0000000000000001, 1.0000000000000002]" = [1.0, 0x1.0000000000001p+0] signal PossiblyUndefinedOperation;
}

[dpsanders]

Exceptions are not yet implemented, but should not be too difficult; recorded in #213. Thanks, @oheim

[lbenet]

Some of this functionality was merged in #215.

[dpsanders]

Reopening as a reminder that there is still work to be done.

[dpsanders]

More parsing in #215.