Skip to content

Proposal: Use sigma types with partial proofs for solution witnesses #195

Description

@LasseBlaauwbroek

I wonder if the current structure of formalizations where an answer must be synthesized is the best.

Instead of having a 'solution' definition that needs to be filled in, wouldn't it be more convenient if it were encoded with a sigma type? Then, for contestants who cannot synthesize the answer, the witness can be pre-chosen by filling in part of the proof:

Theorem putnam_1963_b1 : { P : int -> Prop | forall (R : realType) (a : int), 
  (('X^2 - 'X + a%:~R) : {poly R}) %| ('X^13 + 'X + 90) <-> P a }.
Proof.
exists (fun i : int => i = 2).
Admitted.

Instead of:

Definition putnam_1963_b1_solution (i : int) : Prop := i = 2.
Theorem putnam_1963_b1 (R : realType) (a : int) :
 (('X^2 - 'X + a%:~R) : {poly R}) %| ('X^13 + 'X + 90) <-> putnam_1963_b1_solution a.

In addition to this solution feeling more natural, it also makes things more consistent: The problem discussed in #183 also has a sigma type that finds a certain bound. Although the text description doesn't make it explicit, this sigma type must still be synthesized with a concrete number. (Unless there is some crazy situation where it can be proven non-constructively, but that seems unlikely.)

Many of the definitional witnesses also do not seem correct, especially the ones that concern propositions:

Definition putnam_1988_b2_solution := True.
Theorem putnam_1988_b2
: (forall (a: R), a >= 0 -> forall (x: R), pow (x + 1) 2 >= a * (a + 1) ->
pow x 2 >= a * (a - 1)) <-> putnam_1988_b2_solution.

If I'm allowed to fill in this solution myself, I can easily prove the theorem by just making the solution a copy of the theorem. Instead, it should again be encoded as a sigma type:

Require Import Reals Coquelicot.Coquelicot.
Open Scope R.

Definition decidable P := {P} + {~P}.

Theorem putnam_1988_b2 : decidable 
  (forall (a: R), a >= 0 -> forall (x: R), pow (x + 1) 2 >= a * (a + 1) ->
    pow x 2 >= a * (a - 1)).
Proof.
left.
Admitted.

I would propose the same thing for Lean.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions