Heirarchical domains

[peterbell10]

As discussed in scipy/scipy@7acf8ba#issuecomment-510888182

The domain a.b.c should be treated as a root domain a with sub-domains a.b and a.b.c. This means that calling a function in the leaf domain (a.b.c) should call backends registered to any of the super-domains, walking up the tree.

I think it would also be useful to be able to disable this on a per sub-domain basis so that the end-user can have more control over the backends being called and so they can fail-fast when not calling into the backend they expect.

[hameerabbasi]

By the user, do you mean the author of a given backend (the person who writes __ua_function__) or the API author (the person who writes the multimethods)? A simple solution would be to expose the domain on the multimethod or C-level _Function object. I can do this if needed.

[hameerabbasi]

Or do you mean immediately writing said code for hierarchical domains? I can do that too.

[peterbell10]

By user, I mean the person installing backends and calling multimethods.

Edit: "End-user" in the uarray documentation.

[hameerabbasi]

How about a ua.skip_domain(domain: str, subdomains: bool=True) context manager?

[hameerabbasi]

I'd still prefer the correct method: Don't depend on the name of the multimethod, it's a flaky decision at best. Also check the __module__ within __ua_function__.

[peterbell10]

I'd still prefer the correct method: Don't depend on the name of the multimethod

This has nothing to do with it, it's about giving the end-user more control over what backend gets called. e.g. if I install the pyfftw backend to numpy.scipy.fft, I might want to make absolutely sure that it's the one being called and not the scipy default.

[hameerabbasi]

This has nothing to do with it, it's about giving the end-user more control over what backend gets called. e.g. if I install the pyfftw backend to numpy.scipy.fft, I might want to make absolutely sure that it's the one being called and not the scipy default.

This is already possible with the set_global_backend(..., only=True) and set_backend(..., only=True), but as I understand currently you'd like to limit backends to those with domains of numpy.scipy.fft?

[peterbell10]

This is already possible with the set_global_backend(..., only=True)

If you do that then registered backends aren't usable.

[hameerabbasi]

Currently subdomains have exact matching, so there is no point in such functionality... Unless you'd like a dummy function that'll gain this functionality once hierarchical domains are implemented?

[peterbell10]

Currently subdomains have exact matching, so there is no point in such functionality...

That's why it's in the same issue :)

[hameerabbasi]

Okay. We'll add this once hierarchical domains are implemented.

[hameerabbasi]

cc @peterbell10 @rgommers

The reason I want numpy backends to be tried before numpy.fft for example:

• dask.array ought to become a numpy backend. It should take precedence over MKL FFT or similar, otherwise we'd have GPU stuff happening on the CPU, non-sparse stuff happening or distributed stuff happening locally, etc.

The reason I'd like this over a list of domains:

• There's no need to know the list of domains beforehand.

[peterbell10]

dask.array ought to become a numpy backend. It should take precedence over MKL FFT

I don't think that they should be in competition with each other. If you pass in a dask array to the mkl_fft backend it should return NotImplemented and then the dask backend would be called anyway.

In your example, I think numpy.fft should be tried first because I am assuming that a more specialised backend would only be installed if it was in some way preferred over the less specialised version e.g. MKL FFT should be preferred over the default numpy FFTs because it's faster. If it's done as you suggest then installing mkl_fft and the default numpy backend wouldn't ever call into mkl_fft.

[hameerabbasi]

In your example, I think numpy.fft should be tried first because I am assuming that a more specialised backend would only be installed if it was in some way preferred over the less specialised version e.g. MKL FFT should be preferred over the default numpy FFTs because it's faster. If it's done as you suggest then installing mkl_fft and the default numpy backend wouldn't ever call into mkl_fft.

Fair enough... You've convinced me. 😄