-
Notifications
You must be signed in to change notification settings - Fork 148
Description
Description
This Composite Op computes both Max and Argmax and is returned by default when you call at.max(...).
This makes the graphs unnecessarily more complex from the get-go (see pymc-devs/pymc#6769).
In this specific case there's no loss of functionality because the implementation actually computes the two separately. I imagine an early algorithm computed the two at the same time, but they seemed to have switched to using Numpy Nope, the original one was already like that. Maybe it was useful in other backends (GPU?). Anyway, that's just guessing, and I don't see an obvious reason to start with MaxAndArgmax. If a more efficient impl can be obtained it could be added during specialization, not by default.max and argmax sequentially (both in python and c impl).
There's a mirror issue in Aesara: aesara-devs/aesara#765
And a draft PR: aesara-devs/aesara#874
pytensor/pytensor/tensor/math.py
Line 122 in ec6a315
| class MaxAndArgmax(COp): |
pytensor/pytensor/tensor/math.py
Line 331 in ec6a315
| class Argmax(COp): |
pytensor/pytensor/tensor/math.py
Line 622 in ec6a315
| class Max(NonZeroDimsCAReduce): |