feat: lemmas about Nat.toDigits#1267
Conversation
|
Please summarize the discussion rather than just linking to it. That makes it easier for people here to catch up. |
|
|
||
| namespace Nat | ||
|
|
||
| theorem isDigit_digitChar_iff_lt : n.digitChar.isDigit ↔ (n < 10) := |
There was a problem hiding this comment.
Arguably this should be
| theorem isDigit_digitChar_iff_lt : n.digitChar.isDigit ↔ (n < 10) := | |
| @[simp] | |
| theorem isDigit_digitChar : n.digitChar.isDigit = n.blt 10 := |
There was a problem hiding this comment.
Nat.blt though..? I'd rather do decide (n < 10) in that case
There was a problem hiding this comment.
I don't mind much about the RHS, I just assumed that blt was simp-normal
There was a problem hiding this comment.
Nat.blt is only used in the construction of DecidableLT Nat (and in some other places where fast kernel reduction matters)
There was a problem hiding this comment.
I'm surprised that there's not a simp lemma in either direction
|
Mathlib CI status (docs):
|
|
I've added the lemma |
Nat.toDigits and Char.isDigitNat.toDigits
|
I've added the lemma |
|
I think there should be some general characterisation lemmas to avoid using theorem toDigits_base_zero (n : Nat) : toDigits 0 n = [n.digitChar]
theorem toDigits_base_one (n : Nat) : toDigits 1 n = List.replicate (n + 1) '0'
theorem toDigits_zero (b : Nat) : toDigits b 0 = ['0']
theorem toDigits_of_lt_base (h : n < b) : toDigits b n = [n.digitChar]
theorem toDigits_of_base_le (h : 1 < b) (h' : b ≤ n) : toDigits b n = toDigits b (n / b) ++ [(n % b).digitChar]Then some of the others might be able to be proven with these instead of |
|
@Rob23oba Is it desirable to have characterisation lemmas for bases |
|
You're right; but at the same time, we characterize garbage values for division etc. I agree that this is a bit different though, so let's maybe wait with those two until there is consensus on leanprover/lean4#8686. |
|
I'm on the fence about this PR. Several lemmas belong in I do think it's important to have theorems to prove facts about these. I would recommend a different approach:
I don't think string representation is too relevant. For example, Batteries will eventually need to support Base-64 encoding, which is incompatible with traditional representation in bases 2, 8, 10, 16. |
Isn't this basically the |
|
Perhaps. If so, that should make it easier to adapt this PR! |
|
I'm not sure I understand the proposal; surely we don't want a third version of this function? Is the suggestion to upstream |
|
I checked out @marcusrossel How urgent is your need for this PR? |
|
@fgdorais not urgent at all :) |
|
WIP PR #1293 adds the functions I'm thinking about. The @marcusrossel If you are still inclined to help, you can start reviewing this PR when you have time. The parts leading up to |
|
I'll be rather busy the next 2 weeks, but if it's not too late by then, I'll take a look :) |
|
Uh, @fgdorais was this merge intentional? |
|
Yes! We can improve this later and it doesn't hurt to have it now. |
As discussed in leanprover/lean4#8673.