Re: A mid-rad interchange motion...
> Subject: Re: A mid-rad interchange motion...
> From: John Pryce <j.d.pryce@xxxxxxxxxxxx>
> Date: Sat, 15 May 2010 04:49:52 +0100
> To: P1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> 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".
You got it.
> (Occurs twice.)
Well, let's count that as one. What else would you
like today?
>
> (b) You might like to change the wording about import & export
> slightly after reading my I/O motion.
Hmm. I'm a little less clear on what you want here.
I must admit that the use of the words import & export
caused a tingle in my spider sense in that I did not
define what import & export operation ARE, after all.
If you would like to define them, I'm OK with it.
Or if you would like to use other words when it works
its way into the draft, that is the editor's privilege.
If the intended meaning is clear my words are not
important to me.
>
> 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).
I think this is, again, editor's privilege.
But we had this problem in 754 so its worthy of
discussion.
In 754, the problem centered on how we make the
distinction between the abstract set of values
that a datatype represents & the encoding of that
set of values in memory. Most of the time we
wanted to be mathematically precise on the former
& lax on the latter. Except for the encodings of
interchange formats, that is.
As I recall we avoided the use of the word 'type'
at all. I apologise for bringing the word back
up again but it was a compromise at best.
I believe we ended up using 'format' for the
abstraction & 'encoding' for the bit patterns.
I guess you would call them level 1 & level 3,
respectively.
I suppose 1788 could also use those terms. Feel
free to look up the exact definitions in the 754
document itself.
Or you could use your own terms.
I guess the reason the compromise doesn't sit well
with me is that 'type' sounds like an abstraction
to me & 'format' sounds like an encoding.
But much of standards work involves the use of
tortured language if only to avoid more common
terms on the grounds that those terms also carry
with them connotations we would like to avoid.
Simple language versus words we explicitly define
for ourselves.
It is a difficult problem.
>
> - 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.
It looks perverse to me as well. I think of the
distinction as living at the set of values each
form represents. Therefore, level 1.
>
> 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
Again, a different set. I think making that distinction
at level 1 is best.
But I've been wrong before.
I thought I was wrong once but I was wrong. :-)
Enjoy,
Dan
P.S. - Oh, here is the motion changed as John asked:
---------------------------------------------------------------
An interval type is said to be <b> supported </b> if all
required operations are implemented as well as conversions
between that type and any other interval type and import from
and export to text strings.
An interval type is said to be <b> available </b> if conversions
between that type and any other interval 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.
---------------------------------------------------------------