Re: Why (IMO) you should vote Yes to Motion 14.02
Dan,
VERY interesting. What you outline certainly is closer to the standard I think I'd like to see, if we can develop such.
On Jun 30, 2010, at 2:38 AM, Dan Zuras Intervals wrote:
>> From: "Nate Hayes" <nh@xxxxxxxxxxxxxxxxx>
>> To: "Dan Zuras Intervals" <intervals08@xxxxxxxxxxxxxx>,
>> "Christian Keil" <c.keil@xxxxxxxxxxxxx>
>> Cc: <stds-1788@xxxxxxxxxxxxxxxxx>
>> Subject: Re: Why (IMO) you should vote Yes to Motion 14.02
>> Date: Tue, 29 Jun 2010 18:49:11 -0500
>>
>> Dan Zuras wrote:
>>> As for sorting out the nature of supported formats, I think
>>> we would all be well served to ignore the nature of those
>>> formats entirely in the normative text in favor of describing
>>> their behavior only. If we confined all mention of inf-sup or
>>> mid-rad to informative notes & confined our normative text to
>>> making restrictions on how they shall behave, it would be a
>>> better standard for it.
>>>
>>> That's not a bad approach now that I think about it.
>>>
>>> Let's consider that as a principle in the writing of this
>>> standard.
>>
>> Dan,
>>
>> This is an interesting idea.
>>
>> But can you elaborate on what you mean by "how they shall
>> behave"? I'm not quite sure what you mean by that.
>>
>> Nate
>
> OOoo, a challenge.
>
> I say, what about this & you say, show me it has merit.
>
> A good challenge. And a reasonable question. I like that.
>
> I don't know if it has merit.
>
> Let's see if we can find out.
>
> Let's start with 6.1. How about we make the exact extraction
> of bounds the defining characteristic of the mapping from
> level 2 back to level 1? Where level 1 is the set of all
> contiguous intervals chosen from the set of extended Reals.
> And level 2 is some finite subset of that set.
>
> Let each interval datatype always be associated with a
> floating-point datatype. Fixed precision, arbitrary
> precision, binary, decimal, I don't care. Whatever you
> have lying around in your language. So we will call one
> interval datatype a Binary64 interval type because we can
> exactly extract bounds to Binary64. We will call another
> a Decimal3000 interval type because we can exactly extract
> bounds to a 3000 digit decimal datatype. Whatever.
Would we want to specify a few floating-point datatypes to promote reproducibility?
>
> Let the actual representation in registers, in memory, on
> communication channels, whatever, be something we never
> speak of (no 'should's or 'shall's). There could even be
> many representations for the same interval in your format.
> So long as all representations from which the same pair of
> upper & lower bounds can be extracted:
>
> (1) represent the same level 1 interval,
> (2) compare as equal however they are compared,
> (3) have no elements in one that are not in the other,
> (4) behave exactly the same when they participate in
> arithmetic or non-arithmetic operations.
>
> Let the mapping from level 1 to level 2 be defined by the
> narrowest mapping possible. That is, of all the objects
> that exist in your representation that represent supersets
> of a given level 1 interval, let the mapping be to some
> object which is a subset of all of them. There may be
> many such mappings. And the are all, of course, equal in
> the above sense.
>
> Now, with mappings back & forth we can define arithmetic.
>
> Let any operation be defined by mapping its operand(s) to
> level 1, applying that operation there, finding the
> contiguous hull of the result there & mapping that result
> back into your format in the tightest sense as defined
> above.
>
> That gets us most of it. Doesn't it?
>
> Perhaps the level 1 --> level 2 mapping rule is too strict
> for you. I suppose we could consider loosening it a tiny
> bit so long as that loosening does not admit anything silly.
>
> My first thought is to leave it alone but I may be wrong in
> that. Maybe some leeway could be found that makes things
> easier for some formats. Some formats like mid-rad, if I
> am not clear on that point. :-)
>
> And none of this discusses those formats AT ALL. We never
> have to discuss anything below level 2. We could have
> informative notes lying around but they have, frankly,
> been more obfuscating than illuminating up til now. :-)
>
> We don't care how you represent things & we need not care
> so long as we can predict their behavior.
>
> Is that a reasonable approach?
>
> Is that an adequate answer to your challenge?
>
> Does that have merit?
>
> Your call.
>
> I expect many answers. :-)
>
>
> Dan
>
>
> P.S. - If someone looks at this & claims that I have
> defined mid-rad out of it or defined an inf-sup only
> system, I am going to dispute that claim. You KNOW that.
Yes, we know.
Dr. George F. Corliss
Electrical and Computer Engineering
Marquette University
P.O. Box 1881
1515 W. Wisconsin Ave
Milwaukee WI 53201-1881 USA
414-288-6599; GasDay: 288-4400; Fax 288-5579
George.Corliss@xxxxxxxxxxxxx
www.eng.mu.edu/corlissg