Complex number functions for std.math

[Don Clugston]

Norbert Nemec wrote:
> Don Clugston wrote:
>> It is a bit of an oxymoron. I do like the idea of having 'complex' as a
>> standard alias in std.math. It should operate almost as a reserved word,
>> users should not be defining it to be anything other than creal.
>> But I would not like to have to type "imaginary" instead of "ireal" --
>> it's just too long. Any ideas on that one?
> 
> It would not be a problem that "imaginary" is such a long word: this
> type is hardly ever used when coding. Maybe in special places inside a
> library, but I cannot imagine any user-code that actually needs to
> declare a variable of that type. Either you code real or complex, but
> coding purely imaginary is pointless.

You've convinced me. Having just done functions for pure imaginary 
arguments I have a very warped perspective right now. It's a very 
annoying type to work with -- it's not closed under basic arithmetic 
operations. And probably, most of the remaining uses of it are covered 
by automatic type inference.
eg.
const I = 1i;
instead of
const imaginary I = 1i;

>> FWIW, the name "imaginary" is a bit stupid, too. In what sense is a
>> negative "real" number more "real" than an "imaginary" number? Arguably,
>> D is just continuing the trend of inappropriate names <g>.
> 
> Well, I tend to think about redefining nonsensical conventions myself. I
> just hate it when *others* do it. :-)
> 
> Seriously: communications is never about using the "right" term, but
> always about using a term that people understand most easily. And the
> best way to handle stupid conventions: don't change them unless you
> already are an unquestioned guru in the field.

And do your best to avoid creating them, regardless of whether you are 
an unquestioned guru in the field.

I think we could easily amass a lobby group of 100% of the users of 
complex numbers in D to have a 'complex' alias set up in math.d. And 
gradually phase out use of creal (which I think would be better named 
cfloat80 or similar -- make the underlying type itself be of fixed size).