Mon 22 Aug 2016 10:41:50 PM UTC, original submission:
The exceptions defined by IEEE Std 1788-2015, which occur during failed calls of constructors, shall not prevent the return of a result. For example, infsup ("happy hacking") shall return an empty interval whilst signaling the UndefinedOperation “exception”.
1. In Octave, this can be implemented with the native warning mechanism. It is already implemented for the decorated interval constructor `infsupdec`, but not for the bare interval constructor `infsup`. Idea: Turn errors in `infsup` into warnings. If `infsupdec` calls `infsup` internally, it may put the warning IDs into error state locally, catch the error, propagate a warning and return a NaI (similar to current implementation).
2. If the `infsup` constructor doesn't fail anymore on invalid input, it can be made standards conforming on NaN input and (+inf, -inf) input where it must return [empty] in both cases whilst signaling the UndefinedOperation “exception”.
3. In infsupdec the warning ID interval:NaI may shadow the interval:UndefinedOperation warning ID, which should be preserved. interval:NaI should not be visible outside of the constructors.
4. The warning/error ID InvalidOperand should not be used for illegal interval literals in constructors. Use UndefinedOperation instead.
Similar issues:
5. The exactToInterval constructor does not differ from textToInterval in a 754-conforming inf-sup context. Thus, the exactToInterval operation may be discarded/deprecated in the package.
6. intervalpart (nai) shall return an empty interval whilst signaling the IntvlPartOfNaI “exception”. Therefore, the current Octave error can be turned into a warning.
|