inducer / arraycontext

Choose your favorite numpy-workalike!
6 stars 11 forks source link

Make broadcast settings visible on users of with_container_arithmetic #45

Closed inducer closed 3 years ago

inducer commented 3 years ago

This is to support use cases like https://github.com/illinois-ceesd/mirgecom/pull/331, where the information that with_container_arithmetic has about the desired broadcast behavior of a type would also be useful to have. To make it available, this just shoves it into some (undocumented, for now) class attributes. In the linked use case, this would help (e.g.) avoid the need for hardcoding DOFArray. Instead, it could check whether np.ndarray is in type(obj)._outer_bcast_names and then follow that behavior.

I also have a distinct feeling that this might also be a bad idea. @alexfikl, got a gut feeling on this one?

cc @majosm

alexfikl commented 3 years ago

Is it worth moving the outer function somewhere in arraycontext.container? That way it would keep all of this a bit more contained if we ever decide to change it.

Besides that, no particular feeling of impending doom on my side :shrug:

inducer commented 3 years ago

Is it worth moving the outer function somewhere in arraycontext.container?

I'd be all for that, especially since it'd help avoid use of private attributes across package boundaries. @majosm? (Added you to the repo just in case.)

inducer commented 3 years ago

Thanks for taking a look!

majosm commented 3 years ago

Is it worth moving the outer function somewhere in arraycontext.container?

I'd be all for that, especially since it'd help avoid use of private attributes across package boundaries. @majosm? (Added you to the repo just in case.)

Just wondering: how come the specifications in with_container_arithmetic don’t become public? Would it be useful for external code to have access to that so it can build on top of the existing mapping functionality?

inducer commented 3 years ago

Just wondering: how come the specifications in with_container_arithmetic don’t become public? Would it be useful for external code to have access to that so it can build on top of the existing mapping functionality?

I could very well see it being useful. I just have commitment anxiety about the interface... it seems kind of janky and poorly defined.

majosm commented 3 years ago

@inducer Where should I stick outer?

inducer commented 3 years ago

container.traversal, and importable from the root?

majosm commented 3 years ago

46

inducer commented 3 years ago

Closing in favor of #46.