Skip to content

Conversation

Tragicus
Copy link
Collaborator

@Tragicus Tragicus commented Nov 5, 2024

Motivation for this change

Generalizes the instances on function types to dependent function types. The same generalization is happening in mathcomp (see math-comp/math-comp#1256) and it needs to be done here first for backwards compatibility.
EDIT: WIP because we are waiting for unification features in Coq that make unifying dependent functions work.

Checklist
  • added corresponding entries in CHANGELOG_UNRELEASED.md
  • added corresponding documentation in the headers

Reference: How to document

Reminder to reviewers

move=> cu cv; pose a := u \- lu%:S; pose b := v \- lv%:S.
have eq: (u \* v) =1 (lu * lv)%:S \+ ((lu%:S \* b) \+ (a \* v)).
move=> n; rewrite {}/a {}/b /= [u n+_]addrC [(_+_)*(v n)]mulrDl.
move=> n; rewrite {}/a {}/b /= [u n+_]addrC [(_+_)*(v n)]mulrDl.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
move=> n; rewrite {}/a {}/b /= [u n+_]addrC [(_+_)*(v n)]mulrDl.
move=> n; rewrite {}/a {}/b /= [u n+_]addrC [(_+_)*(v n)]mulrDl.

Next Obligation. by move=> T M f g h; rewrite funeqE=> x/=; rewrite mulrDr. Qed.
Next Obligation.
by move=> T M ; apply/eqP; rewrite funeqE => /(_ point) /eqP; rewrite oner_eq0.
by move=> T M f g h; apply/functional_extensionality_dep => x /=; rewrite addrA.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have funext for non-dependent functional extensionality.
Maybe we should introduce funext_dep for uniformity and to save some typing.

Comment on lines 2681 to 2682
Proof.
by apply/funext => x/=; rewrite mulrC. Qed.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Proof.
by apply/funext => x/=; rewrite mulrC. Qed.
Proof. by apply/funext => x/=; rewrite mulrC. Qed.

move=> df; apply/eqaddoP => _/posnumP[e].
rewrite -nbhs_nearE nbhs_simpl /= dnbhsE; split; last first.
rewrite /at_point opprD -![(_ + _ : _ -> _) _]/(_ + _) scale0r add0r.
rewrite /at_point opprD !add_funE !opp_funE/= scale0r add0r.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks indeed a bit better ^_^.

Proof.
move=> dfc dxf; apply/subr0_eq; rewrite -[LHS]/(_ \- _).
apply/littleo_linear0/eqoP/eq_some_oP => /=; rewrite funeqE => y /=.
move=> dfc dxf; apply/subr0_eq/(littleo_linear0 (f:=GRing.sub_fun _ _))/eqoP.
Copy link
Member

@affeldt-aist affeldt-aist Nov 6, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is desirable to avoid using (f:= ...) because it relies on the naming of a variable that is likely to change. (There are instances of this issue below with df:=.)

Proof.
by elim/big_ind : _ => // ? ? g h ?; apply: differentiableD; [exact:g|exact:h].
elim/big_ind : _ => //[_|? ? g h ?]; first exact/(@differentiable_cst _ 0).
apply: differentiableD; [exact:g|exact:h].
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
apply: differentiableD; [exact:g|exact:h].
by apply: differentiableD; [exact:g|exact:h].

theories/ftc.v Outdated
have DPGFE : {in `]a, b[, (- (PG \o F))%R^`() =1 ((G \o F) * (- f))%R}.
move=> x /[dup]xab /andP[ax xb]; rewrite derive1_comp //; last first.
move=> x /[dup]xab /andP[ax xb].
rewrite (derive1_comp (g:[email protected] R)) //; last first.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe avoid the (g:= ...) syntax if possible.

measurable_fun D g -> measurable_fun D (f \- g).
Proof. by move=> ? ?; apply: measurable_funD =>//; exact: measurableT_comp. Qed.
Proof.
move=> ? ?; apply: measurable_funD =>//; exact: measurableT_comp.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
move=> ? ?; apply: measurable_funD =>//; exact: measurableT_comp.
by move=> ? ?; apply: measurable_funD =>//; exact: measurableT_comp.

Proof.
split=> [|f g|f g]; rewrite !inE/=.
- exact: measurable_cst.
- exact: measurable_cst (1 : rT).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mmmhhh... There are now plenty of lemma applications with blah_cst lemmas that now require an explicit mention of the constant in question. This looks problematic.

Proof. by case: n => [_|n /derivableP]; [rewrite expr0|]. Qed.
Proof.
case: n => [_|n /derivableP]; last by [].
by rewrite expr0; apply/(derivable_cst (1 : R)).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, if I remove the (1 : R) type checking does not seem to terminate. Do you know why?

@affeldt-aist affeldt-aist self-requested a review November 6, 2024 14:21
Copy link
Member

@affeldt-aist affeldt-aist left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the justification for the mandatory addition of constants for the application of blah_cst lemmas? Do we know where the problem comes from?

@affeldt-aist
Copy link
Member

I observe that this PS shares similarities with PR #1379 while the latter is marked as draft. Maybe you intended this one as well to be a draft?

@Tragicus
Copy link
Collaborator Author

Tragicus commented Nov 6, 2024

What is the justification for the mandatory addition of constants for the application of blah_cst lemmas? Do we know where the problem comes from?

cst is not dependent (and can not be), so I can not define the operations on dependent functions using it. Then, when Rocq tries to unify cst ?c with 1 : U -> V, it reduces the problem to fun=> ?c = fun t : U => GRing.one ((fun=> V) t) and then to ?c = GRing.one ((fun=> V) t). This fails because ?c can not use t in its instantiation. I believe I have a solution for that, but it needs to be integrated into Coq, so it will take some time, and the impact looks minor according to the CI.

@Tragicus
Copy link
Collaborator Author

Tragicus commented Nov 6, 2024

I extracted this from the other PR and extended it when I realized I needed to generalize things here first. It is ready for review.

@Tragicus Tragicus changed the title Instances for dependent function types [WIP] Instances for dependent function types Feb 19, 2025
@affeldt-aist affeldt-aist marked this pull request as draft September 24, 2025 09:09
@affeldt-aist affeldt-aist changed the title [WIP] Instances for dependent function types Instances for dependent function types Sep 24, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants