Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Top inclusive/exclusive #4

Open
r4j4h opened this issue Jan 19, 2015 · 0 comments
Open

Top inclusive/exclusive #4

r4j4h opened this issue Jan 19, 2015 · 0 comments

Comments

@r4j4h
Copy link
Owner

r4j4h commented Jan 19, 2015

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant