Oddity in ByteBuffer code?

Thread view:

Remon van Vliet - 19 May 2005 16:29 GMT

Hello,

A snippet from ByteBuffer.compareTo(), can anyone figure out what this code
does? :

if ((v1 != v1) && (v2 != v2)) // For float and double

Thanks, just curious,

Remon

Reply to this Message

Eric Sosman - 19 May 2005 16:46 GMT

> Hello,
>
> A snippet from ByteBuffer.compareTo(), can anyone figure out what this code
> does? :
>
> if ((v1 != v1) && (v2 != v2)) // For float and double

The test produces `true' if both v1 and v2 are NaN.

Signature

Eric.Sosman@sun.com

Reply to this Message

Patricia Shanahan - 19 May 2005 16:49 GMT

> Hello,
>
[quoted text clipped - 6 lines]
>
> Remon

It looks like a Not-a-Number test. NaNs do not compare equal
to anything, themselves included. However, sometimes it is
desirable to treat all NaNs as being equal to each other,
leading to tests for NaNs on both sides of a comparison.

If that is what is meant then

if (Double.isNaN(v1) && Double.isNaN(v2))

would be better style. It does the same test, but is
self-documenting.

The test does not seem to make sense in this context. I
don't see any way v1 or v2 could be double or float, and all
byte values compare equal to themselves. I think it may be a
case of over-enthusiastic copy-paste from DoubleBuffer,
which does need it.

Patricia

Reply to this Message

Chris Uppal - 19 May 2005 17:58 GMT

> The test does not seem to make sense in this context. I
> don't see any way v1 or v2 could be double or float, and all
> byte values compare equal to themselves. I think it may be a
> case of over-enthusiastic copy-paste from DoubleBuffer,
> which does need it.

Or, from the comment at the head of the 1.5 version of the source:

// -- This file was mechanically generated: Do not edit! -- //

a case of a tool being misapplied.

-- chris

Reply to this Message

Patricia Shanahan - 19 May 2005 20:09 GMT

>>> The test does not seem to make sense in this context. I
>>> don't see any way v1 or v2 could be double or float, and all
[quoted text clipped - 7 lines]
>
> a case of a tool being misapplied.

That makes the non-use of Double.isNaN even worse, because
there was premeditated intent to use the code in pure
integer contexts, where it is likely to be read by people
who might not instantly recognize the (v1 != v1) idiom.

Patricia

Reply to this Message

Chris Uppal - 20 May 2005 15:18 GMT

> That makes the non-use of Double.isNaN even worse, because
> there was premeditated intent to use the code in pure
> integer contexts, where it is likely to be read by people
> who might not instantly recognize the (v1 != v1) idiom.

And not even an explanatory comment ("For float and double" doesn't count as
explanatory in my book. It scarcely even counts as a comment -- even the
famous "you are not expected to understand this" would have been better ;-)

<sigh/> What is the world coming to...?

-- chris

Reply to this Message

Oddity in ByteBuffer code?

Free Magazines