std.complex

[Craig Dillabaugh]

On Wednesday, 1 January 2014 at 12:29:35 UTC, Stewart Gordon
wrote:
> On 19/11/2013 02:03, Andrei Alexandrescu wrote:> On 11/18/13 
> 5:44 PM, Craig Dillabaugh wrote:
> <snip>
>>> Is there any reason why complex numbers in D's standard lib 
>>> must
>>> be of non-integral types?  I believe in C++ the type is 
>>> optimized
>>> for floating point values, but allows other types.
>>
>> The simple reason is we couldn't find appropriate applications.
> <snip>
>
> I don't understand.  At the moment Complex appears to me to be 
> type-agnostic - as long as a type supports the standard 
> arithmetic operators and assignment of the value 0 to it, it 
> will work.  The only thing preventing it from working at the 
> moment is this line
>
>     struct Complex(T)  if (isFloatingPoint!T)
>
> So why do you need an appropriate application in order not to 
> have this arbitrary restriction?  Or have I missed something?
>
> It isn't just integer types.  Somebody might want to use 
> complex with a library (fixed-point, arbitrary precision, 
> decimal, etc.) numeric type.
>  Fractal generators, for example, are likely to use this a lot.
>
> Or even more exotically, use Complex!(Complex!real) to 
> implement hypercomplex numbers.
>
> Stewart.

Since I originally proposed this I should chime in again. My
use-case for non floating point, complex numbers is radar image
processing, where the radar intensity/phase are stored as complex
numbers which are quantized as 16-bit integer values.

Andrei suggested I come up with a proposal for non-FP complex,
but reading this thread, and my experience working with integer
valued complex values in C++ has now reversed my opinion.  I
think the current D requirement is good.

Just a small example, the norm() method calculates the squared
magnitude of the complex number (eg. you get a single real
value).  This is an operation that we use extensively in our
work.  This created problems with generating lots of NaN values
due to integer overflows, that were somewhat tricky to find.

I can imagine numerous issues like this popping up if using
integral values with complex numbers.