www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - DOC: undefined type of idouble + double

reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----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. Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFEBqs03w+/yD4P9tIRAmmXAKCdr6HhltusbNlcIbsRPRKOy2HFJACfVFov 8/m2InRl20RWcepSFqBDmxo= =hLk9 -----END PGP SIGNATURE-----
Mar 02 2006
parent reply Don Clugston <dac nospam.com.au> writes:
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.
Mar 02 2006
parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----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 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 -----BEGIN PGP SIGNATURE----- iD8DBQFECIqi3w+/yD4P9tIRArngAKCVkIEATUoEcgB2+dTVCGqT9dFk+wCfbclY D19Yynu7phu9V6DT9p8ErvE= =U0aw -----END PGP SIGNATURE-----
Mar 03 2006
parent Don Clugston <dac nospam.com.au> writes:
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.


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)
Mar 07 2006