Re: [boost] Re: I/O operators for Interval library

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2003-05-05 17:17:03

>From: "Guillaume Melquiond" <gmelquio_at_[hidden]>

> On Mon, 5 May 2003, [iso-8859-1] Terje Slettebø wrote:
>
> > >From: "Guillaume Melquiond" <gmelquio_at_[hidden]>
> >
> > The proposed output operator may be more general-approach, though, for
the
> > cases where intervals are used to specify precision, so it might be
useful
> > to provide it in some way, rather than each user having to make it.
>
> Unfortunately, is there really a version of the operators that could be
> useful to more than a few users?

I guess it depends. As mentions, Paul A. Bristow brought up the issue of
using the Interval library with a quantity library. Unless the values are
represented in a way that's easy to understand, such as this, it may be hard
to use it with it. If he's reading this, maybe he could comment?

> > > Another point: your operator expects the two bounds of the interval to
be
> > > of the same sign. If the interval contains 0, the answer won't have a
lot
> > > of meaning. Moreover, if one of the bounds is 0, the behavior probably
> > > is undefined.
> >
> > Ok. Is there any way to fix this? I've attached the new version of the
> > operator, and a test file.
>
> I don't know if there is a way to fix it. More precisely, I don't know how
> to interpret an interval value with bounds of opposite sign, from a
> precision point of view. The operator could answer "no significant digit"
> since there is an infinite loss of precision.

Right. That's how you may represent it.

> But another user may prefer to get the full interval [?,?] in this
> situation. Or maybe having the median and a +/- approximation is enough.
> Or... Here we are back to what I explained, the display of intervals is an
> operation which is really dependent on the user program and I don't think
> the library can provide generic i/o operators.

Well, if you have an interval which crosses or includes zero, and the
interval is meant to represent precision, then I think it's reasonable that
it interprets it as loss of all precision, and possibly do something
exceptional, such as throwing an exception.

I understand that it may be difficult to provide generic I/O, when the
interval can mean anything. However, in this case, it means precision, so
that's the context one may use.

> Other problems that need to be thought of: how to handle infinite bounds
> (due to an overflow for example) or empty intervals? It is not that easy
> to define output operators useful to a lot of people. This discussion
> could be related to the discussions about the output of STL containers.

Right. One could be back to the policy-approach discussed in the docs.

> > > Finally, there might be a lot of problems with respect to rounding
policy.
> > > But I don't really want to speak about them: it is kind of an internal
> > > problem to the library and it would be important only if the users
expect
> > > the operators >> and << to behave like the arithmetic operators.
> >
> > In what way do you mean arithmetic operators? Do you mean bit-shift? It
> > should be clear from the context that it's a stream operator.
>
> Not at all. For example, the user is allowed to ask the library to perform
> code optimizations on blocks where only interval library computations are
> used. So, depending on whether >> and << can be called interval
> operations, some care need to be taken in order to ensure such properties.
> So it is only an internal problem to the library and it is not really
> useful to deal with it now.

Ok. Well, since << and >> deals with I/O, I think they may be considered not
interval computations.

Regards,

Terje