std.complex

[Lars T. Kyllingstad]

On Thursday, 2 January 2014 at 01:17:54 UTC, Joseph Rushton 
Wakeling wrote:
>    * There are calculations involving "pair of reals" 
> implementations of complex
>      numbers that generate spuriously incorrect results. 
> They're corner cases,
>      but they exist.
>
>    * A purely imaginary type allows those calculations to be 
> performed
>      correctly. It also allows more precise calculations in 
> general for cases
>      where the real part of a complex number is known to be 0.

So we have three choices:

1. We add a dedicated Imaginary type, and leave Complex more or 
less the way it is. The pros are that it provides a way to 
represent imaginary numbers "correctly", while keeping Complex 
simple and performant. The cons are that Complex still gives 
wrong (or at least somewhat unexpected) results in the 
aforementioned corner cases, and that we add a new type with 
extremely limited usability.

2. Special-case Complex for imaginary numbers. The pros are that 
it solves the problems Imaginary was intended to solve, and we 
don't need a new type. The cons are that the Complex 
implementation becomes more complex (haha) and less performant, 
and that we actually change the semantics of IEEE floating-point 
"zero" somewhat.

3. Leave std.complex as-is, and make sure people know what the 
problematic cases are.

They all suck. I don't know what is the lesser of three evils 
here, but I too am starting to lean towards 1.  I'm probably 
going to continue playing devil's advocate, though. ;)


>    * You can do calculations involving purely real-valued 
> numbers and complex
>      numbers and not run into the same issues, because purely 
> real values are
>      supported. So you should be able to do the same with 
> purely imaginary
>      numbers.

That argument is fallacious. Imaginary numbers are quite 
different from real numbers.


> I should add that as far as I'm concerned what I want is simply 
> to find the best possible way to represent and use purely 
> imaginary numbers in D. I don't mind if, having done that, the 
> code winds up being rejected, as long as the exercise proves 
> useful.

I think it's great that you're doing this. :)