first_n, last_n, max_n and min_n reductions #1184
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is further work on improved inspection reductions (issue #1126) to add
first_n
,last_n
,max_n
andmin_n
reductions. Each accepts a column name and value forn
, the number of results to return for each pixel. For example,max("value", n=3)
will return a DataArray of shape(ny, nx, n)
containing the 3 highest values of column"value"
for each pixel.Demo code using these within a
where
reduction to return corresponding row indexes or values from a different column:which outputs
where, as usual,
-1
means no row index andnan
means no data to return.This allows us to do some complicated combinations such as
to return
count
plusmin_n
andmax_n
(orfirst_n
andlast_n
) in a single datashader pass.max_n
andmin_n
work with dask but not CUDA (issue #1177 needs to be solved for that).first_n
andlast_n
only work on the CPU and without dask, the same asfirst
andlast
(#1177 and #1182 are needed to fix that).Using antialiased lines the results looked OK in some situation and not others, so I am raising a
NotImplemented
error for all of these when using with antialiasing and I will separately consider what is reasonable behaviour here. This includeswhere(first_n)
and so on as well.There is one issue here that needs deciding. I've called the third dimension of the DataArray returned by such a reduction
"n"
to fit in with the namesfirst_n
, etc. You can put multiplewhatever_n
reductions in a singlesummary
reduction as shown above. If they have the samen
then it all works out as expected. But we need a policy on labelling the third dimension if thewhatever_n
have differentn
values. We could keep the firstn
asn
, and if subsequentn
values are different call themn1
,n2
, etc?