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

Re: Include language bindings? Re: Draft Standard Text, V02.1

Dan Zuras Intervals wrote:

Date: Tue, 16 Mar 2010 13:04:26 -0500
From: "R. Baker Kearfott" <rbk@xxxxxxxxxxxxx>
To: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
CC: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>, stds-1788@xxxxxxxxxxxxxxxxx
Subject: Re: Include language bindings? Re: Draft Standard Text,
V02.1

Dan et al,

My view in the past is that the reformulation is the responsibility
of the programmer.  Although this greatly simplifies compiler
writing, and indeed, standard-writing, it requires the programmers
know what they are doing.  One reason I favor this position is that
I know of very few rearrangement rules that result in narrower
interval values in all cases.

Best regards,

Baker



Baker,

It is, or was, my position as well.

It is a reasonable one.  And defensible on grounds of
simplicity, clarity, transparency, & reproducibility.
The programmer will get exactly what the programmer
asks for.  No more, no less.

Still, there is much to be gained by narrowing a
calculated interval to something more resembling its
true variance.  It would be best to teach programmers
how to do this but the gains are there whether the
programmer knows how or not.

Nate, are there rules that always win?  And can they be
stated simply, clearly, transparently, & reproducibly?
THe topic of how to defeat unrecognized interval dependence is huge. Essentially, this is the definition of "interval analysis."
Monotonicity analysis, endpoint evaluation, bisection, interval Newton. These are all just a few simple and commmon examples of how to defeat unrecognized interal dependence. 

Do these subjects belong in P1788? Personally, I don't think so.
Making careful study of basic arithmetic and algebraic properties of intervals, however, I think is key to P1788. A good study and use of these simple properties can lead to faster and more efficient interval analysis implementations. Particularly in the design of optimal hardware circuits.
Intuitively, I think this is what I hear you and Baker in so many words arguing for, as well. If so, I believe we have a common understanding. 

Nate





I must presume that at least some of these optimizations
are more than data dependent tricks that work in some
cases & not others.  Can we at least standardize those
first & make them available to the programmer?  Whether
default or not?

At least this would be a good place to start.

Yours,

Dan


P.S. - It occurs to me there might be another way to go.
I believe that the 1788 standard must be a pedagogical
document as well as a normative one.  Therefore, could
we write an extensive annex on algebraic reformulations
that are known to improve results?  If complete enough,
it is possible that the normative specification of 'Do
exactly that which is written, no more, no less' when
supplemented by a 'How to narrow your interval results'
annex could suffice for a standard.  It could work.
And it would be a far simpler standard.