feat(Tactic/Positivity): make positivity work for types that are not partial orders#35394
feat(Tactic/Positivity): make positivity work for types that are not partial orders#35394HugLycan wants to merge 9 commits intoleanprover-community:masterfrom
Conversation
Welcome new contributor!Thank you for contributing to Mathlib! If you haven't done so already, please review our contribution guidelines, as well as the style guide and naming conventions. We use a review queue to manage reviews. If your PR does not appear there, it is probably because it is not successfully building (i.e., it doesn't have a green checkmark), has the If you haven't already done so, please come to https://leanprover.zulipchat.com/, introduce yourself, and mention your new PR. Thank you again for joining our community. |
✅ PR Title Formatted CorrectlyThe title of this PR has been updated to match our commit style conventions. |
PR summary d048652946Import changes for modified filesNo significant changes to the import graph Import changes for all files
Declarations diff
You can run this locally as follows## summary with just the declaration names:
./scripts/declarations_diff.sh <optional_commit>
## more verbose report:
./scripts/declarations_diff.sh long <optional_commit>The doc-module for No changes to technical debt.You can run this locally as
|
Make positivity work for types that are not partial orders
Most PositivityExt haven't been updated for non partial order cases yet. They will be updated in the later PR.
Strictnessnow depends onOption Q(PartialOrder $α)instead ofQ(PartialOrder $α), and the constructors ofStrictnessnow have their order typeclass arguments. In order to helpQqsynth instances property, we have to moveassertInstancesCommuteto inner branch, manually addhaveI'or explicitly pass the order typeclass instance into.positive/.nonnegative.