Some comments on revised Motion 19.02 (explicit/implicit)
Page 1, middle:
---------------
The distinction based on an unambiguous hull operation is fine -- but
I still resent the "All interval datatypes are equal" notion, even if
tempered by "some are more equal than others".
The statement would make sense if the only use of interval arithmetic
was certified arithmetic with uncertain numbers (for which bounded
intervals are sufficient, and blow-up to Entire is the only form of
unboundedness, signifying total loss of information).
However, when intervals are used to describe domains instead, there is
a crucial difference between inf-sup and mid-rad forms. There usually
is nothing special about the midpoint (if it exists), and semi-bounded
domains are as natural as any other. This is the view implied by
constraint-propagation and box-splitting discovery algorithms.
Also, given enough precision, any mid-rad form can be emulated by an
inf-sup form, but the converse is not the case.
The mid-rad forms do have their uses, and I would certainly want to
include support for them at least at the level of the Vienna Proposal.
3.1 New definitions -- explicit and implicit (bottom third, page 2)
-------------------------------------------------------------------
It should say: "ID is explicit if every subset ..." (not "if any subset")
3.5 Conformance Requirements (page 4), item 3.
----------------------------------------------
It should say "shall support at least one explicit inf-sup i-datatype".
(An inherently implicit inf-sup i-datatype would be one without a bound
on its resolution. This was addressed in various postings in the recent
past, and we concluded that such types were not welcome -- but they might
nevertheless be "available".)
4.2 Text representation (page 5. middle)
-----------------------------------------
The Motion 17 requirement for hex notation is only for Binary formats!
However, if the source precision is known, recovery conversion can be
used even with inexact (but sufficiently precise) decimal text strings.
In this case I->T conversion is outward-rounding to at least the decimal
precision required for recoverable round-trip conversion by IEEE 754-2008,
and T->I recovery conversion (unlike input conversion) is inward-rounding.
I know that this works for fixed-precision inf-sup types; we may have
to verify whether there is an equivalent for mid-rad types. Actually,
I think there is: the midpoint is converted using round-to-nearest in
both directions, and the radius is rounded outwards for I->T and inwards
for T->I Recovery Conversion.
Input conversion (of new data) must of course always use outward rounding.
This raises the issue of whether exported data need to be tagged with their
source precision -- but that may be beyond the scope of the standard. A
programming note would be used instead.
Come to think of it -- the conversion specifier that selects recovery
conversion could be triggered by a tag in the text input... but I think
we should, just like 754, keep silent on such details. Well, actually
this motion does have a proper section for this, namely conformance
requirement (9c) on documentation: do what you want, but say what it is!
Michel.
---Sent: 2010-09-23 22:03:39 UTC