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

From: Guillaume Melquiond (gmelquio_at_[hidden])
Date: 2003-05-05 09:25:02

On Mon, 5 May 2003, [iso-8859-1] Terje Slettebø wrote:

> >From: "Guillaume Melquiond" <gmelquio_at_[hidden]>
>
> > As I explained in a previous mail, interval/io.hpp is only here as a
> > debugging tool, it is not included by interval.hpp, and each user should
> > define its own versions of >> and <<. As I suggested before, I am even
> > ready to suppress this file if it could clear any misunderstanding on its
> > purpose.
>
> Ah, sorry. As I hadn't followed the Interval library formal review, I
> started reading the postings in that thread, but as there were a lot of
> postings, I didn't read that much, there, and instead read the docs.

It was in a thread two weeks ago. And my conclusion was something like: it
is a pain to define generic input/output operators. We gave it a lot of
thoughts during the design phase of the library and finally:

  For this, we would need an extra i/o policy. It was not felt worth the
  trouble. For one thing, it's always possible to display the bounds. For
  another, intervals are used somewhat internally and there is seldom need
  to display them.

(in the rational part of the documentation).

And since the user would provide this policy, she can directly provide the
i/o operators.

> 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?

> > It is a nice idea and could probably be useful in some particular
> > situations.
>
> Yes, when using intervals to specify precision, which according to the docs
> is one of the motivations for the Interval library. Especially in scientific
> calculations, to ensure that the result isn't given with more significant
> digits than warranted by the values used.
>
> Paul A. Bristow asked in the quantity-thread if the quantity libraries could
> be used with the Interval library, which is why I looked into it.
>
> For example, using it, you may do like this:
>
> meter<interval<double> > length(10.00, 10.01);
> second<interval<double> time(3.000, 3.001);
>
> std::cout << length/time; // Prints 3.33 m/s
>
> Had the Interval library not been used, it would have printed "3.333333
> m/s", a precision not warranted by the values used.
>
> One of way you may fail a science test at school is to use more digits in
> the answer than what is warranted by the values used. As you know, it's an
> important concept in science, similar to using correct units in
> calculations, which would be taken care of by a quantity library. Thus, they
> work well together.
>
> The way to specify number of significant digits is a little obscure, though.
> Being able to do "interval<double> value(<value>, <number of significant
> digits>)" could have been easier to use, but a two-argument constructor
> already exist for specifying the lower and upper values, and using intervals
> for precision is only one application of it, so it may be better to have
> something like this outside the library. For example something like:
>
> std::cout << make_interval<double>("10.0")/make_interval("3.00"); // Prints
> 3.33
>
> This would also make it possible to define an input operator, using the same
> routine.

Yes, it would be a good idea. But it requires a specially crafted parser.
It is also specific to decimal floating-point inputs.

> > 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.

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.

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.

> > 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.

Regards,

Guillaume