Re: Why (IMO) you should vote Yes to Motion 14.02

[Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>]

> 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.

	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.