question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Change default boundary value to "none" for dask map_overlap

See original GitHub issue

I’d like to propose changing the default value of the boundary keyword argument in map_overlap. The current default is "reflect", and I’d like it to be boundary="none" instead.

Reasons why this would be useful:

  • It’s much faster. It roughly halves the number of tasks, and the difference in compute time is significant
  • There’s less of a difference between results from a numpy array, vs the same data in a dask array (numpy doesn’t do extra padding around the edges by default, so when we do this with dask, it’s not equivalent anymore)
  • Users rely on default values to choose something sensible, and I think fast performance should be weighted more highly as a sensible priority.
  • Many inner functions already handle edges themselves (eg: scipy.ndimage.gaussian_filter, among many others), in which case it is redundant to handle the edges twice.

dask-image already uses boundary="none" wherever possible. We also see users concerned about performance end up doing a bit of experimentation and ending up here too.

cc @jni @jakirkham

Issue Analytics

  • State:closed
  • Created 2 years ago
  • Reactions:1
  • Comments:10 (10 by maintainers)

github_iconTop GitHub Comments

4reactions
jakirkhamcommented, Nov 17, 2021

Ok so it doesn’t sound like this will cause issues. So maybe we should go ahead.

Just to make sure we haven’t missed anyone, would suggest a deprecation cycle. So first we warn if boundary is not specified and let users know the behavior will change (this will become "none" in some future release). Then in that future release (whatever version we picked), we make the change.

3reactions
GenevieveBuckleycommented, Dec 5, 2021

Update, we said we’d make the change in version 2022.03.0

So in late February, we need to make a second PR, changing the default value of the boundary kwarg to "none" (that’s not the python None, but a string with the word "none"). If you see the first PR linked above, there’s a comment telling you which function & line the change needs to be made on.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Overlapping Computations - Dask documentation
Note that asymmetric depths are currently only supported when boundary is 'none'. The default value is 0. boundary: str, tuple, dict or list,...
Read more >
Using da.map_overlap in unstructured interpolation - Dask Array
I am using depth argument in the function da.map_overlap to provide the buffer boundary ... trim=True, boundary=None, align_arrays=False, dtype='float64', ).
Read more >
Does daskarray.map_overlap(array, func) supports multiple ...
Figured out the way to add parameters for the function when calling da.map_overlap(). da.map_overlap(array, func, depth, boundary, trim, ...
Read more >
ForeFlight Mobile Pilot's Guide v14.9.pdf
Jeppesen Terminal procedures are the default and will display automatically in the ... No Action results in no map overlap changes when tapping...
Read more >
What's New in the Latest Build - Manifold.net
Rendering label layers set to map overlap decreases parallelism as such layers ... unnecessary refreshes to data after changes to values in non-key...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found