Complex number functions for std.math

[Anders F Björklund]

Norbert Nemec wrote:

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

It could just be a side-effect of DMD only targetting one architecture ?

The real type is 80 bits in register on all the supported platforms, it
just varies in size when stored to mem/disk (80 on Windows, 96 on Linux,
and will probably increase to 128 bit when 64-bit Linux is supported ?)
Usually it just follows the platform definition of "long double", for C.

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

I had a similar suggestion, but the other way around... Keep the
current type names, and added the bitsizenames as aliases instead.
(my original post had names similar to stdint, such as float32_t)

I thought including the bit size in the name made it a bit harder to
read and more unattractive, quite similar to the case with integers ?
(i.e. naming those types as int8, int16, int32, int64, int128 instead)


But I haven't heard anything suggesting that "real" will ever change...
As far as I know, that part of the D specification is already decided.

--anders