This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: this seems to lost (complex norm, abs)
- To: lfarkas at mindmaker dot hu
- Subject: Re: this seems to lost (complex norm, abs)
- From: Theodore Papadopoulo <Theodore dot Papadopoulo at sophia dot inria dot fr>
- Date: Thu, 20 Sep 2001 20:10:07 +0200
- Cc: STDC++ <libstdc++ at sources dot redhat dot com>
lfarkas@mindmaker.hu said:
> hmm, it seems I forget my numerical experiences. but the original
> problem with norm still apply (there cant be overflow and will be much
> faster).
Well, I do not understand why it cannot overflow... The original
report is for integral types which can overflow as well.
Indeed, the current implementation will not work with integer types.
That's true, and there are two problems, none being related to abs in
my opinion (I assume that abs is defined or can be defined in some
manner for all integer types):
First the norm of a complex<T> is not a T when T is integer. Would it
be allowed to change the return type with respect to the standard ??
Then T (or _Tp in the implementation) is also used internally as the
computation type, and that's why it does not work since the divisions
will almost always yield 0 (sometimes 1).
The simpler way to get something that is correct for all standard
numeric types, is to convert the return types and the last 3 line of
the current implementation to use doubles (long double would be
better but so less efficient), but that's dirty.
Another ugly solution, is to use overloading for creating norm only
for the complex<one of {float,double,long double,char,int,short,unsigned,..}>.
The better solution would be to create some traits to handle the type
promotion and use it for the return type and the computation types.
The advantage is that it would be somewhat expandable to user defined
types. But that's also more complicated... For example, what should
be the return type of norm(complex<int>) a float, a double ???
Which solution is the best with respect to the standard, I do not
know....
C arithmetic rules sometimes hurt when used with generic code...
--------------------------------------------------------------------
Theodore Papadopoulo
Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
--------------------------------------------------------------------
PGP signature