# Searching on exponent numbers **URL:** \ **Category:** Elasticsearch\ **Created:** [May 22, 2015, 6:20am UTC](https://discuss.elastic.co/t/searching-on-exponent-numbers/23667 "2015-05-22T06:20:03Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Craig\_Berry](https://avatars.discourse-cdn.com/v4/letter/c/c77e96/32.png) [@Craig\_Berry](https://discuss.elastic.co/u/Craig_Berry)\ **Post date:** [May 22, 2015, 6:20am UTC](https://discuss.elastic.co/t/searching-on-exponent-numbers/23667/1 "2015-05-22T06:20:03Z")
Hi there, I want to be able to provide a text search against a document that contains a large number (10+ digits) but running into some automatic exponent conversion issues with my mapping. Scenario: User can submit a value of 1234567890 in a field and then wants to be able to return that document by searching for the exact text "1234567890". In my current implementation, I'm storing the value in a double typed field (since the field could contain floating point values) with a sub field that copies the string value to another field with a custom analyser that splits the number by decimal point: "numberField": { "type": "double", "fields": { "asText": { "type": "string", "copy\_to": [ "all\_numbers" ] } }, "all\_numbers": { "type": "string", "analyzer": "number\_analyzer" } So this means if the value is 31, then it's stored as 31.0 in numberField and then in all\_numbers as "31" and "0". So a text search against the all\_numbers field will return this document. However, when the number value is very large, it seems the double conversion to string is using exponents, e.g. 1234567890 becomes 1.23456789E9. This means what's stored in my all\_numbers field is "1" and "23456789E9" and so a text search of "1234567890" returns 0 hits. At this point I'm just wondering whether my source document should contain the value twice, once as a number and once as string and avoid needing to do any custom analysis, however this does mean moving this logic to the application layer when I'd rather Elastic could just handle it. Any other suggestions on how I could get Elastic to store the value as I desire? FYI I have other custom analysers running on the \_all field that means searching that field doesn't return the 'number' either. TIA Craig ## -- Please update your bookmarks! We have moved to [https://discuss.elastic.co/](https://discuss.elastic.co/) You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/1895aa0e-659f-425a-8ae4-9b8b69f9eea1%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/1895aa0e-659f-425a-8ae4-9b8b69f9eea1%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\ **Post date:** [May 22, 2015, 9:07am UTC](https://discuss.elastic.co/t/searching-on-exponent-numbers/23667/2 "2015-05-22T09:07:18Z")
This is a long unresolved issue. One solution would be adding BigDecimal support. See for example > > > For XContentBuilder/XContentParser and document mapping, this will add support f…or "big" numeric types BigInteger/BigDecimal. > > BigInteger/BigDecimal support for XContentBuilder/XContentParser is implemented by using the existing Jackson support for the "big" numeric types. A new method \`losslessDecimals()\` is used to switch the XContentParser into recognizing BigInteger/BigDecimal in precedence over primitive numeric types, for better convenience when using the Java API for parsing document sources with BigInteger/BigDecimal field values. > > For the document mapping, new core types \`biginteger\` and \`bigdecimal\` are introduced. With a new flag \`lossless\_numeric\_detection\`, the precedence of BigInteger/BigDecimal over primitive numeric types can be controlled in the mapping. When set to \`true\`, new dynamic numeric fields are assigned to "big" numeric types first. Default is \`false\`, where primitive numeric types still take precedence. > > Caveat: BigInteger/BigDecimal support is just meant for search and indexing/storing. The "big" numeric types are degraded to their \`.longValue()\` and \`.doubleValue()\` components when they are used in NumericRangeQuery and related contexts, so it is not recommended to use values larger than Long.MAX\_VALUE or Double.MAX\_VALUE in analytical queries like facets and aggregations, strange cut-offs or underflows/overflows should occur. Jörg On Fri, May 22, 2015 at 8:20 AM, Craig Berry [craig.adrian.berry@gmail.com](mailto:craig.adrian.berry@gmail.com) wrote: > Hi there, > > I want to be able to provide a text search against a document that > contains a large number (10+ digits) but running into some automatic > exponent conversion issues with my mapping. > > Scenario: User can submit a value of 1234567890 in a field and then wants > to be able to return that document by searching for the exact text > "1234567890". > > In my current implementation, I'm storing the value in a double typed > field (since the field could contain floating point values) with a sub > field that copies the string value to another field with a custom analyser > that splits the number by decimal point: > > "numberField": { > "type": "double", > "fields": { > "asText": { > "type": "string", > "copy\_to": [ > "all\_numbers" > ] > } > }, > "all\_numbers": { > "type": "string", > "analyzer": "number\_analyzer" > } > > So this means if the value is 31, then it's stored as 31.0 in numberField > and then in all\_numbers as "31" and "0". So a text search against the > all\_numbers field will return this document. > > However, when the number value is very large, it seems the double > conversion to string is using exponents, e.g. 1234567890 becomes > 1.23456789E9. This means what's stored in my all\_numbers field is "1" and > "23456789E9" and so a text search of "1234567890" returns 0 hits. > > At this point I'm just wondering whether my source document should contain > the value twice, once as a number and once as string and avoid needing to > do any custom analysis, however this does mean moving this logic to the > application layer when I'd rather Elastic could just handle it. > > Any other suggestions on how I could get Elastic to store the value as I > desire? > > FYI I have other custom analysers running on the \_all field that means > searching that field doesn't return the 'number' either. > > TIA > > Craig > > ## -- Please update your bookmarks! We have moved to [https://discuss.elastic.co/](https://discuss.elastic.co/) > > You received this message because you are subscribed to the Google Groups > "elasticsearch" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > To view this discussion on the web visit > [https://groups.google.com/d/msgid/elasticsearch/1895aa0e-659f-425a-8ae4-9b8b69f9eea1%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/1895aa0e-659f-425a-8ae4-9b8b69f9eea1%40googlegroups.com) > [https://groups.google.com/d/msgid/elasticsearch/1895aa0e-659f-425a-8ae4-9b8b69f9eea1%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/1895aa0e-659f-425a-8ae4-9b8b69f9eea1%40googlegroups.com?utm_medium=email&utm_source=footer) > . > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ## -- Please update your bookmarks! We have moved to [https://discuss.elastic.co/](https://discuss.elastic.co/) You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoG4\_yghdUijNB3q3Ppcc-ws1WziNk62vo90ZOqKwUfLfA%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoG4_yghdUijNB3q3Ppcc-ws1WziNk62vo90ZOqKwUfLfA%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 12:12am UTC](https://discuss.elastic.co/t/searching-on-exponent-numbers/23667/3 "2017-07-06T00:12:28Z")