Minor improvements to docs for numeric types (#27553)

* Caps
* Fix awkward wording that took multiple passes to parse
* Floating point _number_
* Something more descriptive about the `scaled_float` scaling factor.
This commit is contained in:
David Turner 2017-11-28 11:36:07 +00:00 committed by GitHub
parent 7ac361d86e
commit a165d1df40
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -8,10 +8,10 @@ The following numeric types are supported:
`integer`:: A signed 32-bit integer with a minimum value of +-2^31^+ and a maximum value of +2^31^-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+. `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+. `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. `double`:: A double-precision 64-bit IEEE 754 floating point number.
`float`:: A single-precision 32-bit IEEE 754 floating point. `float`:: A single-precision 32-bit IEEE 754 floating point number.
`half_float`:: A half-precision 16-bit IEEE 754 floating point. `half_float`:: A half-precision 16-bit IEEE 754 floating point number.
`scaled_float`:: A floating point that is backed by a `long` and a fixed scaling factor. `scaled_float`:: A floating point number that is backed by a `long`, scaled by a fixed `double` scaling factor.
Below is an example of configuring a mapping with numeric fields: Below is an example of configuring a mapping with numeric fields:
@ -49,15 +49,15 @@ bound is `+0.0` then `-0.0` will not match.
As far as integer types (`byte`, `short`, `integer` and `long`) are concerned, 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 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 help indexing and searching be more efficient. Note however that storage is
storage is optimized based on the actual values that are stored, picking one optimized based on the actual values that are stored, so picking one type over
type over another one will have no impact on storage requirements. another one will have no impact on storage requirements.
For floating-point types, it is often more efficient to store floating-point For floating-point types, it is often more efficient to store floating-point
data into an integer using a scaling factor, which is what the `scaled_float` data into an integer using a scaling factor, which is what the `scaled_float`
type does under the hood. For instance, a `price` field could be stored in a type does under the hood. For instance, a `price` field could be stored in a
`scaled_float` with a `scaling_factor` of +100+. All APIs would work as if `scaled_float` with a `scaling_factor` of +100+. All APIs would work as if
the field was stored as a double, but under the hood elasticsearch would be the field was stored as a double, but under the hood Elasticsearch would be
working with the number of cents, +price*100+, which is an integer. This is working with the number of cents, +price*100+, which is an integer. This is
mostly helpful to save disk space since integers are way easier to compress mostly helpful to save disk space since integers are way easier to compress
than floating points. `scaled_float` is also fine to use in order to trade than floating points. `scaled_float` is also fine to use in order to trade