Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Motion 6



> Date: Thu, 17 Sep 2009 02:43:26 +0200
> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> To: stds-1788@xxxxxxxxxxxxxxxxx
> Subject: Re: Motion 6
> 
> On 2009-09-16 16:52:38 +0200, Arnold Neumaier wrote:
> > I'd prefer a motion to exclude midrad from consideration.
> > We have more than enough to do for infsup, and most considerations
> > for midrad are completely different than those for infsup, so that
> > virtually everything done for infsup would need to be reconsidered
> > carefully.
> > As a result, the work load would nearly double.
> 
> I don't think so. The common part could be considered, and everything
> else specific to midrad could be left to the implementation.
> 
> The relation between (future) language support and P1788 is not clear
> yet, and I fear that if midrad is excluded from P1788, it will be more
> difficult to have it recognized at some levels.
> 
> > Nobody in practice uses midrad as a basic representation,
> > except for input/output, where only the conversion behavior
> > needs to be specified, but not the arithmetic.
> 
> Perhaps currently. But IMHO midrad would be useful in multiple
> precision, where the error can be in much smaller precision.
> 
> -- 
> Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.org/>
> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
> Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

	Vincent,

	The issue of a midrad representation with the midpoint of
	a different precision aside for the moment, you must at
	the very least acknowledge that the set of contiguous
	intervals on the reals extended to infinity is represented
	in one way under infsup & another under midrad.

	They are two different sets.

	In particular, the semi infinite sets have no representation
	in midrad.  An important subset in need of representation.

	On the other hand, the midrad permits vastly narrower interval
	representations than does infsup.  But ONLY if the midpoint
	is a representable number.  Probably not as important a subset.

	These two sets are not interconvertable so any attempt to
	make an interoperable standard could not permit a variation
	along these lines in the style of their interval
	representations among standard implementations.

	If I had to choose one I would choose infsup on grounds you
	know better than I.  But that's just IMHO.

	Still, this does not mean that midrad won't have a place in
	intervals.  In particular, in many of the algorithms for
	which you use it, you likely choose a midrad for reasons of
	computational efficiency.  And for those problems that are
	sufficiently intractable as to require such an approach, I
	would have every expectation that a midrad would be used by
	the implementor internally to accomplish that.

	If you feel that such a thing needs to be standardized for
	that reason alone, I would support it.  But, if so, I would
	like to make the language of our support to be written in
	such a way that means we are not recommending midrad be used
	for 'general' interval problems.

	Would that be sufficient?  Or is your argument of a more
	fundamental philosophical nature?

	Yours,

				   Dan