[[number]]
=== Numeric datatypes

The following numeric types are supported:

[horizontal]
`long`::       A signed 64-bit integer with a minimum value of +-2^63^+ and a maximum value of +2^63^-1+.
`integer`::    A signed 32-bit integer with a minimum value of +-2^31^+ and a maximum value of +2^31^-1+.
`short`::      A signed 16-bit integer with a minimum value of +-32,768+ and a maximum value of +32,767+.
`byte`::       A signed 8-bit integer with a minimum value of +-128+ and a maximum value of +127+.
`double`::     A double-precision 64-bit IEEE 754 floating point.
`float`::      A single-precision 32-bit IEEE 754 floating point.
`half_float`:: A half-precision 16-bit IEEE 754 floating point.

Below is an example of configuring a mapping with numeric fields:

[source,js]
--------------------------------------------------
PUT my_index
{
  "mappings": {
    "my_type": {
      "properties": {
        "number_of_bytes": {
          "type": "integer"
        },
        "time_in_seconds": {
          "type": "float"
        }
      }
    }
  }
}
--------------------------------------------------
// CONSOLE

==== Which type should I use?

As far as integer types (`byte`, `short`, `integer` and `long`) are concerned,
you should pick the smallest type which is enough for your use-case. This will
help indexing and searching be more efficient. Note however that given that
storage is optimized based on the actual values that are stored, picking one
type over another one will have no impact on storage requirements.

For floating-point types, picking the smallest type that is enough for the
use-case will still help indexing and searching be more efficient. However,
given that floating-point data is hard to compress, it might also have a
significant impact on storage requirements. Here is a table that compares the
3 floating-point types that are available in order to help make a decision.

[cols="<,<,<,<",options="header",]
|=======================================================================
|Type |Minimum value |Maximum value |Significant bits / digits
|`double`|+2^-1074^+ |+(2-2^-52^)·2^1023^+ |+53+ / +15.95+
|`float`|+2^-149^+ |+(2-2^-23^)·2^127^+ |+24+ / +7.22+
|`half_float`|+2^-24^+ |+65504+ |+11+ / +3.31+
|=======================================================================

When possible, it is often more efficient to store floating-point data into an
integer using a scaling factor. For instance, it is more efficient to store
percentages as integers between 0 and 100 than as floating-point numbers between 0
and 1. Another example would be prices: it will be more efficient to store prices
as a number of cents, which is an integer, than as a floating-point number.

[[number-params]]
==== Parameters for numeric fields

The following parameters are accepted by numeric types:

[horizontal]

<<coerce,`coerce`>>::

    Try to convert strings to numbers and truncate fractions for integers.
    Accepts `true` (default) and `false`.

<<mapping-boost,`boost`>>::

    Mapping field-level query time boosting. Accepts a floating point number, defaults
    to `1.0`.

<<doc-values,`doc_values`>>::

    Should the field be stored on disk in a column-stride fashion, so that it
    can later be used for sorting, aggregations, or scripting? Accepts `true`
    (default) or `false`.

<<ignore-malformed,`ignore_malformed`>>::

    If `true`, malformed numbers are ignored. If `false` (default), malformed
    numbers throw an exception and reject the whole document.

<<include-in-all,`include_in_all`>>::

    Whether or not the field value should be included in the
    <<mapping-all-field,`_all`>> field? Accepts `true` or `false`.  Defaults
    to `false` if <<mapping-index,`index`>> is set to `false`, or if a parent
    <<object,`object`>> field sets `include_in_all` to `false`.
    Otherwise defaults to `true`.

<<mapping-index,`index`>>::

    Should the field be searchable? Accepts `true` (default) and `false`.

<<null-value,`null_value`>>::

    Accepts a numeric value of the same `type` as the field which is
    substituted for any explicit `null` values.  Defaults to `null`, which
    means the field is treated as missing.

<<mapping-store,`store`>>::

    Whether the field value should be stored and retrievable separately from
    the <<mapping-source-field,`_source`>> field. Accepts `true` or `false`
    (default).