aboutsummaryrefslogtreecommitdiff
path: root/mathcomp/field/closed_field.v
AgeCommit message (Collapse)Author
2020-11-20Tuning simplifications using Arguments simpl nomatchCyril Cohen
2020-11-19Removing duplicate clears and turning the warning into an errorCyril Cohen
2020-10-29Switch from long suffixes to short suffixesKazuhiko Sakaguchi
2019-11-22New generalised induction idiom (#434)Georges Gonthier
Replaced the legacy generalised induction idiom with a more robust one that does not rely on the `{-2}` numerical occurrence selector, using either new helper lemmas `ubnP` and `ltnSE` or a specific `nat` induction principle `ltn_ind`. Added (non-strict in)equality induction helper lemmas Added `ubnP[lg]?eq` helper lemmas that abstract an integer expression along with some (in)equality, in preparation for some generalised induction. Note that while `ubnPleq` is very similar to `ubnP` (indeed `ubnP M` is basically `ubnPleq M.+1`), `ubnPgeq` is used to remember that the inductive value remains below the initial one. Used the change log to give notice to users to update the generalised induction idioms in their proofs to one of the new forms before Mathcomp 1.11.
2019-04-26Cleaning Require and Require ImportsCyril Cohen
2018-12-13Adjust implicits of cancellation lemmasGeorges Gonthier
Like injectivity lemmas, instances of cancellation lemmas (whose conclusion is `cancel ? ?`, `{in ?, cancel ? ?}`, `pcancel`, or `ocancel`) are passed to generic lemmas such as `canRL` or `canLR_in`. Thus such lemmas should not have trailing on-demand implicits _just before_ the `cancel` conclusion, as these would be inconvenient to insert (requiring essentially an explicit eta-expansion). We therefore use `Arguments` or `Prenex Implicits` directives to make all such arguments maximally inserted implicits. We don’t, however make other arguments implicit, so as not to spoil direct instantiation of the lemmas (in, e.g., `rewrite -[y](invmK injf)`). We have also tried to do this with lemmas whose statement matches a `cancel`, i.e., ending in `forall x, g (E[x]) = x` (where pattern unification will pick up `f = fun x => E[x]`). We also adjusted implicits of a few stray injectivity lemmas, and defined constants. We provide a shorthand for reindexing a bigop with a permutation. Finally we used the new implicit signatures to simplify proofs that use injectivity or cancellation lemmas.
2018-12-11Fix some new warnings emitted by Coq 8.10:Anton Trunov
``` Warning: Adding and removing hints in the core database implicitly is deprecated. Please specify a hint database. [implicit-core-hint-db,deprecated] ```
2018-12-04Merge pull request #253 from anton-trunov/argumentsGeorges Gonthier
Document parameter names whenever possible
2018-12-04Document parameter names whenever possibleAnton Trunov
As suggested by @ggonthier [here](https://github.com/math-comp/math-comp/pull/249#pullrequestreview-177938295) > One of the design ideas for the `Arguments` command was that it would allow to centralise the documentation of the application of constants. In that spirit it would be in my opinion better to make as much use of this as possible, and to document the parameter names whenever possible, especially that of implicit parameters. and [here](https://github.com/math-comp/math-comp/pull/253#discussion_r237434163): > As a general rule, defined functional constants should have maximal prenex implicit arguments, as this facilitates their use as arguments to functionals, because this mimics the way function constants are treated in functional programming languages with Hindley-Milner type inference. Conversely, lemmas and theorems should have on-demand implicit arguments, possibly interspersed with explicit ones, as it's fairly common for other lemmas to have universally quantified premises; also, this makes it easier to specify such arguments with the apply: tactic. This policy may be amended for lemmas that are used as functional arguments, such as reflection or cancellation lemmas. Unfortunately there is currently no easy way to tell Coq to use different defaults for definitions and lemmas, so MathComp sticks to the on-demand default, as there are significantly more lemmas than definition, and use the Prenex Implicits to redress matters in bulk for definitions. However, this is not completely systematic, and is sometimes omitted for constants that are not used as functional arguments in the library, or inside the sections in which the definition occur, since such commands need to be repeated after the section is closed. Since Arguments commands should document the intended constant usage as best as possible, they should follow the implicits policy - even in cases such as this where the Prenex Implicits had been skipped.
2018-11-26correct and improve signature and documentation of FieldMixinGeorges Gonthier
Documentation of FieldUnitMixin and FieldMixin corrected to reflect actual arguments, with mulVf and inv0 made explicit arguments for FieldMixin (they were implicit due to the extended signature of Field.mixin_of). Type of FieldMixin changed to a convertible variant to facilitate construction of on-the-fly in-proof construction of fieldType instances, exposing an idomainType instance.
2018-10-26moving countalg and closed_field aroundCyril Cohen
- countalg goes to the algebra package - finalg now get the expected inheritance from countalg - closed_field now contains the construction of algebraic closure for countable fields (previously in countalg) - proof of quantifier elimination for closed field rewritten in a monadic style
2018-02-06fixing things that @ggonthier and @ybertot spotted and some I spottedCyril Cohen
2018-02-06running semi-automated linting on the whole libraryCyril Cohen
2016-11-07update copyright bannerAssia Mahboubi
2015-07-28update copyright bannerEnrico Tassi
2015-07-17Updating files + reorganizing everythingCyril Cohen
2015-04-09field for v8.5Cyril Cohen
2015-03-09Initial commitEnrico Tassi