Bug 8530 – Float types default initializers doesn't work in class

Created attachment 1136 problematic code When I create class with some float variable without value, then call some method on this class and test float variable for default value, it doesnt work. My code is in in attachment

If you want to check for NaN, then use std.math.isNaN. As I understand it, there is no guarantee that two NaN values have the same bit pattern (at minimum, you have signed and unsigned NaN, and there may be more variations - I don't remember). isNaN returns true in both cases. So, I don't believe that this is a bug.

(In reply to comment #1) > If you want to check for NaN, then use std.math.isNaN. As I understand it, > there is no guarantee that two NaN values have the same bit pattern (at > minimum, you have signed and unsigned NaN, and there may be more variations - I > don't remember). isNaN returns true in both cases. So, I don't believe that > this is a bug. Thanks for your reply. However I still think it is a bug, because when I assign TYPE.init to variable VAR of type TYPE, and then I compare VAR is TYPE.init, I assumed it returns true;

(In reply to comment #2) > (In reply to comment #1) > > If you want to check for NaN, then use std.math.isNaN. As I understand it, > > there is no guarantee that two NaN values have the same bit pattern (at > > minimum, you have signed and unsigned NaN, and there may be more variations - I > > don't remember). isNaN returns true in both cases. So, I don't believe that > > this is a bug. > > Thanks for your reply. However I still think it is a bug, because when I assign > TYPE.init to variable VAR of type TYPE, and then I compare VAR is TYPE.init, I > assumed it returns true; Your assumption is not correct. If type.init is a signalling NaN, the bit pattern changes when you access it. It has nothing to do with classes. More generally, x = y; assert (x is y); Fails if x is floating point and y is a signalling NaN. When reading from x, the 'quiet' bit of will be set, so that it reads a quiet NaN, not a signalling one. That's the way the hardware works, the same behaviour applies in any language that uses the hardware.

(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > If you want to check for NaN, then use std.math.isNaN. As I understand it, > > > there is no guarantee that two NaN values have the same bit pattern (at > > > minimum, you have signed and unsigned NaN, and there may be more variations - I > > > don't remember). isNaN returns true in both cases. So, I don't believe that > > > this is a bug. > > > > Thanks for your reply. However I still think it is a bug, because when I assign > > TYPE.init to variable VAR of type TYPE, and then I compare VAR is TYPE.init, I > > assumed it returns true; > > Your assumption is not correct. If type.init is a signalling NaN, the bit > pattern changes when you access it. It has nothing to do with classes. > > More generally, > > x = y; > assert (x is y); > > Fails if x is floating point and y is a signalling NaN. > When reading from x, the 'quiet' bit of will be set, so that it reads a quiet > NaN, not a signalling one. > That's the way the hardware works, the same behaviour applies in any language > that uses the hardware. OK, but still I dont understand why others compilers(LDC,GDC) works as I expect and why real type in DMD behave different.

(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > (In reply to comment #1) > > > > If you want to check for NaN, then use std.math.isNaN. As I understand it, > > > > there is no guarantee that two NaN values have the same bit pattern (at > > > > minimum, you have signed and unsigned NaN, and there may be more variations - I > > > > don't remember). isNaN returns true in both cases. So, I don't believe that > > > > this is a bug. > > > > > > Thanks for your reply. However I still think it is a bug, because when I assign > > > TYPE.init to variable VAR of type TYPE, and then I compare VAR is TYPE.init, I > > > assumed it returns true; > > > > Your assumption is not correct. If type.init is a signalling NaN, the bit > > pattern changes when you access it. It has nothing to do with classes. > > > > More generally, > > > > x = y; > > assert (x is y); > > > > Fails if x is floating point and y is a signalling NaN. > > When reading from x, the 'quiet' bit of will be set, so that it reads a quiet > > NaN, not a signalling one. > > That's the way the hardware works, the same behaviour applies in any language > > that uses the hardware. > > OK, but still I dont understand why others compilers(LDC,GDC) works as I expect > and why real type in DMD behave different. GDC calls memcmp() between the two floating values - dunno what DMD does... Regards Iain

*** This issue has been marked as a duplicate of issue 3632 ***