
Boost : 
From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 20020311 17:12:53
> 1. The best implementation of complex is obvious. Anyone who used
> complex numbers and understands C++ would do it pretty much as the stl
> version.
I believe that's not correct.
On many machines, for certain number types, multiplications are
significantly more expensive than additions. Therefore, the wellknown
algorithm (attributed I recall to Gauss) that multiplies two complex numbers
using only three multiplying operations and a couple more adds would be
useful in implementing complex<T>::operator*().
Or I only thought it's well known. Three STL implementation I looked up use
the brute force approach to multiplying complex numbers, regardless of their
type :o/. One for good quality STL implementations.
Of course, the legendary YASLI (Yet Another Standard Library Implementation)
implements complex multiplications efficiently.
> 2. I doubt if there is any optimal representation for rationals. I
> have used about a dozen myself. You will never find a class that makes
> more than about 30% of the users happy. The best plan might be to have
> several types, such as:
>
> a) two fixed integers, overflow is tuff luck
>
> b) two unlimitedprecision integers. This calls for a standard
> unlimitedprecision integer class, which should be done first.
>
> c) two fixed integers, and a float to use for 'fall back' when a
> number cannot be represented. I usually use a char to indicate which
> rep is in effect.
>
> d)two fixed integers, a fallback float, and also let the char indicate
> other events, such as plus, minus, and unsigned infinity, and NaN.
>
> 3. A method for rat_to_float is easy, but float_to_rat that correctly
> 'rounds off' is hard. I am not aware if a useable algorithm is known.
I guess you don't want to represent a rational with a floating point number
because you can't satisfy most of the expectations you'd have from a
rational number. For the other options, a straight design with policies
sounds appropriate.
Andrei
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk