Re: Branch & bound for not everywhere defiend constraints
> Date: Tue, 8 Sep 2009 14:20:04 -0400
> From: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
> Subject: Re: Branch & bound for not everywhere defiend constraints
> To: STDS-1788@xxxxxxxxxxxxxxxxx
>
> Dan Zuras Intervals wrote:
> . . .
> >>
> >> No. This absolutely rules out the entire NaI concept.
> >
> > Other than in name, I don't see how.
>
> Ok. I'm sorry. Here is what I mean:
>
> To me "decorated interval" has a very specific meaning from Design Patterns.
> In this case, a decorated interval is an abstract ideal representing some
> structure or aggregate comprised of an undecorated interval and its flags
> bits. The implementations may vary, but a decorated interval always has two
> portions: the undecorated interval portion and the decoration portion.
>
> NaI just represents the decoration and does not have an undecorated portion
> (that part is lost when NaI is instantiated).
Sorry. I'm still not getting the problem.
On the one hand I grant that decorated intervals may not
be the final answer to our problem of how to make intervals
sufficiently rich to do what we want while avoiding old
754 errors like global modes & flags.
On the other hand, if there is an abstraction for an NaI
that somehow lives in the upper & lower bounds of an
interval, OR, an abstraction for an NaI that lives in a
decoration, how does that change any algorithm that uses
that abstraction?
Perhaps there will turn out to be performance issues. But
we will never know unless we know something about what is
being done & what sort of performance we can expect out of
it.
Either way.
Sorry, but I still don't get it.
>
> . . .
>
> > It all seems entirely equivalent to me. The issue of
> > power-or-two in size is not so important as you make it
> > out to be, IMHO. The rest is a question of the choices
> > an implementation makes to beat its competition.
>
> I believe the question is deeper than implementation: is there an example of
> interval algorithms at the mathematical level that actually require both
> portions of a decorated interval?
Now, you KNOW that is a question that you & the other
interval experts are more qualified to answer than I
am.
But is the question even posed in the right way?
Shouldn't the question be something along the lines
of just what attributes do we need our intervals to
have in order to make them mathematically correct &
implement the algorithms we need to use?
And if the question is posed at the abstraction level,
isn't the issue of HOW those attributes are provided
mostly an implementation issue?
>
> Alexandre's fixed-point example, as originally presented, required both
> portions. But when reformulated into a branch-and-bound problem, this
> mutual dependency no longer exists (so NaI is adequate).
>
> If decorated intervals are not required at the mathematical level, I wonder
> why are they required at the implementation level? That is what I do not
> understand.
>
> Nate Hayes
An excellent question.
Are attributes other than those needed to represent
closed connected sets of real numbers needed at the
level of a mathematical abstraction?
It seems the empty set & sets open ended to infinity
are required to complete limit sets if nothing else.
Is anything else required?
A couple of people have made the case that an NaI
caused by the illegal use of an interval constructor
may be needed. But this is ALREADY out of the relm
of mathematical abstraction & into the practical
problems of posing the questions of our world into
the language of intervals.
Is there anything else that lives at the level of
mathematical abstraction?
Again, you & the others who have studied intervals
while I spent my career on floating-point chips are
more qualified to answer this question than I am.
I leave it to you all...
Dan