The featured proof about the sum of Fibonacci numbers divided by 2^n is beautiful.
When I started reading the proof I thought it was a mistake, a mismatch between the theorem to proof and the linked proof. I didn't expect using Kolmogorov axioms to prove this kind of sums. I really enjoyed reading it. I just learned something new today, thanks!
The set of sequences of length n ending in HH (and with no earlier HH) and beginning with a T are in bijection with the set of sequences of length n-1 ending in HH (and with no earlier HH) by the bijection
Also the bijection between sequence of length n ending in HH (and no earlier HH) and beginning with an H are a bijection with the set of sequences of length n-2 ending in HH (with no earlier HH) by the bijection:
def f(s):
assert(s[0] == 'H')
assert(s[1] == 'T') # can't be another H!
def f_inverse(s):
return 'HT' + s
Therefore, since sequences either begin with a T or an H, for n>=2 we see f(n) = f(n-1) + f(n-2).
> Lean mathlib was originally a type checker proof assistant, but now leanprover-community is implementing like all math as proofs in Lean in the mathlib project
Be careful. While a proof in Lean is executable (it is a script, so to speak) it is conceptually a sequence of references to tactics. Writing a Lean proof does involve a highly specialised form of functional programming, but I wouldn't be at all sure that becoming an expert in Lean would improve your programming skills across the board.
Your comment also reminds me of the people who claim that the Curry-Howard isomorphism means "programming is math". It's not a claim that anyone should really be making in good faith. There's a lot more to programming than the lambda calculus.
Verbal skills are apparently more predictive of programming career success than math scores.
Is Quantum Logic the correct propositional logic?
Is Quantum Logic a sufficient logic for all things?
I'd much rather work with machine-checkable proofs; though Lean is not what I've been taught math in either.
Coq-HoTT is written in Coq, not Lean.
A tool that finds the correspondence between proofs as presented and checkable proofs in a reasonable syntax would be helpful, I think.
If I start with
"Why is 2+2=4?" [in this finite ring], I'm not sure how to find the relevant Lean code in Mathlib to prove my bias inductively, deductively, or abductively
> Verbal skills are apparently more predictive of programming career success than math scores.
This is an urban legend inspired by this article [1]. One problem with this research though is that it studies language learning. Not how good a programmer one becomes, and certainly not career success.
I've heard this and always thought it was probably true even setting aside the soft skills part of the job, but that was before data engineering and data scientists were common titles. If it ever was true, the situation is probably more nuanced now than it used to be
I guess it means they're not testing on logic in the math exam, or are verbal scores predictive of coding but not logic scores; maybe it's more of a G factor.
Not all code functions are mathematical functions. An expression can describe a relation that is not a function per the definition like "a function always returns one output for one input".
What I mean is lean can prove things like one of cantors theorems, the proof of which requires you to derive from properties on a function f showing that there exists a function g inverse to f, and show something about the results of calling g.
such a function in lean is considered non-computable by lean because it cannot be evaluated by lean since g has merely been shown to exist.
Many proofs in lean however are computable, just not all.
I don't think SymPy has abstract Function attributes to reason about, but it does have limited reasoning about number classes given e.g. `x = Symbol('x', real=True)`
If there is some sort of e.g. geometric correspondence, it could be possible for a Church-Turing classical computer to compute quantum functions (that return wave functions) that a Church-Turing-Deutsch quantum computer can compute; but otherwise Lean can't compute most quantum circuits either.
Indeed I was always very mystified when people complain about Youtube ads until Youtube started to mess with ad blockers. This made me consider stopping using Youtube altogether but fortunately uBlock Origin catched up.
Agree - and not simply the presence of ads, but the scammy, fraudulent type. I just saw the tiniest “X” to close an ad I’ve ever seen. And clicking it just opened the advertisers site anyway.
That’s not a sustainable strategy, that’s just fraud.
it states
"Amusingly, given that Graham's number is an upper bound, the actual solution to the problem in question, according to certain experts, may well be 6. "
I cannot edit the page but I believe they're up to at least 13 now.
I remember findind this site when solving exercise of creating sign function for Z with arithmetic operators only. I used this[1] page to cheat and reimplement mod in C (by default % is rem) with defined zero. Unfortunately it doesn't helped me yet, but I still like this site.
Their "proof" that there are only 12 solutions to 8 Mutually Non-Attacking Queens on Chessboard is just "That there are only these 12 can be proved by brute force." :/
In my university math departments putnam problem competition (they'd just be on the wall, prize was a $40 giant pizza each week) they would accept the most elegant solution, so if nobody else submitted something better I'd get a pizza for just running a few lines of python.
I'm not gatekeeping proofs here, and I'm glad you got math pizza :) If proofwiki had exhaustively printed all possible arrangements, or the decision tree of constructing them, or if they had even included the code that would do the checking (like, say, https://www.richard-towers.com/2023/03/11/typescripting-the-...), then I would agree it counts. But without even a rough ballpark estimate of possible arrangements to check, asserting "brute force" does not make a proof. If I incorporate understanding of the problem, I can see that at most we need to check 8!, which is reasonable. But if the constraints were not so simple, then we might be dealing with 64-choose-8 cases instead, which is heading into not-reasonable.
They can add the same sentence under every finite fact in their wiki, but then it won't be a proof wiki, it would be a list of numeric facts they checked by brute force and we can either trust them, or check ourselves.
The task proving some statement and the task of finding the shortest, or a "reasonably short" proof, are very different endeavours.
The first is about certainty that a statement is valid ("true"). The other is about simplifying the understanding of _why_ it is valid. Most of the time, you don't care much about the latter.
At current rates, whatever is done on a supercomputer today is done by a cheap pocket-size device just decades later. So, I'm not too worried about this case.
One of the first famous examples of this is the four-coloring theorem. I don't know any serious mathematician who is not certain of that result.
When I started reading the proof I thought it was a mistake, a mismatch between the theorem to proof and the linked proof. I didn't expect using Kolmogorov axioms to prove this kind of sums. I really enjoyed reading it. I just learned something new today, thanks!