std.complex

[Joseph Rushton Wakeling]

On Wednesday, 1 January 2014 at 23:32:58 UTC, Lars T. Kyllingstad 
wrote:
> I'm not 100% convinced that a pure imaginary type is the way to 
> go.  You may be interested in reading a previous discussion, 
> where the subject of pure imaginary number support is brought 
> up:
>
>   http://forum.dlang.org/thread/flsf9u$jf$1@digitalmars.com

I have read through that thread already, but thank you for 
bringing it up -- it raises some issues that deserve an answer.

My own thoughts on the matter go something like this:

    * 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.

    * The idea of allowing imaginary literals but promoting them 
to complex when
      written to a variable sounds attractive but we can't 
discount the
      possibility that people will want to pass imaginary literals 
to functions
      or otherwise store them in variables, and later use them; if 
they are
      promoted to complex, calculations done with them may have 
lesser precision
      or even generate the aforementioned spurious results. I 
don't think simply
      writing to a variable should cause loss of precision like 
this.

    * 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.

    * The lack of closure under various operations is annoying but 
not
      insurmountable.

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.

Of course, an alternative would be to tweak the internals of 
Complex so that it can represent "purely real" and "purely 
imaginary" types precisely.

I'm writing from a phone now so it's not really convenient to 
explain at length, but I'll try to expand on the above in the 
next days.