Conversation
…mprove performance
| xmin, xmax = x['value'].min(), x['value'].max() | ||
| ymin, ymax = y['value'].min(), y['value'].max() |
There was a problem hiding this comment.
I presume the exclusive bounds are intentional?
There was a problem hiding this comment.
Do you mean that if we have a max value that falls exactly on a bin edge, the bin to the right of that won't be included?
I think that's it what we want?

If I draw a rectangle exactly from 15 to 20, then I want the cells from the left edge at 15 to the right edge at 20 to be included.
I don't want the cell with a right edge at 15 and the one with left edge at 20 to be included. Right?
There was a problem hiding this comment.
I don't know. We have made that decision for slicing, but I am not sure the same is valid for a UI and drawing a rectangle — a user might expect both bounds to be inclusive?
…ctangle, now it's as soon as one edge is in the rectangle
| # Closing the rectangle by repeating the first point. | ||
| x = [-1, 21] | ||
| y = [-1, 310] | ||
| x = [-1, 19] |
There was a problem hiding this comment.
This indicates a slight behaviour change:
before a cell was only included if its center was in the rectangle, now it's as soon as one edge is in the rectangle.
This makes little difference for data with a large resolution.
Which is the correct one is difficult to decide. When the operation we perform at the end is a sum, we would probably want to just rebin at the exact position of the rectangle edge, to include a fraction of an incomplete bin.
But if the operation is something else, it is not clear what should actually be done.
I think it's fine for now, it's probably what most users would expect.
If some fine tuning is needed for a specific application we can either revisit or make a custom selection function and inject that in the inspector (somehow).
We use slicing for rectangle tool instead of masking like a polygon.
This yields a very large speedup.
Try out this on
mainand in thisspeedup-rectangle-inspectorbranch: