Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Progress table.v #29

Open
wants to merge 1 commit into
base: table
Choose a base branch
from
Open

Progress table.v #29

wants to merge 1 commit into from

Conversation

pi8027
Copy link
Member

@pi8027 pi8027 commented Nov 27, 2020

  • Lemmas about lindex and rindex are relocated since I had to use some of them for sequences of extended values.
  • Proved ext_inF and lrindex_notin.

Comment on lines +620 to +627
move=> t /andP []; case: (ltngtP i (size s)) => [lt_is|lt_si|->].
- rewrite -lindex_gt -?rindex_le //= ?ltnS ?size_map ?(ltnW lt_is) //.
move=> + ge_i; apply: contra_leqF => ts; move: ge_i.
by rewrite lindex_in ?rindex_in ?sorted_map ?mem_map ?map_inj_uniq.
- by rewrite nth_default //= size_map.
- move=> + _; apply: contra_ltF => ts.
rewrite -lindex_le //= ?ltnS ?size_map //.
by rewrite -(size_map Fin) -has_find has_map; apply/hasP; exists t => /=.
Copy link
Member

Choose a reason for hiding this comment

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

I have an unpushed commit, does this work?

Suggested change
move=> t /andP []; case: (ltngtP i (size s)) => [lt_is|lt_si|->].
- rewrite -lindex_gt -?rindex_le //= ?ltnS ?size_map ?(ltnW lt_is) //.
move=> + ge_i; apply: contra_leqF => ts; move: ge_i.
by rewrite lindex_in ?rindex_in ?sorted_map ?mem_map ?map_inj_uniq.
- by rewrite nth_default //= size_map.
- move=> + _; apply: contra_ltF => ts.
rewrite -lindex_le //= ?ltnS ?size_map //.
by rewrite -(size_map Fin) -has_find has_map; apply/hasP; exists t => /=.
rewrite -(@lindexE i t); last by rewrite inE t_gt ltW.
by apply: contraTF => /mem_rnext->; rewrite ltxx.

Copy link
Member Author

Choose a reason for hiding this comment

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

@CohenCyril There is no lemma lindexE. Do you mean lindex_eq?

Copy link
Member Author

Choose a reason for hiding this comment

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

mem_rnext is also missing.

Copy link
Member

Choose a reason for hiding this comment

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

I need to check what I had, I think I have 5 different variations son my hard drive, and I need to decide which one of them is actually useful...

Copy link
Member

Choose a reason for hiding this comment

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

I think I waited for the new interval.v to start anew

Copy link
Member

Choose a reason for hiding this comment

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

because in the current state, I need a few variations snext, anext and stuff, whereas providing an interval bound would explain whether or not we want to include the starting point or not in the search!

Copy link
Member

Choose a reason for hiding this comment

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

There would be a unique next b function such that if b is BLeft x it includes x and otherwise not...
I'm quite excited about that and I wished to continue exploring this direction.

Copy link
Member

Choose a reason for hiding this comment

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

(as soon as mathcomp 1.12 got merged)

Copy link
Member Author

Choose a reason for hiding this comment

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

because in the current state, I need a few variations snext, anext and stuff, ...

Sure. I see this is confusing and frustrating😂


Lemma lrindex_notin i :
{in [pred t | [i] < t%:x < [i.+1]], forall t, t \notin s}.
Proof. (* by move=> x /lindex_inF->. Qed. *) Admitted.
Proof. by move=> x /ext_inF ->. Qed.

Lemma lindex_next t tnext : anext t = tnext%:x -> lindex s tnext = lindex s t.
(* Proof. by move=> sneq; apply: lindexE; rewrite inE -sneq lexx andbT. 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 move=> sneq; apply: lindexE; rewrite inE -sneq lexx andbT. Qed. *)
Proof. by move=> sneq; apply: lindexE; rewrite inE -sneq lexx andbT. Qed.

Comment on lines 518 to +519
Lemma in_aprev t : aprev t \in -oo :: map Fin s.
Proof.
by rewrite aprevE; case: ifPn => [ts|_]; rewrite ?in_sprev// in_cons mem_map.
Qed.
Proof. by apply: mem_nth; rewrite /= ltnS size_map rindex_size. Qed.
Copy link
Member Author

@pi8027 pi8027 Nov 27, 2020

Choose a reason for hiding this comment

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

Remark: in_aprev and in_anext (below) do not require s to be sorted, but they accidentally required this assumption (by using aprevE?) in the previous version. We should reshuffle sections or declare Argument commands to avoid this kind of issue.

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