[
https://issues.apache.org/jira/browse/SOLR-16361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17606612#comment-17606612
]
Jason Gerlowski commented on SOLR-16361:
----------------------------------------
Hey [~epugh] thanks for grabbing this and thanks [~rosher] for the PR; it'd
been on my review list but I stalled out trying to get to the bottom of a
question I had about how func-queries work. I never figured out the answer, so
I'm gonna ask here in case that gets the Q a few extra eyes:
The math operations in our function queries cast to 'float' pretty
consistently: 'sum', 'sub', 'pow' are all float-based operations. Is there a
reason we used 'float' here? If not, should we switch over to 'double' more
broadly, and not just for 'mod'?
> 'mod' function query casts to float, returns wrong modulus for large ints
> -------------------------------------------------------------------------
>
> Key: SOLR-16361
> URL: https://issues.apache.org/jira/browse/SOLR-16361
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: search
> Affects Versions: 9.0
> Reporter: Dan Rosher
> Assignee: Eric Pugh
> Priority: Major
> Fix For: 9.1, main (10.0)
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> mod function query uses DualFloatFunction. This eventualy does a conversion
> {code:java}
> (float)value {code}
> converting an integer (32bit) into a float which has a 24bit mantissa
> ,resulting in a loss of precision.
> This means that for integers > 2^24 this returns an incorrect modulus due to
> this loss of precision.
> Should we use integer only, or perhaps cast to double (so then create a
> DualDoubleFunction) which has a 52bit mantissa, so can convert int to double
> without loss of precision?
> This issue may also affect the other function queries?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
