Module docstring
{"# Typeclasses for (semi)groups and monoids
In this file we define typeclasses for algebraic structures with one binary operation.
The classes are named (Add)?(Comm)?(Semigroup|Monoid|Group), where Add means that
the class uses additive notation and Comm means that the class assumes that the binary
operation is commutative.
The file does not contain any lemmas except for
- axioms of typeclasses restated in the root namespace;
- lemmas required for instances.
For basic lemmas about these classes see Algebra.Group.Basic.
We register the following instances:
Pow M ℕ, for monoidsM, andPow G ℤfor groupsG;SMul ℕ Mfor additive monoidsM, andSMul ℤ Gfor additive groupsG.
Notation
+,-,*,/,^: the usual arithmetic operations; the underlying functions areAdd.add,Neg.neg/Sub.sub,Mul.mul,Div.div, andHPow.hPow.
","### Design note on AddMonoid and Monoid
An AddMonoid has a natural ℕ-action, defined by n • a = a + ... + a, that we want to declare
as an instance as it makes it possible to use the language of linear algebra. However, there are
often other natural ℕ-actions. For instance, for any semiring R, the space of polynomials
Polynomial R has a natural R-action defined by multiplication on the coefficients. This means
that Polynomial ℕ would have two natural ℕ-actions, which are equal but not defeq. The same
goes for linear maps, tensor products, and so on (and even for ℕ itself).
To solve this issue, we embed an ℕ-action in the definition of an AddMonoid (which is by
default equal to the naive action a + ... + a, but can be adjusted when needed), and declare
a SMul ℕ α instance using this action. See Note [forgetful inheritance] for more
explanations on this pattern.
For example, when we define Polynomial R, then we declare the ℕ-action to be by multiplication
on each coefficient (using the ℕ-action on R that comes from the fact that R is
an AddMonoid). In this way, the two natural SMul ℕ (Polynomial ℕ) instances are defeq.
The tactic to_additive transfers definitions and results from multiplicative monoids to additive
monoids. To work, it has to map fields to fields. This means that we should also add corresponding
fields to the multiplicative structure Monoid, which could solve defeq problems for powers if
needed. These problems do not come up in practice, so most of the time we will not need to adjust
the npow field when defining multiplicative objects.
","### Design note on DivInvMonoid/SubNegMonoid and DivisionMonoid/SubtractionMonoid
Those two pairs of made-up classes fulfill slightly different roles.
DivInvMonoid/SubNegMonoid provides the minimum amount of information to define the
ℤ action (zpow or zsmul). Further, it provides a div field, matching the forgetful
inheritance pattern. This is useful to shorten extension clauses of stronger structures (Group,
GroupWithZero, DivisionRing, Field) and for a few structures with a rather weak
pseudo-inverse (Matrix).
DivisionMonoid/SubtractionMonoid is targeted at structures with stronger pseudo-inverses. It
is an ad hoc collection of axioms that are mainly respected by three things:
* Groups
* Groups with zero
* The pointwise monoids Set α, Finset α, Filter α
It acts as a middle ground for structures with an inversion operator that plays well with
multiplication, except for the fact that it might not be a true inverse (a / a ≠ 1 in general).
The axioms are pretty arbitrary (many other combinations are equivalent to it), but they are
independent:
* Without DivisionMonoid.div_eq_mul_inv, you can define / arbitrarily.
* Without DivisionMonoid.inv_inv, you can consider WithTop Unit with a⁻¹ = ⊤ for all a.
* Without DivisionMonoid.mul_inv_rev, you can consider WithTop α with a⁻¹ = a for all a
where α non commutative.
* Without DivisionMonoid.inv_eq_of_mul, you can consider any CommMonoid with a⁻¹ = a for all
a.
As a consequence, a few natural structures do not fit in this framework. For example, ENNReal
respects everything except for the fact that (0 * ∞)⁻¹ = 0⁻¹ = ∞ while ∞⁻¹ * 0⁻¹ = 0 * ∞ = 0.
","We initialize all projections for @[simps] here, so that we don't have to do it in later
files.
Note: the lemmas generated for the npow/zpow projections will not apply to x ^ y, since the
argument order of these projections doesn't match the argument order of ^.
The nsmul/zsmul lemmas will be correct. "}