Complex number functions for std.math

[Anders F Björklund]

Norbert Nemec wrote:

>> 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)
> 
> That means trying to build something well-defined on top of shaky ground
> which is exactly what causes the huge mess of C/C++-build systems like
> "automake" and "autoconf". The build system has to do a number of tests
> to find out what the implementation-dependend things are on a given
> system to define portable types. This is just the thing I believed D was
> supposed to solve.

AFAIK, the only D things undecided are the size of a real and the param
format of a dynamic array. At least those are the ones I've run into...

Size of the other types should be pretty constant ? Even size of a bool.
Already had stdint aliases for integers, so I thought about "stdfloat".

I dropped the idea, since it's not as common to need to set the size of
a float/double in bits, as compared to when using short/long int types.


The D number types are also the same as in Java, which is another plus.
(D adds the unsigned and imaginary/complex variants, which is a bonus)

I renamed real into "extended" here, and just treat "real" as an alias.
But usually I just use float and double, to keep the code portable...


>> 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)
> 
> Harder to read? That's exactly what aliases should be used for. The
> names including bit sizes are precise, well defined and to the point,
> which is the best ground to build something on top

I've been doing some coding with Mac's C types, which include the bit
size, and it's not *that* bad in practice actually. Just a bit strange:

     typedef unsigned char           UInt8;
     typedef signed char             SInt8;
     typedef unsigned short          UInt16;
     typedef signed short            SInt16;
     typedef unsigned long           UInt32;
     typedef signed long             SInt32;
     typedef uint64_t		    UInt64;
     typedef int64_t		    SInt64;
     typedef float                   Float32;
     typedef double                  Float64;

But when writing regular ANSI C code, using things like "int" or "float"
just feels more readable (to me) than using e.g. "SInt32" or "Float32" ?


So I don't think there are too many problems with all the old "regular"
types, it's just the "real" type that I'm having some minor issues with.

And like suggested, it's easy enough to add a few "alias" and live with.
(I'm going to continue to call the X87 80-bit type "extended", I think)

--anders