You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So right now when using .top(3) for example, only the top 3 records are fetched from the source group and their % change or moving averages calculated from there on. This could lead to misleading numbers.
An argument could be made that all the records should be fetched from the source group and their % change or moving averages calculated and only the top 3 of those post-calculation results returned.
In the meantime, using .top(Infinity) or .all() and then grabbing/slicing from the returned complete array to maintain prior sorting should always provide accurate numbers. If sorted % change or moving averages is desired, then either of those in combination with the appropriate sortBy should always provide accurate numbers.
IOW, .top(K) with fewer K than there are data points currently works off those data points as if only they exist.
The area I want to explore is intelligently padding the K argument to include needed data in calculations while keeping it out of the results. At least for % change and short-term moving averages this should make up for the incorrect values whilst avoiding requiring iterating the entire data set.
The text was updated successfully, but these errors were encountered:
So right now when using .top(3) for example, only the top 3 records are fetched from the source group and their % change or moving averages calculated from there on. This could lead to misleading numbers.
An argument could be made that all the records should be fetched from the source group and their % change or moving averages calculated and only the top 3 of those post-calculation results returned.
In the meantime, using
.top(Infinity)
or.all()
and then grabbing/slicing from the returned complete array to maintain prior sorting should always provide accurate numbers. If sorted % change or moving averages is desired, then either of those in combination with the appropriate sortBy should always provide accurate numbers.IOW, .top(K) with fewer K than there are data points currently works off those data points as if only they exist.
The area I want to explore is intelligently padding the K argument to include needed data in calculations while keeping it out of the results. At least for % change and short-term moving averages this should make up for the incorrect values whilst avoiding requiring iterating the entire data set.
The text was updated successfully, but these errors were encountered: