[
https://issues.apache.org/jira/browse/LUCENE-1649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987551#action_12987551
]
Doron Cohen commented on LUCENE-1649:
-------------------------------------
I think the creator of this refers to the [precision
loss|http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#25214]
caused in IntFieldSource.floatVal(doc) when a large int is "widened" to float,
but unfortunately not the same.
The problem then materializes in app code when the score of that doc is used as
a key for accessing e.g. a DB.
So problem is real, for such app, but not sure it should be fixed, because
relying on a float score for accessing something by discrete int key seems a
wrong design, - fetching that key from a payload seems a better approach.
Anyway, long time, no patch, good to go to sleep until there is one.
> numerical problem associated with CustomScoreQuery, ValueSourceQuery
> --------------------------------------------------------------------
>
> Key: LUCENE-1649
> URL: https://issues.apache.org/jira/browse/LUCENE-1649
> Project: Lucene - Java
> Issue Type: Bug
> Components: Search
> Affects Versions: 2.4.1
> Environment: OpenSuse 10.3 32bit kernel , JDK 1.6.0_13, Pentium D
> 3.2GHz
> Reporter: alex
>
> float type computation used in subclasses of FieldCacheSource
> ,ValueSourceQuery , will cause numerical error when moderately large int
> values were supplied in a field.
> For example, consider a document with a field parsable as integer with the
> value 24118569
> During scoring, a cast will be performed like so, (float) 24118569, in order
> to get the float representation of the field.
> In this case the value is turned into 24118568.0. If this value is then used
> to lookup a database the result will be incorrect even if we
> cast it back to an integer.
> my temporal resolution to this problem is by attaching the int[] array from
> lucene's internal cache to the query object through reflection,
> and perform the value lookup myself with docid. Clearly , this is not optimal
> .
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
