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 max and argmax sequentially (both in python and c impl). 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.
There's a mirror issue in Aesara: aesara-devs/aesara#765
And a draft PR: aesara-devs/aesara#874
|
class Max(NonZeroDimsCAReduce): |
Description
This Composite
Opcomputes bothMaxandArgmaxand is returned by default when you callat.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 NumpyNope, 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.maxandargmaxsequentially (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
pytensor/pytensor/tensor/math.py
Line 331 in ec6a315
pytensor/pytensor/tensor/math.py
Line 622 in ec6a315