Boost logo

Boost :

From: David Bergman (davidb_at_[hidden])
Date: 2002-09-09 20:36:34


Hmm, is "std::complex" not supposed to give us an abstraction for
complex numbers in the Cartesian plane? There has been arguments in this
thread of using

        complex<interval<double>>

What sense does that mean? It is not that "std::complex" is an alias for
"future_std::make2D"... The type parameter in the "std::complex" is an
implementation-issue, not an issue of specializing an abstraction. One
should differentiate template instantiation as either (1) conceptual
specializations or (2) implementation specializations.

But, this wanting to have uncertainty in complex operations represented
by an interval emphasizes that the interval library should handle things
beside one-dimensional continuum... What we want is
interval<complex<double>>.

/David

-----Original Message-----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of Herve Bronnimann
Sent: Saturday, September 07, 2002 2:17 PM
To: boost_at_[hidden]
Subject: Re: [boost] Formal Review for Interval Library (was:
IntervalLibrary reminder)

On Sat, Sep 07, 2002 at 07:29:00PM +0200, Gabriel Dos Reis wrote:
> | Note that for intervals, it was a question at some point whether we
> | should provide specializations for T==float, double and long double,

> | with additional implicit conversions for float->double->long double.

> | For those ones, we can guarantee at least that there is no loss of
> | precision.
>
> This is what is done in the standard for std::complex<>, and in effect

> you end up rewritten the same thing over and over...

Yes that was also one worry. Although we tried to keep the class
template interval at its smallest, all of its members have to be
redefined for each specialization. And luckily, interval<T> does not
have as big an interface as complex<T>, but even then...

-- 
Herve'
_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk