Open lbenet opened 7 years ago
It's ~possible~probable that we would prefer to use either the I"[1]"
or @interval [1]
syntax.
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;
}
Exceptions are not yet implemented, but should not be too difficult; recorded in #213. Thanks, @oheim
Some of this functionality was merged in #215.
Reopening as a reminder that there is still work to be done.
More parsing in #215.
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 (tablesWhile
@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