When working with ``++float++`` or ``++double++`` primitive types, it may be required to deal with ``++NaN++`` (Not a Number) values. When tested against itself, ``++NaN++`` will always answer ``++false++`` as long as the primitive wrapper type is not used. When the wrapper is used, it will always be ``++true++``. This property is illustrated in the code snipped below.
In order to remove any ambiguity, this rule raises an issue every time an equality test is used with ``++double++``, ``++Double++``, ``++float++`` or ``++Float++``, when both sides of the test are the same variable. The ``++isNaN(...)++`` methods from ``++Double++`` and ``++Float++`` should be preferred.
\[~michael.gumowski] this rule duplicates RSPEC-2688. Make it a subtask?
=== on 31 Jan 2018, 16:57:46 Michael Gumowski wrote:
Arf, I missed that when I searched for ``++NaN++`` in RSPEC... Thanks for noticing it [~ann.campbell.2]. It's indeed a duplicate, but to me RSPEC-2688 is not that good as an explanation. What do you mean by making it a subtask? replacing the existing subtask?
=== on 31 Jan 2018, 17:23:05 Ann Campbell wrote:
\[~michael.gumowski] the main task talks about using a ``++NaN++``-testing function, which is what this rule also talks about. So yes, replacing the subtask makes sense to me, particularly if you don't like the suggested remediation in the existing subtask.
=== on 1 Feb 2018, 08:42:17 Michael Gumowski wrote:
\[~ann.campbell.2] Ok, so let's make it a subtask. Can you take charge of it? I'm not sure what to do with the previous one.
=== on 1 Feb 2018, 16:34:48 Ann Campbell wrote:
Done [~michael.gumowski]
=== on 2 Feb 2018, 08:08:30 Michael Gumowski wrote: