Add logprob inference for not operations

[shreyas3156]

What is this PR about?
Implementation of logprob derivation for bitwise 'not' operations as discussed in #6680, using the following logic:
not(gt(x, const), True) -> (gt(x, const), not(True)).

Checklist

• Explain important implementation details 👆
• Make sure that the pre-commit linting/style checks pass.
• Link relevant issues (preferably in nice commit messages)
• Are the changes covered by tests and docstrings?
• Fill out the short summary sections 👇

New features

• Logprob inference for bitwise 'not' Ops.

---

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

[codecov]

Codecov Report

Merging #6689 (fd6ddde) into main (55d915c) will decrease coverage by 1.46%.
The diff coverage is 96.15%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6689      +/-   ##
==========================================
- Coverage   91.99%   90.54%   -1.46%     
==========================================
  Files          95       95              
  Lines       16016    16075      +59     
==========================================
- Hits        14734    14555     -179     
- Misses       1282     1520     +238     

Impacted Files	Coverage Δ
pymc/logprob/binary.py	96.66% <96.15%> (-0.31%)	⬇️

... and 6 files with indirect coverage changes

[ricardoV94]

Looks good, some small tweak suggestion below

[ricardoV94]

Suggested change

	raise TypeError("Base RV should be of type boolean")
	raise TypeError("Base RV should be of type boolean")

We shouldn't raise errors, because another rewrite (including a user custom one) could implement a transformation for this type of variable.

One thing we might want to start doing sooner or later is to add log.debug statements so that users can figure out why didn't pymc figure out the logprob for their expression (where here we could say that bitwise for integer variables is not supported by this rewrite).

[ricardoV94]

Opened an issue #6691

Here we should just return None, which means the current rewrite does not apply

[shreyas3156]

We shouldn't raise errors, because another rewrite (including a user custom one) could implement a transformation for this type of variable.

Understood. I'll replace it to return None.

One thing we might want to start doing sooner or later is to add log.debug statements so that users can figure out why didn't pymc figure out the logprob for their expression (where here we could say that bitwise for integer variables is not supported by this rewrite).

I have a question about this. Since the logprob rewrites are in the IR graph, should the user be exposed to the internal errors? (e.g.: If the value variable is potentially measurable).

[ricardoV94]

Since the logprob rewrites are in the IR graph, should the user be exposed to the internal errors? (e.g.: If the value variable is potentially measurable).

What do you mean by internal errors?

[shreyas3156]

I was thinking of a scenario when we check the potential measurability of the value variables and whether the user would be concerned with the error. But I figured that it has to be the expression defined by the user that would cause the error, so the answer should be yes. It may have been an oversight on my part since I'm still getting acquainted with the use cases of PyMC.

[ricardoV94]

The point I was trying to make is that these rewrites are local. So what looks like something invalid to them, may be valid for another rewrite (ours or provided by the user). So we shouldn't raise any errors ourselves, but simply return None, which states: this rewrite does not apply to this graph.

What I suggested in the linking issue, is that we can issue a log message saying why this local rewrite was not applied, as it can be very useful for the user to understand why the logprob was not derived for their graph.

[shreyas3156]

Okay, I understand now. Thank you so much for clarifying!