-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor the axis sanitization #412
Comments
@magnatelee I have one up-front question about philosophy/policy. Is our goal to match numpy's handling of axis args exactly, including any limitations? Or is it acceptable for our APIs to be "wider"? I am thinking specifically of the possibility that some numpy method accepts a strict axis type, but we want to accept a more general (convertible) "axis-like" everywhere for simplicity. Put another way: is it OK if our functions accept everything numpy accepts, and more? (I'm also speculating here, perhaps numpy already accepts a more general "axis-like" everywhere and the issue is moot). |
The goal is to match NumPy's behavior. In most cases, |
from inspect import isclass, isfunction, signature
from pkgutil import walk_packages
import cunumeric
PATH = cunumeric.__path__
PREFIX = f"{cunumeric.__name__}."
SKIP = ("cunumeric.config", "cunumeric.runtime")
for loader, name, _ in walk_packages(path=PATH, prefix=PREFIX):
if name in SKIP: continue
module = loader.find_module(name).load_module(name)
for k, v in vars(module).items():
if k.startswith("_"): continue
if isfunction(v) and "axis" in signature(v).parameters:
print(f"{name}.{k}")
if isclass(v) and v.__module__ == name:
for kk, vv in vars(v).items():
if kk.startswith("_"): continue
try:
if isfunction(vv) and "axis" in signature(vv).parameters:
print(f"{name}.{k}.{kk}")
except ValueError:
pass And the results appear to be:
|
@magnatelee I just wrote
when I discovered that Numpy itself defines an almost identical
or
Rather than duplicate what is already in numpy I would suggest first just apply |
I'm also somewhat confused by some cases like this:
In that case if |
If we can reuse the primitives in NumPy, I don't see a reason not to use them, as long as they have the semantics we're expecting. And you're right,
|
So then accepting None there in argmax there is a bug? Because letting it through will result in a tuple of ints being used inside |
that's not a bug. for some reason, NumPy supports argmin and argmax for a None axis, in which case they yield scalar results. We simply follow this semantics and |
Many operations optionally take an
axis
argument to denote a specific dimension of an ndarray. Although these operations sanitize theaxis
value in almost the same way, they implemented the logic individually and there's no common utility. We need to refactor the code so that all those operations use the same sanitization implementation.The text was updated successfully, but these errors were encountered: