# Boost :

Date: 2002-09-04 03:40:50

> The library manipulates interval with closed bounds. But it doesn't mean
> that it is not usable for intervals with open bounds; it's just a matter
> of correctly choosing the base number type. Here is an example:
>
> [...]
>
> I only described one half of the addition in this example. But I hope it's
> clear that it can be extended to the other operations and that it
> correctly defines arithmetic operations on interval whose bounds are not
> always included.

I think it should be part of the library implementation and interface.
Tweaking rounding policy to achieve open intervals does not seem for
end-user obvious IMO.

> You're right; instead of operation over pair, it will operate over list of
> pair. So let's see an example. Let's take the addition, it's quite an
> easy operation. How do we do the addition of two lists of interval? Here
> is an algorithm:
>

[...]

> I won't describe all the available possibilities and write the various
> algorithms. And it was just for the addition. What will we do with the
> multiplication and the division which are not monotonic on their whole
> domain but only on smaller parts? And the transcendental functions?
>
> Yes, you were right, the library can be generalized to deal with lists of
> intervals. But are you still ready to maintain that it is "just one small
> step ahead in terms of generalization" and that "it does not require too
> much efforts"?
>
> Regards,
>
> Guillaume

I must admit that I may be underestimate the complexity of some operation
over list of pairs, but:
1. It's implementation details. The main question is should Interval library
support this notion or not. Not how to implement it.
2. This problem a not new. I pretty sure that there are already algorithms
in a field that do the job pretty efficiently. So you won't need to invent
the wheel.
3. Whatever algorithms you will implement it most probably (I think) will
be better if any non-specialist person will start to implement it from
scratch using your simple Interval as a base.
4. It's obvious that if we use list of pairs instead of one pair all the
operation with intervals will take more time. But what if problem require
namely multi-interval values.
5. Independent from how you implement algorithms working over list of pair
single pair intervals won't be affected in terms of performance More exactly
should not. Even more exactly may be affected but difference should be
negligible.

So real question still: does the problem justify the efforts needed to solve
it?

I still convinced that support for multy-pair intervals is essential. It may
become more clear once we will see the results of domain analysis I proposed
in other post.