Description
We already support the following decay functions in painless for the script_score query:
double decayNumericLinear(double origin, double scale, double offset, double decay, double docValue)
double decayNumericExp(double origin, double scale, double offset, double decay, double docValue)
double decayNumericGauss(double origin, double scale, double offset, double decay, double docValue)
double decayGeoLinear(String originStr, String scaleStr, String offsetStr, double decay, GeoPoint docValue)
double decayGeoExp(String originStr, String scaleStr, String offsetStr, double decay, GeoPoint docValue)
double decayGeoGauss(String originStr, String scaleStr, String offsetStr, double decay, GeoPoint docValue)
double decayDateLinear(String originStr, String scaleStr, String offsetStr, double decay, JodaCompatibleZonedDateTime docValueDate)
double decayDateExp(String originStr, String scaleStr, String offsetStr, double decay, JodaCompatibleZonedDateTime docValueDate)
double decayDateGauss(String originStr, String scaleStr, String offsetStr, double decay, JodaCompatibleZonedDateTime docValueDate)
Decay functions are used to penalize scores based on recency (for date types) or distance (numeric and geo types) and this is a useful feature we want to add to ES|QL.
We do not want to add 9 different decay functions. We could have a single decay function with the following signature:
decay(type, origin, scale, offset, decay, value)
For parameters:
Type: can be "linear", "exp" or "gauss".
Origin: numeric, spatial, date types
Scale: numeric, spatial, date types
Offset: numeric, spatial, date types
Decay: numeric
Value: numeric, spatial, date types
The return type should be double.
In terms of priority - it would make sense to add support for linear and exponential first, with gauss decay being used less in practice.
As a note we could potentially have 3 different decay functions decay_linear, decay_exp and decay_gauss.