Re: A suggestion regarding status change Motion P1788/0023.01:NoMidRad -- VOTING PERIOD BEGINS
Michel Hack wrote:
I guess it's up to Dan formally to withdraw and resubmit Motion 23,
but if he does, I will second it.
Here is the revised text (extracted from Arnold's note of Oct 11):
**====================================================================
It is proposed that, apart from conversion issues, approximately to
the extent specified in the Vienna Proposal, specifications shall be
provided by the final standard text only for infsup interval types,
and only for standard intervals, i.e., those that represent closed
and connected sets.
On the other hand, nothing should prevent implementors from providing
arbitrary functionality for midrad interval or nonstandard intervals,
as long as the required conversion rules to all (and at least one)
supported infsup datatype are respected.
**====================================================================
I actually think that Nate's reaction to Baker's "redefinition"
of Motion 23 was overblown. At issue was:
... Also, by "nonstandard intervals," let us agree that
this means Kaucher arithmetic. (Otherwise, one might
think "nonstandard" meant "anything not in the standard,"
something that would not make sense in this context.)
Nate must have overlooked the "Otherwise" part. Baker's
clarification was only about a possible mis-interpretation
of "non-standard", and did not change our collective position
on Kaucher arithmetic (discussed at length a year or two ago).
I don't remember any votes on this.
Apparently you have some "insider" information that I don't.
Was there any possible interpretation of Arnold's original statement:
| ----------------------------------------------------
| The standard shall not support a midrad interval format or
| nonstandard intervals, beyond providing conversion support,
| approximately to the extent specified in the Vienna Proposal.
| ----------------------------------------------------
that would have permitted actual support for Kaucher arithmetic,
in view of discussions (and Motion 3) from the past?
Of course.
Nate also wrote:
I believe the time for standardization of Kaucher arithmetic is ripe,
if not already overdue.
Perhaps so, but that earlier discussion settled on the notion that THIS
standard was not the place for it, as it would greatly hinder a simple
and consistent exposition. Then as now the concurrent availability of
Kaucher (or mid-rad for that matter) was not precluded -- but the
expectation was that such support would be provided through separate
datatypes (explicitly, or implied by convention, depending on the level
of primitive support in the language under consideration).
I also agree with the need to address the name of the standard, but (as
Baker explained) that is a separate and non-trivial procedural matter.
Then by all means the better it should be done sooner rather than later.
As for the perceived conflict between Motion 23 and (revised Motion 19,
I'll have to re-read the latter to refresh my mind, but I interpreted
M0019 primarily as providing a framework for describing additional
interval types, beyond those formally supported by the standard. (I
know that's not how it was written or perhaps intended; as I said, I'll
have to reread it to comment with more assurance). With my current
interpretation I would see no conflict. A more direct blow to mid-rad
would be to require support for semibounded intervals, which is of a
different nature from unambiguous tightest-hull definability. (Btw,
I also don't see how Kaucher intervals fit into Motion 19 -- I believe
the Kaucher issue was essentially settled by Motion 3, was it not?)
Absolutely not.
As for applicability of hardware-supported Kaucher arithmetic: is it
not also possible to exploit this for "standard" arithmetic? Or are
the tweaks required for this more expensive than those required to
exploit current 754-2008 primitives?
The "tweaks" required are Kaucher arithmetic.
Nate Hayes
Michel.
---Sent: 2010-10-12 08:58:42 UTC