Re: the "set paradigm" is harmful

[Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>]

	Baker & co,

	I realize you are doing part of your due diligence as chairman
	to suggest this motion but I must say that I would resist such
	a motion.

	I have not commented yet because far better qualified people
	have been making the case against this.  But the simple fact
	is that midpoint-radius representations are not equivalent to
	or interchangable with inf-sup representations.

	There is no problem with specifying conversions to & from the
	midpoint-radius representation but to have some implementations
	use it for calculations & others use inf-sup representations
	would be inconsistent with our overall goal of assured
	computation.

	(If it comes to it I can make the case for that claim in a
	later note.)

	I believe that what Svetoslav wants is a laudable goal but
	involves different principles than we are trying to lay down
	here.

	While he may not believe it at the moment, I believe that
	Svetoslav will be able to do useful work with intervals as
	we will end up defining them.

	Let's let that process play out & see...


				Dan

> Date: Tue, 10 Feb 2009 07:43:01 -0600
> From: Ralph Baker Kearfott <rbk@xxxxxxxxxxxxx>
> CC: stds-1788@xxxxxxxxxxxxxxxxx
> Subject: Re: the "set paradigm" is harmful
> 
> Svetoslav et al,
> 
> I see several possibilities of accommodating midpoint-radius
> representations in the standard.  One might be to simply
> specify two representations for intervals, and specify
> conversion between the two.  (That might be the simplest way.)
> Does anyone care to make a formal motion to that effect?
> If such a motion passes, we can then work out details.
> 
> There is another representation of intervals in use to avoid
> having to change the rounding mode: [-inf,sup].  However, we
> may be able to accommodate that representation within the [inf,sup]
> representation by "as if" wording.
> 
> Baker
> 
> P.S. I'm not sure in exactly what places, if any, the issue of accommodating
>       midpoint-radius impacts the two motions currently being
>       formally processed. (P1788/M0001.01_StandardizedNotation and
>       P1788/M0002.01_ProcessStructure)  The first deals with the
>       notation to be used in the standards document and the second deals
>       with the structure of the standards document (and not its actual
>       content).  If there is anything within these motions that
>       impacts midpoint-radius, please be VERY specific about where.
>