Better coverage for float32 tests

[ferrine]

fix #6779

Bugfixes

• Fix the issue when float32 mode breaks Dirichet distribution
• enforce float32 tests to not create float64 variables

---

📚 Documentation preview 📚: https://pymc--6780.org.readthedocs.build/en/6780/

[codecov]

Codecov Report

Merging #6780 (55d6c31) into main (f91dd1c) will increase coverage by 0.00%.
The diff coverage is 100.00%.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #6780   +/-   ##
=======================================
  Coverage   91.89%   91.89%           
=======================================
  Files          95       95           
  Lines       16181    16185    +4     
=======================================
+ Hits        14870    14874    +4     
  Misses       1311     1311           

Impacted Files	Coverage Δ
pymc/logprob/transforms.py	94.28% <100.00%> (+0.04%)	⬆️

[ferrine]

@ricardoV94 some errors seem weird to me, any idea how they could emerge?

[ricardoV94]

Should be enough to request the model.logp()? No point in compiling and evaluating once if you're not checking the results

[ricardoV94]

@ricardoV94 some errors seem weird to me, any idea how they could emerge?

I think some change with the latest PyTensor release, probably with __repr__ changes given the failure

[ricardoV94]

This is actual a change to the SimplexTransform, we should test that directly, and not via the Dirichlet? Another transform that I think will upcast to float64 is the ZeroSumNormal because it uses the shape of the value as well

[ferrine]

This is actual a change to the SimplexTransform, we should test that directly, and not via the Dirichlet? Another transform that I think will upcast to float64 is the ZeroSumNormal because it uses the shape of the value as well

I'll change that in the test then

[ferrine]

@ricardoV94 I looked into how transforms are checked with float32 mode, they do not. And the float32 tests that exist do not check float32 condition properly, they still allow float64 subgraphs graphs. I bet that float32 tests should be more strict that they are now.

[ricardoV94]

@ricardoV94 I looked into how transforms are checked with float32 mode, they do not. And the float32 tests that exist do not check float32 condition properly, they still allow float64 subgraphs graphs. I bet that float32 tests should be more strict that they are now.

Feel free to make the float32 job more restrictive. Just keep in mind we shouldn't throw random things into those float32 jobs, but only tests that actually matter.

[ferrine]

The real cause of the issue was actually here

The transforms did not respect the original dtype

[ferrine]

I added a check that backward(forward(x)) keeps the original tensortype. It seems to catch the intended bug

[ricardoV94]

Looks good.

The first failing test seems unrelated, can open an issue and rerun or see if it can be seeded.

[ricardoV94]

Also failing with the new numpy deprecation, should be a simple fix to replace np.product by np.prod (but should be a distinct commit, or if not, PR)

[ferrine]

just in case, float32 was not checked in the CI so the previous tolerance was not taken in account