RE: A mid-rad interchange motion...
Looks very good. Since it was submitted by two folks it probably does not need a second but if necessary I will be glad to second it.
-----Original Message-----
From: stds-1788@xxxxxxxx [mailto:stds-1788@xxxxxxxx] On Behalf Of Dan Zuras Intervals
Sent: Friday, May 14, 2010 1:40 PM
To: stds-1788@xxxxxxxxxxxxxxxxx
Cc: Dan Zuras Intervals
Subject: A mid-rad interchange motion...
Folks,
Arnold & I have been working offline on the text of a mid-rad
interchange motion. I think it is much improved. And the credit
for that goes much to Arnold. Thank you Arnold.
As it is now, we define two new terms: 'supported', meaning fully
supported for all required operations (our intention for inf-sup)
& 'available', meaning merely supported for conversion to & from
(our intention for mid-rad & mid-rad1-rad2).
The motion is pared down to just 3 shalls: (1) saying that one
shall have at least one of each type, (2) saying that conversions
shall tightly preserve containment, & (3) saying that importing
from & exporting to text shall be tightly contained as well.
There is also an informative note stating explicitly that the
standard is silent on the issue of further support for available
but not supported types.
(I know: an explicit statement about being silent. As Arnold
puts it, it is the MOTION that is being explicit on what the
STANDARD should be silent about. He is right, of course.
So gimme a break. :-)
So, I submit for your approval, from both of us, this motion
for mid-rad as an interchange only type:
---------------------------------------------------------------
An interval type is said to be <b> supported </b> if all
required operations are implemented as well as conversions to
and from that type and any other type and import from and export
to text strings.
An interval type is said to be <b> available </b> if conversions
to and from that type and any other type are implemented as well
as import from and export to text strings.
A conforming implementation shall support at least one inf-sup
type and make available at least one mid-rad and one mid-rad1-rad2
type.
All conversions shall preserve containment and return the tightest
representable interval in the target type.
All imports shall preserve containment and return the tightest
representable interval in the target type. All exports shall
preserve containment and return the tightest representable text
string in the specified format.
NOTE --- This standard is silent on the matter of other
operations implemented for types that are available but not
supported.
---------------------------------------------------------------
I have a special on friendly amendments at this time.
This week only, two for the price of one.
Enjoy,
Dan