Complex number functions for std.math

[Norbert Nemec]

Anders F Björklund wrote:
> Norbert Nemec wrote:
> 
>> That discussion was before my time and obviously nobody back
>> then had strong feelings against talking about "really complex numbers".
> 
> 
> Walter didn't like the "extended" keyword, so he renamed it "real":
> http://www.digitalmars.com/d/changelog.html#new054 [DMD 0.54, 2003]

That's interesting! This was nearly one year before I seriously got in
contact with D for the first time. I remember that the "creal/ireal"
names offended me right away when I read the specification. I wrote a
message about it to the newsgroup and people started discussing about
the type naming in all directions, but there didn't seem to be anybody
who even understood the irony of "complex real" and "imaginary real"
numbers.

> Several people hated "imaginary real" and "complex real", though ?
> But I guess they left and never came back, or something like that.

It really seems that people with mathematical background really either
left of gave up on the issue back then.

>> Therefore the final word still is: "Do in the library whatever you want,
>> the language definition will not be changed again."
> 
> That's my understanding as well, with the 64-128 bit floating type.
> I'd rather have the basic D types be of a fixed size, but that's me.

Exactly my opinion: The basic types should have well-defined bit-sizes
and be portable across architectures.

The best names for a floating point types with fixed bit size are type
names that have the bit-size incorporated: float32, float64, float80 and
so on. Correspondingly there would be ifloat32, ifloat64 and ifloat80.
For complex numbers, the naming is not obvious, but I would go for
cfloat32 for a complex float made up of two float32 numbers.

Any library interfacing C code would then probably define
	alias float32 float;
	alias float64 double;

The standard library should then pre-define the precious type names
"real", "complex" and "imaginary" to some reasonable default, that may
be architecture dependent and can easily be changed. The regular user
should be encouraged to use these aliases without depending on a fixed
size. This will result in code that can easily be compiled with a
different precision or moved inside a template library where "real"
becomes a parameter.

This would solve several problems:

* currently, there is no type name for 80-bit floats

* the current naming scheme has no obvious extension towards 16-bit,
128-bit or other bit-size floating point numbers.

* the current definition of "real" is dangerous:
"largest hardware implemented floating point size"
If you implemented D on some future architecture that supports 1024-bit
floats in hardware, "real" would have a float1024, even if the high
data-rate makes this a very bad general choice.

* the mechanism that determines the size of "real" is not clear at all.
It may be hard-wired in the compiler or there may be a compiler-switch
which is different for every implementations. Using plain aliases, the
mechanism is completely transparent any can use the full flexibility of
conditional compilation.

* The ridiculous concept of "really complex numbers" and "irreal"
numbers is finally off the table and D can stop being ashamed in view of
the seriously mathematical world.

Greetings,
Norbert