My vote on Motion P1788/M0036.03: Flavors is NO.
With any NO vote, I am required to state what would bring me to a "YES."
In most ways, I agree with the spirit of creating a standard that
allows for a common set of operations, and allows implementations to
extend that with a "better" set of operations for some purposes and
boundary cases (e.g. Kaucher intervals, or disjoint unions of intervals,
or various handlings of infinities, or arbitrary-precision, or symbolic
calculations.)
I would tend to vote YES for a motion that has been thought through
more clearly than this one. The rationale paper is muddled, does not
define terms that it uses, is inconsistent in its terminology (for
example, it defines "C-opinst" but then in some places uses the term
"common opinst" which is not clear if it refers to the same term; there
are many such instances of inconsistent editing,) is not consistent with
the text of the Motion, has open-ended questions, notes to self that
indicate that further research is necessary, inconsistent line wrapping
and notation, and other more fundamental problems.
The text of the Motion does also not even use the same terminology as
the text of the Rationale. The Motion cannot stand alone (and the text
of the Motion is what we're ultimately voting on,) the Rationale is not
self-consistent, and the Motion and Rationale are not consistent with
each other. These are fundamental editing problems. We need to do
better. Any time we demand the time of hundreds of busy experts, we
need to make sure that we've done our job of editing properly. (My
mantra to myself when composing group e-mails is that "if it's not worth
my time to edit and format and proofread properly, it's not worth
people's time to read it." I delete many, many emails without sending
based on this rule.)
I would strongly suggest that this motion be tabled, edited, and made
more coherent, in which case it might find more enthusiastic adherents.
A rationale paper should make its argument persuasively. The current
rationale paper does not inspire confidence.
As I have noted before, I am concerned that this standardization
effort is not paying enough consideration to "better" interval
implementations, including those that may include rational numbers,
arbitrary-precision numbers, symbolic constants (such as pi or e,) and
so on. The open-ended questions in the rationale paper do not give me
confidence that these issues have been properly considered. Is
arbitrary-precision or symbolic mathematics considered an incompatible
flavor? Or is it within the aegis of the "common operations?" (These
are apparently unresolved questions-to-self in the current rationale paper.)
Performance issues also go unaddressed here. The new "COMMON"
decoration appears to require that every operation in every flavor check
for this "COMMON" decoration to decide whether they should proceed with
calculation. This has severe performance implications, especially with
vectorized calculations. It also isn't at all clear what we do when an
implementation decides it can't deal with a result that is passed in
from another incompatible flavor. Throw exceptions? Crash? Return
wrong results silently? Do all operations now have to return error
codes in that case? Any motion for separate flavors needs to address if
we can handle this situation, and how.
I would, in the future, vote in favor of a motion that allows for a
set of "common" operations, and possibly more "better" implementations,
but this is not a motion that has been considered enough to incur the
costs of supporting additional flavors. I would hope that we could get
a stronger motion and rationale paper that demonstrates the need for
various flavors. I would like a progressive standard that works for
more people. However, as history has proven, it may be difficult enough
to for us to agree on basic operations. The additional cost/benefit
analysis of supporting multiple flavors has not been adequately
demonstrated by this motion, and for that reason, I must reluctantly
vote NO. I may vote YES on a better motion, and I encourage that a
better motion for such be put forth.