DOC: undefined type of idouble + double

Don Clugston dac at nospam.com.au
Thu Mar 2 01:06:00 PST 2006


Thomas Kuehne wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> http://www.digitalmars.com/d/type.html
> "Usual Arithmetic Conversions" doesn't list any of the following
> conversions:
> 
> float -> cfloat
> ifloat -> cfloat
> double -> cdouble
> idouble -> cdouble
> real -> creal
> ireal -> creal
> 
> http://www.digitalmars.com/d/float.html
> "Complex and Imaginary types" documents the conversions above:
>> There is no particular complex literal syntax, just add a real and
>> imaginary type.
> 
> DMD-0.148 allows the promotion to complex types.

It does, but it shouldn't.
Adding a real and an imaginary type to form a complex is does not have 
to involve implicit promotion to complex. In fact, it can't, because 
then you get problems with the sign of zero. You need to treat "real op 
ireal" as a special case, which return a creal. Such bugs exist 
currently with constant folding of complex numbers.

import std.math;
import std.stdio;

void main()
{
     real n = -0.0;          // OK
     const real m = -0.0;    // OK

     creal c = -0.0 + 3i;   // BUG: this is +0.0 + 3i
     creal d = n + 3i;      // OK:  this is -0.0 + 3i
     creal e = m + 3i;      // BUG: this is +0.0 + 3i

     // should print "11111" actually prints "11010".
     writefln(signbit(n), signbit(m),
	signbit(c.re), signbit(d.re), signbit(e.re));
}

I've argued previously that these promotions are a mistake; they mean 
that it's impossible to provide overloads of a function for real and 
creal types. Once you have both a real and a creal version, you must 
create all the other ones.
eg if you have
real sin(real x)
creal sin(creal z)
you now have to provide sin(double x), sin(float x), otherwise something
as simple as
sin(0.5)
will no longer compile. When multiple parameters are involved, the 
situation rapidly worsens.
It would be OK if float-> real was tried before float->creal, but the 
simple lookup rules don't allow that. So it's better to entirely prevent 
conversion from non-complex to complex types.



More information about the Digitalmars-d-bugs mailing list