Beta parameter in Gamma RV displays as f() in Latex due to TrueDiv scalar Op

[larryshamalama]

with pm.Model() as model:
    a = pm.Gamma("a", 1., 5.)

model

yields $a \sim \text{Gamma}(1, f())$ due to the second parameter/last input being an Elemwise{true_div,no_inplace}.0. dprint yields:

gamma_rv{0, (0, 0), floatX, False}.1 [id A] 'a'
 |RandomGeneratorSharedVariable(<Generator(PCG64) at 0x184C99E00>) [id B]
 |TensorConstant{[]} [id C]
 |TensorConstant{11} [id D]
 |TensorConstant{1.0} [id E]
 |Elemwise{true_div,no_inplace} [id F]
   |TensorConstant{1.0} [id G]
   |TensorConstant{5.0} [id H]

[ricardoV94]

Yeah, it's because Aesara or PyMC uses the rate and the other uses the shape parametrization

[larryshamalama]

Should the Latex display be adapted just for the Gamma distribution? Are there other instances of a TrueDiv being "incorrectly" displayed?

[ricardoV94]

It's not incorrect though. If you used the mu/sigma parametrization you would also always get f() in the parameters. This is a more broad question of how to display transformed parameters

[larryshamalama]

Okay, I see what you mean. I'm not the biggest fan of seeing $a \sim \text{Gamma}(1, f())$ with pm.Gamma("a", 1., 5.) initialization as I would be expecting $a \sim \text{Gamma}(1, 5)$. However, regarding the more broad question, I don't have a solution in mind; displaying f() may be best for transformed parameters. Shall we leave it this way then? Can we incorporate a specific fix for the case where the Gamma distribution is used with 1) an alpha, beta initialization and 2) the parameters are constant? Or would this be too specific...

[ricardoV94]

@larryshamalama yes that would be too specific a change. You might want to study https://github.com/aesara-devs/aeppl/blob/main/aeppl/printing.py (and https://github.com/aesara-devs/aeppl/blob/main/tests/test_printing.py) to get some ideas of how a more general solution may work. I agree that it would be great to get rid of most of those opaque f(), but we should do it in a way that generalizes well

[larryshamalama]

@larryshamalama yes that would be too specific a change. You might want to study https://github.com/aesara-devs/aeppl/blob/main/aeppl/printing.py (and https://github.com/aesara-devs/aeppl/blob/main/tests/test_printing.py) to get some ideas of how a more general solution may work. I agree that it would be great to get rid of most of those opaque f(), but we should do it in a way that generalizes well

I dove into aeppl/printing.py and the approach taken seems very well done. I spent some time understanding it and tweaking it and I was able to retrieve some preliminary results; see this gist. Notably, dispatching of SymbolicRandomVariables is not included since it's a PyMC design, but a SymbolicRVPrinter class can be created, possible tailored to each symbolic distribution?

It also seems like the printing module of AePPL is not available in the PyMC logprob submodule. On top my head, the advantages are that 1) the approach is more general and cleaner and 2) printing of non-distribution Ops are included (I don't think that we have that in PyMC). The main cons are that the code was challenging to understand and most of the gist was taken verbatim from AePPL.

I don't think that closing #6311 would be too too challenging but, when it comes to providing a more general design to printing variables and PyMC models, this seems to be a preferable solution, as you mention above. Some modifications to PyTensor would be needed at some point. Happy to hear thoughts on this.