www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 8530] New: Float types default initializers doesn't work in class

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8530

           Summary: Float types default initializers doesn't work in class
           Product: D
           Version: D2
          Platform: x86_64
        OS/Version: Linux
            Status: NEW
          Severity: major
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: kozzi11 gmail.com


--- Comment #0 from Daniel Kozak <kozzi11 gmail.com> 2012-08-10 02:27:21 PDT ---
Created an attachment (id=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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 10 2012
next sibling parent reply "Daniel Kozak" <kozzi11 gmail.com> writes:
On Friday, 10 August 2012 at 09:27:25 UTC, Daniel Kozak wrote:

 http://d.puremagic.com/issues/show_bug.cgi?id=8530

            Summary: Float types default initializers doesn't 
 work in class
            Product: D
            Version: D2
           Platform: x86_64
         OS/Version: Linux
             Status: NEW
           Severity: major
           Priority: P2
          Component: DMD
         AssignedTo: nobody puremagic.com
         ReportedBy: kozzi11 gmail.com


 --- Comment #0 from Daniel Kozak <kozzi11 gmail.com> 2012-08-10 
 02:27:21 PDT ---
 Created an attachment (id=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


Problematic code:
-----------------------------------------------------------
module main;

import std.stdio;

class A {
	private float floatInClass;
	
	public void tryfloatInitValue() {
		float floatInLocalScope;
		
		if (floatInClass is float.init) {
			writeln("floatInClass OK");
		} else {
			writeln("floatInClass ERR");
		}
		
		if (floatInLocalScope is float.init) {
			writeln("floatInLocalScope OK");
		} else {
			writeln("floatInLocalScope ERR");
		}
	}
}

void main(string[] args)
{
	A smth = new A();
	smth.tryfloatInitValue();
}

----------------------------------------------------------
Same for double, but for real type it is ok
Aug 10 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/10/2012 2:30 AM, Daniel Kozak wrote:

 Problematic code:


Replying to bug reports in the newsgroup generally means your reply will be 
overlooked. Please reply on bugzilla.
Aug 10 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8530


Jonathan M Davis <jmdavisProg gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg gmx.com


--- Comment #1 from Jonathan M Davis <jmdavisProg gmx.com> 2012-08-10 03:00:35
PDT ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 10 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8530



--- Comment #2 from Daniel Kozak <kozzi11 gmail.com> 2012-08-10 03:19:42 PDT ---
(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;

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 10 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8530


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug yahoo.com.au


--- Comment #3 from Don <clugdbug yahoo.com.au> 2012-08-15 06:23:41 PDT ---
(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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 15 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8530



--- Comment #4 from Daniel Kozak <kozzi11 gmail.com> 2012-08-15 07:29:25 PDT ---
(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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 15 2012
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8530


Iain Buclaw <ibuclaw ubuntu.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ibuclaw ubuntu.com


--- Comment #5 from Iain Buclaw <ibuclaw ubuntu.com> 2012-08-15 08:09:25 PDT ---
(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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 15 2012