digitalmars.D.bugs - DOC: undefined type of idouble + double
- Thomas Kuehne (20/22) Mar 02 2006 -----BEGIN PGP SIGNED MESSAGE-----
- Don Clugston (35/55) Mar 02 2006 It does, but it shouldn't.
- Thomas Kuehne (48/87) Mar 03 2006 -----BEGIN PGP SIGNED MESSAGE-----
- Don Clugston (9/36) Mar 07 2006 The problem is that
-----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
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: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.There is no particular complex literal syntax, just add a real and imaginary type.DMD-0.148 allows the promotion to complex types.
Mar 02 2006
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Don Clugston schrieb am 2006-03-02:Thomas Kuehne wrote:Exactly what would be the problems besides implementation bugs?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: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.There is no particular complex literal syntax, just add a real and imaginary type.DMD-0.148 allows the promotion to complex types.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
Don Clugston <dac nospam.com.au> Thomas Kuehne wrote:-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Don Clugston schrieb am 2006-03-02: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)Thomas Kuehne wrote:Exactly what would be the problems besides implementation bugs?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: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.There is no particular complex literal syntax, just add a real and imaginary type.DMD-0.148 allows the promotion to complex types.
Mar 07 2006