A.2 Conformance Claim

The inverval package version 3.2.1 for GNU Octave is conforming to IEEE Std 1788-2015, IEEE Standard for Interval Arithmetic. It is conforming to the set-based flavor with IEEE 754 conformance for the infsup binary64 interval type and without compressed arithmetic. Additionally it provides no further flavors.

A.3 Conformance Questionnaire

1. Implementation-defined behavior
   1. What status flags or other means to signal the occurrence of certain decoration values in computations does the implementation provide if any?

      The implementation does not signal the occurrence of decoration values.

2. Documentation of behavior
   1. If the implementation supports implicit interval types, how is the interval hull operation realized?

      The implementation supports explicit interval types only.

   2. What accuracy is achieved (i.e., tightest, accurate, or valid) for each of the implementation’s interval operations?

      The accuracy requirements of IEEE Std 1788-2015 are fulfilled. Most operations achieve tightest accuracy, some operations (especially reverse operations) do not. The tightness of each operation is documented in the function’s documentation string and can be displayed with the help command.

   3. Under what conditions is a constructor unable to determine whether a Level 1 value exists that corresponds to the supplied inputs?

      When two different string boundaries for an interval both lie between the same two subsequent binary64 numbers, a PossiblyUndefined warning is created.

   4. How are ties broken in rounding numbers if multiple numbers qualify as the rounded result?

      Tie-breaking uses the IEEE Std 754 default: round ties to even.

   5. How are interval datums converted to their exact text representations?

      The binary64 boundaries are converted into hexadecimal-significand form as required by the standard. It is also possible to convert interval datums to exact interval literals in decimal form, see optional arguments of function intervaltotext for that purpose.

3. Implementation-defined behavior
   1. Does the implementation include the interval overlapping function? If so, how is it made available to the user?

      Yes, the interval overlapping function is implemented under the name @infsup/overlap.

   2. Does the implementation store additional information in a NaI? What functions are provided for the user to set and read this information?

      No additional information is stored in a NaI.

   3. What means if any does the implementation provide for an exception to be signaled when a NaI is produced?

      The creation of a NaI is signaled with GNU Octave’s warning mechanism.

   4. What interval types are supported besides the required ones?

      None.

   5. What mechanisms of exception handling are used in exception handlers provided by the implementation? What additional exception handling is provided by the implementation?

      The exceptions described by IEEE Std 1788-2015 raise a warning, which can be handled with GNU Octave’s warning mechanism. The warning may be customized to produce an error instead and interrupt computation. The implementation provides no additional exception handling.

   6. [Question does not apply to IEEE 754 conforming types.]
   7. Does the implementation include different versions of the same operation for a given type and how are these provided to the user?

      The interval matrix multiplication (see @infsup/mtimes) offers two implementations, with either tightest or valid accuracy. The user may chose the desired version with an optional argument during the function call.

   8. What combinations of formats are supported in interval constructors?

      Any reasonable combination of the formats described in the standard document is supported.

   9. [Question does not apply to IEEE 754 conforming types.]
   10. What methods are used to read or write strings from or to character streams? Does the implementation employ variations in locales (such as specific character case matching)? This includes the syntax used in the strings for reading and writing.

       Input and output is implemented with GNU Octave string variables in UTF-8 encoding. There is no discrimination between different locales. Character case is ignored during input. The syntax for interval literals is used as described by the standard document.

   11. What is the tightness for the interval to string conversion for all interval types?

       The general-purpose interval to string conversion produces the tightest decimal infsup form which has no more digits than are necessary to separate two binary64 numbers.

   12. What is the result of Level 3 operations for invalid inputs?

       Interval constructors prevent the creation of invalid Level 3 interval datums.

       Any non-interval input to Level 3 operations is implicitly converted into an interval and the operation silently continues on interval inputs.

       If at least one input is a decorated interval, bare interval inputs are implicitly decorated as described by newDec in the standard document. Implicit promotion from a bare interval to a decorated interval is signaled with GNU Octave’s warning mechanism.

       If implicit conversion fails (e.g., illegal interval literals), bare interval operations produce empty intervals, whereas the decorated interval operations continue on NaI inputs.

   13. [Question does not apply to IEEE 754 conforming types.]
   14. What decorations does the implementation provide and what is their mathematical definition? How are these decorations mapped when converting an interval to the interchange format?

       The implementation provides the decorations com, dac, def, trv, and ill as described by the standard document.

   15. [Question does not apply to IEEE 754 conforming types.]
4. [Question applies to compressed arithmetic only, which is not supported.]
5. [Questions apply to non-standard flavors only, which are not supported.]