IIRC we had some issues with clip behavior in numpy, we should dig those up to check for possible semantics issues.

This wasn't too bad actually, a lot of it was segfaults and whether it was a ufunc or not. The relevant ones:

Semantics when the max value is smaller than the min value: numpy.clip documentation could be misleading for a_max < a_min numpy/numpy#18782. Probably not very interesting, just undefined behavior,
Whether or not the output dtype should depend on the dtype of the min/max values: numpy.clip does not mantain array dtype when setting min and max to int64 limits numpy/numpy#16609. Not immediately clear to me what the right answer is here.

And of course we need to choose keyword names, always a hard problem. Existing signatures don't match:

np.clip(a, a_min, a_max, out=None, **kwargs)
torch.clip(input, min=None, max=None, *, out=None)

No name is ideal - min/max are nicer names, but not everyone may be happy that it conflicts with builtin names. a_min and a_max are bad though, given that we consistently name our input arrays x and not a. So how about:

def clip(x, min, max, /):  # all positional-only args to avoid incompatibilities

Add clip #482

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Add `clip` #482