Complex number functions for std.math

[Dave]

Norbert Nemec wrote:
> Anders F Björklund wrote:
>>> Exactly my opinion: The basic types should have well-defined bit-sizes
>>> and be portable across architectures.
>> It could just be a side-effect of DMD only targetting one architecture ?
> 
> That certainly is the core of the issue. The D specification contains a
> bit of theoretical talk about portability, but effectively the language
> is an x86-only language only.
> 

Hrm, that's a little strong: http://home.earthlink.net/~dvdfrdmn/d/

GDC's been running on AIX and non-intel Mac for a while now. IIRC, 
elsewhere there has been a working port for HPUX as well.

The bottom line is that 'i/c/real' are the only native types where the 
size is not specified by the language, but by the underlying hardware. 
This is a big improvement for portability over C/++. According to the 
rationale, the 'real' type is to encourage programmers to use the max. 
hardware precision available for fp operations and port things that way.

Let's not over-guru things here:
- float and double are widely understood as 32 bit and 64 bit for a 
C-lineage language.
- There seems to be little complaint about i/c/float and i/c/double as well.
- The big complaint is from numerics programmers who don't like the 
irony of ireal and creal. *Just change those to be 'imag' and 'comp'*.
- Walter understandably doesn't want to change the spec. for every 
floating point type, but this would be a change involving just two of 
them that we hear constant complaints about and are not yet used 
ubiquitously.
- If it breaks your code, you can simply alias the old creal and ireal 
types until you get time to change it.

So you have:

float
ifloat
cfloat

double
idouble
cdouble

real
imag
comp

If Walter would handle the compiler end of things, I would be glad to 
grep the phobos math libs. and docs. to make the changes there.

Besides getting rid of ireal and creal, imag and comp are short yet 
descriptive to those who would most likely use them. They will not 
confuse newbies or make the type system any harder to understand. And 
they imply a type that is 'native' to the machine like 'real' does 
because they don't have any connotations of absolute size.

Let's face it, there is no way Walter is going to again change the base 
fp types (float, double, real). And speaking from the point of view of a 
humble user who may want to use yet-to-be-built math libraries sometime, 
I would immediately search for an alternative for a D math library built 
with aliased types because that would just be one more inconsistency, 
another thing to learn and remember, and more to concern myself with for 
porting.

- Dave