dask: Data.where#260
Conversation
sadielbartholomew
left a comment
sadielbartholomew
left a comment
There was a problem hiding this comment.
I think a rogue line, or a missed parameter from a typo, might have slipped into the new where docstring examples, but otherwise this is all good. The new unit tests are sound and pass for me locally.
| shape_x = x.shape | ||
| shape_data = data.shape | ||
| for n, m in zip(shape_x[::-1], shape_data[::-1]): | ||
| if n != m and n != 1: |
There was a problem hiding this comment.
Potentially my thought as follows would be premature optimisation, so maybe if anything it could be a tentative TODODASK comment, but could this logic be refactored to avoid the need to calculate the shape of the data in the cases across where x has only size-1 dimensions? In other words, to essentially change the short-circuiting on the if check here to:
| if n != m and n != 1: | |
| if n != 1 n != m: |
in case x is trivial and data is not, notably if it is large so expensive to get its shape? Would that even be worthwhile or could it e.g. be a niche case with general usage of the where method (not sure right now, thinking aloud here)?
There was a problem hiding this comment.
Can we talk about this one on out next call?
There was a problem hiding this comment.
@davidhassell, sure. I'll add it to my (sprawling) questions and thoughts list.
sadielbartholomew
left a comment
sadielbartholomew
left a comment
There was a problem hiding this comment.
Great, thanks! (There are some new left conflicts to resolve, but please go ahead and merge after they have been addressed.)
2 participants
Includes in
cf.Querya bug-fix and new utility methodset_condition_units.