Mailing-List: contact users-help@groovy.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@groovy.incubator.apache.org
DomainKey-Signature: a=rsa-sha1; s=emp2q2010; d=windstream.com; c=nofws;
 q=dns;
	h=dkim-signature:from:to:subject:date:message-id:
	accept-language:content-language:x-ms-has-attach:x-originating-ip:
	x-proofpoint-virus-version:x-proofpoint-spam-details;
	b=Oe9Y6UtemwBD+YrUiT2MpY/96CoPxXPXD1qj0Fbjea2TEUrdcZNfZhoBz8ZtqdzBm
	ZhkCkdNl5nxLTPQbryCmenZvPbm2fmpZbycwBgZcHpB9ZPcGXaHJct9WcDme3ZjsyQf
	wjNO5QKwuXzbQGOtNO5HdADm3FOwQDd0d/eoF0w=
From: "Winnebeck, Jason" <Jason.Winnebeck@windstream.com>
To: "users@groovy.incubator.apache.org" <users@groovy.incubator.apache.org>
Subject: Is NaN ==/!= NaN guaranteed to be consistent in all Groovy versions?
Thread-Topic: Is NaN ==/!= NaN guaranteed to be consistent in all Groovy
 versions?
Thread-Index: AdD0d+DDbzYoH0UGQnCg3P1Nk/EBWA==
Date: Mon, 21 Sep 2015 14:14:50 +0000
Message-ID: <5C676E6359909E478C7B811BDB48CA35415C65@CWWAPP478.windstream.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_5C676E6359909E478C7B811BDB48CA35415C65CWWAPP478windstre_"
MIME-Version: 1.0

--_000_5C676E6359909E478C7B811BDB48CA35415C65CWWAPP478windstre_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I see in Groovy that =3D=3D and !=3D work to compare variables against NaN.=
 The rationale seems to be that compareTo is used instead of primitive comp=
arisons or equals. Is this behavior guaranteed to be defined this way in al=
l future versions of Groovy?

I've come across some Groovy code that is doing "x !=3D Float.NaN" and in a=
ll of the test cases it seems to work. I ask because I'm afraid of primopts=
 or static compiler in the future perhaps replacing the float to float comp=
arison with a primitive !=3D, which returns false always in Java, but if th=
is is a locked in behavior for Groovy, then I won't worry about refactoring=
 existing code.

I see that https://issues.apache.org/jira/browse/GROOVY-3309 addresses this=
 and Jochen responded to it but it was left open instead of closed as "won'=
t fix", which concerns me that Groovy team may introduce a breaking change =
in the future.

Jason

----------------------------------------------------------------------
This email message and any attachments are for the sole use of the intended=
 recipient(s). Any unauthorized review, use, disclosure or distribution is =
prohibited. If you are not the intended recipient, please contact the sende=
r by reply email and destroy all copies of the original message and any att=
achments.

--_000_5C676E6359909E478C7B811BDB48CA35415C65CWWAPP478windstre_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii">
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">I see in Groovy that =3D=3D and !=3D work to compare=
 variables against NaN. The rationale seems to be that compareTo is used in=
stead of primitive comparisons or equals. Is this behavior guaranteed to be=
 defined this way in all future versions
 of Groovy?<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I&#8217;ve come across some Groovy code that is doin=
g &#8220;x !=3D Float.NaN&#8221; and in all of the test cases it seems to w=
ork. I ask because I&#8217;m afraid of primopts or static compiler in the f=
uture perhaps replacing the float to float comparison with a
 primitive !=3D, which returns false always in Java, but if this is a locke=
d in behavior for Groovy, then I won&#8217;t worry about refactoring existi=
ng code.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I see that <a href=3D"https://issues.apache.org/jira=
/browse/GROOVY-3309">
https://issues.apache.org/jira/browse/GROOVY-3309</a> addresses this and Jo=
chen responded to it but it was left open instead of closed as &#8220;won&#=
8217;t fix&#8221;, which concerns me that Groovy team may introduce a break=
ing change in the future.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Jason<o:p></o:p></p>
</div>

<HR>This email message and any attachments are for the sole use of the inte=
nded recipient(s). Any unauthorized review, use, disclosure or distribution=
 is prohibited. If you are not the intended recipient, please contact the s=
ender by reply email and destroy all copies of the original message and any=
 attachments.<BR>
</body>
</html>

--_000_5C676E6359909E478C7B811BDB48CA35415C65CWWAPP478windstre_--