Boost logo

Boost :

From: Hubert HOLIN (Hubert.Holin_at_[hidden])
Date: 2001-05-30 16:51:11

Paris (U.E.), le 30/05/2001

--- In boost_at_y..., Peter Schmitteckert (boost) <boost_at_s...> wrote:
> Salut,
> On Wednesday 30 May 2001 00:06, you wrote:
> > Hubert HOLIN wrote:
> > > > Peter
> > > >
> > > > P.S: interval< octernion<double> > will be funny
> > >
> > > For that matter, what would interval< complex< float> >
> > > mean?
> >
> > This doesn't make sense, because complex<T> is not ordered. The way to
> > do it is to use octonion< interval<double > > and
> > complex< interval<double> >. Except that the latter is not valid for
> You're right, I've been using interval with Pascal-XSC only, there it's
> just called cinterval.
> > std::complex, because it's not defined for general T.
> >
> > Jens Maurer
> That's a pitty. I would like to use complex< interval<double> > later
> this year for some quantum mechanical calculations. Of course I can
> create my own complex for that so it's not a real problem.
> Is this currently adressed by the commitee ? Or is there a
> reason for it.
> Best wishes
> Peter

                As far as I understand it, the unspecialized template class
complex is part of the standard, but it is its instanciation with a
type other than float, double and long double that has undefined
behaviour. But it does describe the expected behaviour (for instance:
"Adds the complex value rhsto the complex value *this and stores the
sum in *this. Returns: *this." for template<class T> complex<T>&
operator+=(const complex<T>& rhs);). I interpret this as: if T has the
algebraic properties of, say, float, then the algebraic properties of
complex<T> will be what are expected. In practice that means, subject
to checking with the actual implementation, that algebraic properties
are most likely to be OK, but that transcendentals will go haywire. So
if interval<double> has the same algebraic operators than, say, double,
then the algebraic properties of complex< interval<double> > will be
what is expected.

                I believe it would be worthwile, for the next iteration of
the standard, to be more explicit on that point, perhaps with clauses
of the style: this behaves "as if" it hab been coded thus and thus, but
with the possiblities of exceptions being generated.

Tout de bon...

        Hubert Holin

Boost list run by bdawes at, gregod at, cpdaniel at, john at