Re: Version 2.11, Proposal for interval standardization
Sylvain,
- I find it strange to mention "standard intervals" and "non standard
intervals".
The reason is that I want nonstandard intervals to be supported in a
minimal way that enables someone interested to create a
standard-complying implementation of Kahan or Kaucher arithmetic.
I would just focus on intervals (your current standard intervals), and
not mention non standard intervals. Otherwise it looks like we put
some constraints
on something we don't do completely and that we want to be out of scope
of the document.
IMO, better leave them away, otherwise all functions would have to mention
"the behavior for nonstandard intervals is not specified", like 1.5.8).
This clause stands here to be valid for everything said later.
- 1.5.6 : anyInterval(l,u) : what happens if e.g. l>u ?
Should some "undefined behavior" notion be defined somewhere and used
here?
Nothing special happens. This is the difference between 1.5.5 and 1.5.6.
- 1.5.7 areDistinct() : this is syntactic sugar for the language level,
I would remove it from here.
One of the two is syntactic sugar for the other.
I have no preference for either, hence kept both.
- 2.6 "Exact expressions" : I was wondering what the reason of this was.
I see 2 reasons :
* being able to parse a complete expression: it seems like this belongs to
the language level.
* being able to get tighter intervals for constants which you want to
specify
as simple expressions.
The reason is that I had come across real applications (to conjectures
in pure math) generated by computer-algebra systems where constants were
quotients of very long integers or algebraic numbers defined by
expressions.
Computer-assisted proofs is one of the important applications of
interval techniques, and should be well- supported by the standard.
This is a good thing, but I think we can
generalize
it to any kind of sub-expression, not only those exact "constant"
expressions.
The idea is that we should allow an implementation to produces
tighter results
for combined operations when it can do so. For example, it should be
possible
to turn the function "(x/7)*7" into "x", or turn "sqrt(x*x)" into
"abs(x)",
since these transformations produce proovably tighter intervals compared
to the step-by-step evaluation, and the containment guarantees are still
there for the whole function.
Unless I miss some arguments which would make these transformations
invalid
for some applications, I think that we should mention it, otherwise
we may
prevent some optimization opportunities.
This is difficult to specify in a standard, since the list of useful
transformations is difficult to establish, and the demands placed on the
implementor is significantly increased. Moreover, sometimes, different
equivalent formulations have different advantages, so that there will
be hardly an agreement of what to demand. Such things are better handled
in a context like automatic differentiation type software, which
requires different expertise than those have who are likely to create
a good interval implementation.
We must place a limit to what to include in the standard.
My recommendation is of course my personal judgment, but I tried
to put the border where it benefits most.
- 2.8 : (exact interval -> text conversion): just a note : it is
possible to
exactly represent binaries in decimal text, you may only need many digits.
Yes, but this is not very convenient...
- 3.3 : (accuracy levels) : should we add that "empty" always propagate?
(the c++ proposal explicitly has "all functions, except set operations,
taking the empty interval as argument must return the empty interval.")
Yes; this was an oversight.
- Remark 3 at the end of Part 3 : should we have several levels of
conformance?
Just a data point wrt C++: my belief is that it is unlikely that the C++
standardization committee accepts a complete proposal including all
hard-to-implement
functions, as part of the C++ standard proper. We may end up with a
separate
document (still validated by WG21 though). That said, I am thinking
that it
might be possible to split the functions into an easy-to-implement base
(no elementary functions, only +, -, *, sqrt and set operations), which
could
be part of the C++ standard proper, and the other functions part of a
separate
document.
In the next version of my proposal, I propose a small subset of
core interval arithmetic - the part that would be most interesting
to have in hardware.
If this combination is accepted, then it would be nice to refer
to "the C++ standard implements IEEE-1788-part1", and "the C++
interface to
IEEE-1788-part2 is available in this other official document".
That's an argument for having several parts, and with this particular
split in mind.
- 4.2 (Boolean valued operations) : comparisons should also mention ==
and !=.
Moreover, you mention 3-valued return value, but it may be desirable to
have
a 4-valued return value. This is what we did for the C++ proposal where
interval comparisons return std::bool_set which stands for "true", "false"
"true or false" and "neither true nor false". In practice, the last value
is returned when you compare against the empty interval. You get more
information out of the comparison (the empty interval propagates :) ),
and there is no significant added cost.
Possibly yes.
- 5.1 (float -> interval) : apart from the arguments already raised, I
think
that writing "floating-point or integer x converts to interval [x,x]" is
wrong if we consider cases like 32-bit integer conversion to
interval<float>,
or 64-bit "double" converting to interval<float>: the input floating-point
or integer may have more precision that the bounds of the interval, in
which
case a conversion cannot be made to a singleton interval.
In general, for finite values, can't we simply require "the tightest"
conversion instead?
Yes.
I expect to have a new version of my proposal ready towards the end of
this week, reflecting these comments and many others I received off-line.
Arnold Neumaier