Complex number functions for std.math

[Norbert Nemec]

B.t.w: just added this point to the "unofficial wishlist":
	http://all-technology.com/eigenpolls/dwishlist/index.php
under the name "Precise names for floats"

Please vote for it if you think it is important.



Norbert Nemec wrote:
> 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