Rolling does not respect type, converts to float

[racinmat]

Function rolling returns float for int arguments, it should keep the type and not make conversions unless the aggregation function needs it. See

julia>     data = 1:5
1:5

julia>     rolling(sum, data, 3)
3-element Vector{Float64}:
  6.0
  9.0
 12.0

julia>     [sum(data[i-2:i]) for i in 3:length(data)]
3-element Vector{Int64}:
  6
  9
 12

it would make sense for rolling to return ints instead of floats.

[jmurga]

Similar problem when using customs functions in rolling. You cannot return multiple outputs from your functions because the module will try to convert it to Float.

[miromarszal]

It would be particularly useful to allow custom functions output vectors, so that one could do, for instance, a rolling pacf for multiple lags at once.

[JeffreySarnoff]

These are two different requests. Looking into both.

The return a sequence that is typed as the input is typed is not something that makes sense in the general case (the mean of some integers is not an integer). So each rolling summarization would need to be annotated with allowed type[s] in and how they map to type(s) out, which would introduce some overhead -- perhaps there is a general way to not be so general.

The essential design that drives all of the rolling capability and flexibility "looks over successive, stepped, adjacent spans of data" and observes a summary from each look -- providing theses summaries as successive items in the result, a sequence of values. To generalize this sense of a summary from a numerical value to a value tuple, would add something of intrinsic merit.

[JeffreySarnoff]

closed (fixed) in main (unregistered)