-
Notifications
You must be signed in to change notification settings - Fork 137
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): |