Re: Re-submission of motion 5: multiple-format arithmetic.
Ralph Baker wrote:
> Arnold Neumaier wrote:
> > Not deciding this issue (modal or not) very soon will
> > constitute a major quarrel in each issue to be decided.
>
> Does someone wish to formulate and formally put forward a
> simple motion to decide whether or not the standard should
> explicitly contain specifications for modal arithmetic?
I've been "away" from 1788 matters for a while (vacation, then
busy with other matters), though I have been following the
discussion somewhat. I may reply in detail after reading the
whole stuff again soon -- but a quick reply is needed here.
I think the issue of including modal arithmetic (or any specific
form other than the one that the standard concentrates on) is the
wrong issue. The right issues are:
(1) whether the standard has provisions that preclude proper
(or reasonably efficient) support of other forms
(2) whether the standard is willing to define other arithmetics
to the point that, *if* provided, they must be provided in
a standard manner (but actual support is optional)
(3) whether the standard should support or encourage certain
primitives that would be useful to other arithmetics even
though they appear unneeded for the standard arithmetic
The point of (1) is that some choices may have little impact in
the intended arithmetic model, but could have a significant impact
on others -- so we should try to avoid a choice that hurts others.
The point of (2) is that would satisfy the primary reason for having
a standard, namely that if a feature is there, it is there in a form
that is predictable across computing platforms.
The point of (3) is that some primitives are not difficult at all to
provide in a uniform manner, that they may be useful to applications
outside the originally considered application domain, but that would
be useless without a precise specification.
It is perfectly reasonable to admit (indeed, specifically warn about)
the fact that using certain primitives violates certain global
desiderata of the standard, e.g. the BTIA. 754 does this with respect
to reproducibility (a general goal violated by some operations) and
NaN propagation (as discussed recently in this forum).
In particular, I like the "two opcodes" approach, which addresses a
fundamental concern not only for the support of modal arithmetic, but
also for organizing interval computations in general -- namely, how
to interpret function domains. (This issue even pervades mathematics
in general, i.e. whether the concept of partial function is present
or not.) There is precedent for this: in 754, two forms of predicate,
one signalling on QNaNs and one silent; and in the Vienna proposal,
forwards and backwards forms.
I think that the Vienna proposal strikes a reasonable balance with
respect to the points mentioned here, except for the distinction of
interest here, namely handling of out-of-domain cases. Vienna *does*
address the point with its sticky domain-error flag, but that brings
with it not only the burden of flags (which can be relatively minor
if locality issues are properly addressed), but also the burden of
continuing to compute and propagate results that will eventually be
thrown away. Now, in may contexts throwing away results is in fact
overall cheaper than always deciding whether or not to compute them
-- but not always, and in some cases it could be prohibitive. This
is why the programmer should have control over this. (Whether this
control is expressed via modes or variant function names is not quite
as critical, as either can be taken as syntactic sugar for the other
in many cases.)
Michel.
---Sent: 2009-06-12 14:16:59 UTC