Re: A mid-rad interchange motion...
Dan, P1788
On 14 May 2010, at 20:40, Dan Zuras Intervals wrote:
> I have a special on friendly amendments at this time.
> This week only, two for the price of one.
A.
The motion looks good to me. Can I suggest, as I present my 2-for-1 voucher at the checkout:
(a) "conversions to and from that type and any other type" is bad grammar and should be either "conversions between that type and any other interval type" or just "conversions to and from that type". (Occurs twice.)
(b) You might like to change the wording about import & export slightly after reading my I/O motion.
B.
Here's something different but related. The current description of inf-sup & mid-rad in our Definitions, e.g.
"2.2.17. mid-rad. Describes a representation of an interval based on its
midpoint and radius."
is pretty vague. I wonder if we should change it on these lines:
- Introduce the term "interval type", suitably defined, to supplement or even replace "interval format" (definition also a bit vague at present).
- Define an interval type to be an inf-sup or mid-rad type depending on its level 3 representation:
An inf-sup interval type is one whose level 3 representation by
floating-point numbers lets the lower and upper bound of each
nonempty interval of that type be retrieved exactly.
and
A mid-rad interval type is one whose level 3 representation by
floating-point numbers lets the midpoint and radius of each
nonempty [add "bounded" here?] interval of that type be
retrieved exactly.
Letting level 3 drive the definition looks perverse, but it seems to me that's where the essence of the two kinds of type lies.
However, I'm not sure whether a "mid-rad1-rad2" type admits a definition on these lines, because of the extra degree of freedom in describing it by 3 numbers instead of 2.
John