Remove wrong type-hints and stale docstrings from distributions

[ricardoV94]

Related to #4859

This was originally proposed in #6272, see #6272 (review)

Major / Breaking Changes

• ...

Bugfixes / New features

• ...

Docs / Maintenance

• Remove stale logp and logcdf docstrings

[codecov]

Codecov Report

Merging #6280 (d34b557) into main (7608e30) will increase coverage by 0.40%.
The diff coverage is 100.00%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6280      +/-   ##
==========================================
+ Coverage   94.19%   94.59%   +0.40%     
==========================================
  Files         102      111       +9     
  Lines       21490    25883    +4393     
==========================================
+ Hits        20243    24485    +4242     
- Misses       1247     1398     +151     

Impacted Files	Coverage Δ
pymc/distributions/discrete.py	99.64% <ø> (+0.42%)	⬆️
pymc/distributions/continuous.py	97.50% <100.00%> (ø)
pymc/distributions/logprob.py	92.48% <0.00%> (-4.78%)	⬇️
pymc/tests/distributions/util.py	90.00% <0.00%> (-0.87%)	⬇️
pymc/stats/convergence.py	92.72% <0.00%> (-0.21%)	⬇️
pymc/backends/base.py	87.54% <0.00%> (-0.11%)	⬇️
pymc/initial_point.py	100.00% <0.00%> (ø)
pymc/tests/tuning/test_starting.py	100.00% <0.00%> (ø)
pymc/tests/stats/test_convergence.py	100.00% <0.00%> (ø)
pymc/tests/distributions/test_bound.py	100.00% <0.00%> (ø)
... and 31 more

[canyon289]

Thank you Ricardo! I'll get to this in next 96 hours

[OriolAbril]

Not blocking the PR, but trying to think forawrd. How do we expect users to know what parameters they need to pass for logp/logcdf to work? several distributions also have alternative parametrizations

[ricardoV94]

Not blocking the PR, but trying to think forawrd. How do we expect users to know what parameters they need to pass for logp/logcdf to work? several distributions also have alternative parametrizations

Users should never call these methods themselves. The user-facing API is pm.logp(rv, value) For more context see #5308

[canyon289]

Users should never call these methods themselves. The user-facing API is pm.logp(rv, value) For more context see #5308

Ah this is where I think you and I saw things differently. These are forms of developer documentation for me so if someone is contributing code in the future this is for them. For instance a number of these docstrings would be useful to me right now as a contributor if these methods needed to change. Thats why Im trying to save them (in some form!)

[ricardoV94]

I would bet a newbie developer would be more confused than enlightened by these broken docstrings...

[canyon289]

This is a really good example. I wouldnt know what lam or alpha are by memory and from the logp calculation below theres not enough math to tell me. Having even just a basic description of the parameters would be helpful mathematically.

The other is the what is allowed as inputs. If I was to write code that called this logp I would know what to pass, and auto type checking would be useful.

In the scope of things I care way more about 1 than I do 2, though both would be nice

[ricardoV94]

This is a really good example of why I don't like it. The return type is completely wrong, should be TensorVariable (Type) not RandomVariable (Op). Also we only test and promise to support TensorVariable inputs, not float or np.ndarray (even though many times they will work)

[ricardoV94]

The parameter information is contained in the main distribution docstring already.

[ricardoV94]

pymc/pymc/distributions/continuous.py

Lines 861 to 868 in d34b557

	mu : tensor_like of float, optional
	Mean of the distribution (mu > 0).
	lam : tensor_like of float, optional
	Relative precision (lam > 0).
	phi : tensor_like of float, optional
	Alternative shape parameter (phi > 0).
	alpha : tensor_like of float, default 0
	Shift/location parameter (alpha >= 0).

[maresb]

Ok, presumably with the pin in #6282, mypy is now passing. Is this ready to merge? (I have not reviewed.)