[
https://issues.apache.org/jira/browse/SOLR-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill A. updated SOLR-10332:
-----------------------------
Description:
There are rounding errors in the Stats component of Solr while requesting
min/max statistics for a currency field.
Description:
I have a currency field price in the Solr index. Here is the schema definition:
<fieldType name="currency" class="solr.CurrencyField"
currencyConfig="currency.xml" defaultCurrency="EUR" precisionStep="8"/>
<field name="price" type="currency" multiValued="false" indexed="true"
required="false" stored="true"/>
Sending a stats query to get the min/man price in the result set leads to
rounding errors for index documents with a price with certain digits after the
decimal point.
The following stats-string is used in the stats query:
{code:title=Stats-string|borderStyle=solid}
stats=true&stats.field={!func}currency(price,EUR)
{code}
Example 1:
Index document with
"price":"209.90000,EUR"
Stats query only for this document (with additional fq-filter using the id)
returns:
"stats":{
"stats_fields":{
"currency(price,EUR)":{
"min":209.89999389648438,
"max":209.89999389648438,
...
Example 2:
Index document with
"price":"295.95000,EUR",
Stats query only for this document (with additional fq-filter using the id)
returns:
"stats":{
"stats_fields":{
"currency(price,EUR)":{
"min":295.95001220703125,
"max":295.95001220703125,
...
Now if you want to determine a price range to show to the user (min and max
price in the index for the current constraints), you can not safely use the
stats function: if you round the result 295.95001220703125 to a price with two
digits after the decimal point you get: 295.95. Now if you use 295.95 as the
max price of the range, you will not find documents which actually have a price
295.95001220703125 and not 295.95000 in the second example. The stats function
returned 295.95001220703125 but we don't know if it is a rounding error or a
real price. Note, that if a price has a different currency, the conversion to
EUR (default currency) can also produce a result with a lot of decimal places
so you have to rely on accuracy of the stats function.
So it is not a solution to round an inaccurate result to determine the max
price (if you round the inaccurate result down, you get 295.95 but you will not
find documents with an other currency equal to for example 295.951 EUR, so you
should not round down. If you round the inaccurate result up you get: 295.96
but it is not the real price of the document in the second example).
The min and max stats function should return an accurate result (example 1:
209.9 EUR, example 2: 295.95 EUR)
The SolrJ interface of Solr in Java returns a result of min/max stats function
as double, but double can provide inaccurate results for currency fields and
currency conversion, please consider using BigDecimal.
was:
There are rounding errors in the Stats component of Solr while requesting
min/max statistics for a currency field.
Description:
I have a currency field price in the Solr index. Here is the schema definition:
<fieldType name="currency" class="solr.CurrencyField"
currencyConfig="currency.xml" defaultCurrency="EUR" precisionStep="8"/>
<field name="price" type="currency" multiValued="false" indexed="true"
required="false" stored="true"/>
Sending a stats query to get the min/man price in the result set leads to
rounding errors for index documents with a price with certain digits after the
decimal point.
The following stats-string is used in the stats query:
stats=true&stats.field={!func}currency(price,EUR)
Example 1:
Index document with
"price":"209.90000,EUR"
Stats query only for this document (with additional fq-filter using the id)
returns:
"stats":{
"stats_fields":{
"currency(price,EUR)":{
"min":209.89999389648438,
"max":209.89999389648438,
...
Example 2:
Index document with
"price":"295.95000,EUR",
Stats query only for this document (with additional fq-filter using the id)
returns:
"stats":{
"stats_fields":{
"currency(price,EUR)":{
"min":295.95001220703125,
"max":295.95001220703125,
...
Now if you want to determine a price range to show to the user (min and max
price in the index for the current constraints), you can not safely use the
stats function: if you round the result 295.95001220703125 to a price with two
digits after the decimal point you get: 295.95. Now if you use 295.95 as the
max price of the range, you will not find documents which actually have a price
295.95001220703125 and not 295.95000 in the second example. The stats function
returned 295.95001220703125 but we don't know if it is a rounding error or a
real price. Note, that if a price has a different currency, the conversion to
EUR (default currency) can also produce a result with a lot of decimal places
so you have to rely on accuracy of the stats function.
So it is not a solution to round an inaccurate result to determine the max
price (if you round the inaccurate result down, you get 295.95 but you will not
find documents with an other currency equal to for example 295.951 EUR, so you
should not round down. If you round the inaccurate result up you get: 295.96
but it is not the real price of the document in the second example).
The min and max stats function should return an accurate result (example 1:
209.9 EUR, example 2: 295.95 EUR)
The SolrJ interface of Solr in Java returns a result of min/max stats function
as double, but double can provide inaccurate results for currency fields and
currency conversion, please consider using BigDecimal.
> Rounding errors in min/max statistics for a currency field/currency conversion
> ------------------------------------------------------------------------------
>
> Key: SOLR-10332
> URL: https://issues.apache.org/jira/browse/SOLR-10332
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Affects Versions: 6.4.1, 6.4.2
> Reporter: Kirill A.
>
> There are rounding errors in the Stats component of Solr while requesting
> min/max statistics for a currency field.
> Description:
> I have a currency field price in the Solr index. Here is the schema
> definition:
> <fieldType name="currency" class="solr.CurrencyField"
> currencyConfig="currency.xml" defaultCurrency="EUR" precisionStep="8"/>
> <field name="price" type="currency" multiValued="false" indexed="true"
> required="false" stored="true"/>
> Sending a stats query to get the min/man price in the result set leads to
> rounding errors for index documents with a price with certain digits after
> the decimal point.
> The following stats-string is used in the stats query:
> {code:title=Stats-string|borderStyle=solid}
> stats=true&stats.field={!func}currency(price,EUR)
> {code}
> Example 1:
> Index document with
> "price":"209.90000,EUR"
> Stats query only for this document (with additional fq-filter using the id)
> returns:
> "stats":{
> "stats_fields":{
> "currency(price,EUR)":{
> "min":209.89999389648438,
> "max":209.89999389648438,
> ...
> Example 2:
> Index document with
> "price":"295.95000,EUR",
> Stats query only for this document (with additional fq-filter using the id)
> returns:
> "stats":{
> "stats_fields":{
> "currency(price,EUR)":{
> "min":295.95001220703125,
> "max":295.95001220703125,
> ...
> Now if you want to determine a price range to show to the user (min and max
> price in the index for the current constraints), you can not safely use the
> stats function: if you round the result 295.95001220703125 to a price with
> two digits after the decimal point you get: 295.95. Now if you use 295.95 as
> the max price of the range, you will not find documents which actually have a
> price 295.95001220703125 and not 295.95000 in the second example. The stats
> function returned 295.95001220703125 but we don't know if it is a rounding
> error or a real price. Note, that if a price has a different currency, the
> conversion to EUR (default currency) can also produce a result with a lot of
> decimal places so you have to rely on accuracy of the stats function.
> So it is not a solution to round an inaccurate result to determine the max
> price (if you round the inaccurate result down, you get 295.95 but you will
> not find documents with an other currency equal to for example 295.951 EUR,
> so you should not round down. If you round the inaccurate result up you get:
> 295.96 but it is not the real price of the document in the second example).
> The min and max stats function should return an accurate result (example 1:
> 209.9 EUR, example 2: 295.95 EUR)
> The SolrJ interface of Solr in Java returns a result of min/max stats
> function as double, but double can provide inaccurate results for currency
> fields and currency conversion, please consider using BigDecimal.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
