Eigenpoll : D wish list : Precise names for floats 

The current names of floating point types have several problems:

* there is no definite type name for 80-bit floats. "real" *may* have 80 bits, but it may be something different as well.

* the 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 exotic architecture that supports floats up to 1024-bit in hardware, "real" would have to have 1024 bits, even though that may be very inefficient in general.

* 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 then different for every implementation. Using plain aliases, the mechanism could completely transparent any can use the full flexibility of
conditional compilation.

* The names "creal" ("really complex numbers"??) and "ireal" (misspelling of "irreal"??!!) are a offense to anybody with a serious mathematical background.

Alternative suggestion:

a) Have basic types defined by the language that unmistakably show that they have definite bit-size: float16, float32, float64, float80 and float128. The existance of some of these types in an implementation may be optional, but you know that *if* they exist, they have a definite size.

b) Introduce types ifloat16, ifloat32, ifloat64, ifloat80 and ifloat128 with the obvious meaning

c) Introduce cfloat32 et al. where cfloat32 is a complex number made up of two float32 values, so cfloat32 has 64 bits. (This decision is non-obvious, but the decision has to be done in one way or the other. In the end it is a matter of taste.)

d) Define two fixed aliases for C lovers in the standard library:
alias float32 float;
alias float64 double;

e) Define the precious names "real", "complex" and "imaginary" as aliases to some reasonable, architecture dependent default. Encourange users to just use these names unless they have specific needs for the bit-size.

f) leave it open to anyone to define "real", "complex" and "imaginary" differently for their code if they need to. Any code that does not explicitely define these names should work portably for arbitrary precision.


Report this item for cleanup