Thread overview
DOC: undefined type of idouble + double
Mar 02, 2006
Thomas Kuehne
Mar 02, 2006
Don Clugston
Mar 03, 2006
Thomas Kuehne
Mar 07, 2006
Don Clugston
March 02, 2006
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.

Thomas


March 02, 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.
March 03, 2006
Don Clugston schrieb am 2006-03-02:
> Thomas Kuehne wrote:
>> 
>> 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.

Exactly what would be the problems besides implementation bugs?

> 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));
> }

[snip]

Added to DStress as: http://dstress.kuehne.cn/run/c/cdouble_07_A.d http://dstress.kuehne.cn/run/c/cdouble_07_B.d http://dstress.kuehne.cn/run/c/cdouble_07_C.d http://dstress.kuehne.cn/run/c/cdouble_07_D.d http://dstress.kuehne.cn/run/c/cdouble_08_A.d http://dstress.kuehne.cn/run/c/cdouble_08_B.d http://dstress.kuehne.cn/run/c/cdouble_08_C.d http://dstress.kuehne.cn/run/c/cdouble_08_D.d http://dstress.kuehne.cn/run/c/cdouble_09_A.d http://dstress.kuehne.cn/run/c/cdouble_09_B.d http://dstress.kuehne.cn/run/c/cdouble_09_C.d http://dstress.kuehne.cn/run/c/cdouble_09_D.d http://dstress.kuehne.cn/run/c/cfloat_07_A.d http://dstress.kuehne.cn/run/c/cfloat_07_B.d http://dstress.kuehne.cn/run/c/cfloat_07_C.d http://dstress.kuehne.cn/run/c/cfloat_07_D.d http://dstress.kuehne.cn/run/c/cfloat_08_A.d http://dstress.kuehne.cn/run/c/cfloat_08_B.d http://dstress.kuehne.cn/run/c/cfloat_08_C.d http://dstress.kuehne.cn/run/c/cfloat_08_D.d http://dstress.kuehne.cn/run/c/cfloat_09_A.d http://dstress.kuehne.cn/run/c/cfloat_09_B.d http://dstress.kuehne.cn/run/c/cfloat_09_C.d http://dstress.kuehne.cn/run/c/cfloat_09_D.d http://dstress.kuehne.cn/run/c/creal_32_A.d http://dstress.kuehne.cn/run/c/creal_32_B.d http://dstress.kuehne.cn/run/c/creal_32_C.d http://dstress.kuehne.cn/run/c/creal_32_D.d http://dstress.kuehne.cn/run/c/creal_33_A.d http://dstress.kuehne.cn/run/c/creal_33_B.d http://dstress.kuehne.cn/run/c/creal_33_C.d http://dstress.kuehne.cn/run/c/creal_33_D.d http://dstress.kuehne.cn/run/c/creal_34_A.d http://dstress.kuehne.cn/run/c/creal_34_B.d http://dstress.kuehne.cn/run/c/creal_34_C.d http://dstress.kuehne.cn/run/c/creal_34_D.d

Thomas


March 07, 2006
Thomas Kuehne wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Don Clugston schrieb am 2006-03-02:
>> Thomas Kuehne wrote:
>>> 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 does not have to involve implicit promotion to complex. In fact, it can't, because then you get problems with the sign of zero.
> 
> Exactly what would be the problems besides implementation bugs?

The problem is that
-0.0 + 0.0 = -0.0
+0.0 - 0.0 = +0.0

So if you always promote imaginary numbers by adding +0.0,
then you get
-0.0 + 7.0i  = creal (-0.0 + 7.0i)
but
7.0i - 0.0  = creal (+0.0 + 7.0i)