[
https://issues.apache.org/jira/browse/LUCENE-7594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15751994#comment-15751994
]
Dawid Weiss commented on LUCENE-7594:
-------------------------------------
Ah, that is trappy... In a way it makes sense as -0.0f is 8000_0000 and min
value is 0000_0001, so if you disregard the sign bit there's some logic there.
Patch looks good. I don't know if the compiler will be smart enough to avoid
recomputing the static {{Float.floatToIntBits(-0f)}}. An alternative would be
to:
{code}
if (Float.compare(f, -0.0) == 0)
{code}
or simply compare the int representation (Float.toIntBits(f) == 0x8000_0000).
Either way, looks good to me.
> Float/DoublePoint should not recommend using Math.nextUp/nextDown for
> exclusive ranges
> --------------------------------------------------------------------------------------
>
> Key: LUCENE-7594
> URL: https://issues.apache.org/jira/browse/LUCENE-7594
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Adrien Grand
> Priority: Minor
> Attachments: LUCENE-7594.patch
>
>
> Float/Double points are supposed to be consistent with Double/Float.compare,
> so +0 is supposed to compare greater than -0. However Math.nextUp/nextDown is
> not consistent with Double/Float.compare and returns MIN_VALUE for nextUp(-0).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
