Hi @Samuel1 ,
sorry for the high latency, I was off last week.
The most tricky part about processing entries with a sliding window is multi-threading – each entry will process a bunch of entries at a time, and the first and last entries in the bunch will not have a previous/next entry so you’ll miss some statistics.
If you are happy with single-thread processing, or you don’t mind losing some of the pairs of consecutive entries, you can use a stateful functor + RDataFrame, something like (haven’t tested, it’s just to give you an idea):
// not thread-safe, but can easily be made thread-safe by using a vector of
// previousPseudoRapidity values, one per thread (df.GetNSlots() returns the
// the required number of threads/processing slots).
struct PseudoRapidityDiff {
double previousPseudoRapidity = 1e20;
double operator()(double pseudoRapidity) {
if (previousPseudoRapidity > 1e19) // no previous value
return -999;
double diff = pseudoRapidity - previousPseudoRapidity;
previousPseudoRapidity = pseudoRapidity;
return diff;
}
};
// only safe in single-thread processing
df.Define("pseudoRapDiff", PseudoRapidityDiff{}, {"pseudoRapidity"});
I hope this helps!
Enrico
P.S.
I am not familiar with TimeFrame
personally, but my understanding is that it is an independent class that reuses some RDF concepts but natively works with sliding windows. @Axel will know more.