Is the following conjecture: “there does not exist a union closed family on n sets with all elements with frequency (n-1)/2” easier than the Frankl’s union closed sets conjecture?

See this question: https://mathoverflow.net/questions/430993/how-to-prove-that-there-does-not-exist-a-union-closed-family-of-n-sets-with-al?noredirect=1#comment1109221_430993

Also, in (iii) shouldn’t the restriction read “whenever x >= 1 and y >= 1”?

]]>Comment Submission Failure

]]>@jcamilledo — I can reply now to this part of your comment, which I think I understand:

> … if the automate is able to kind of conjecturate that it is an intermediary result, … we would be sometime even more happy that the automate finds that a result is a good “intermediary” candidate, then if the automate is able to proof the intermediary result.

I think you are saying that (especially if a task fails to prove its goal statement, but not only then), it may be useful for it to come up with an “intermediary result” statement which it can neither prove, nor prove would lead to the goal, but which it still thinks would be a useful intermediate to study, as part of studying the goal.

I will guess that a statement would be a “useful intermediate” if (1) it is likely to be easier to solve than the original goal; (2) if solved, that solution process would likely provide some useful insight into how to achieve the original goal.

I agree with that (if I interpreted it correctly). It reminds me of this known advice for a mathematician facing a hard problem: “first solve a related easier problem”.

I am not sure how a machine could purposefully come up with an intermediate statement like that; but in hindsight, it can’t be harder than some of the other things we’re proposing here, since it would be a necessary consequence of those ways working, that this would sometimes happen.

For example, if it’s possible to come up with an intermediate which *is* a good step on the way to a proof of the goal, then it must also be possible to come up with one which *might be* that, but in some cases turns out not to be that. But very likely it would often be easier, and related enough that its solution could be a useful model. Also, at the time of coming up with it, it may be unclear whether or not it will be a useful step in a larger proof.

This reminds me of another comment here in which someone said something like “the first step is to form a mental picture of the situation being examined, and play with it to further develop one’s understanding of it”. That process of playing with it might include coming up with many simpler problems about the same situation, and solving some of them.

Indeed, one definition of “an understanding (of type T) of situation X” is “the ability to efficiently solve any problem about X (which is expressed in a form based on T)”. In other words, a type T of “understanding of X” consists of a set of problem-templates about situations of the same type as X, coupled with an efficient ability to solve any problem of those kinds, about X. (Or perhaps “most problems” rather than “any problems” of those kinds.)

]]>@jcamilledo

I don’t understand your description very clearly, but to the extent I can guess your meaning, I think your ideas are interesting. If you are planning to reorganize your blog post, I will gladly read it after you do that. (I don’t understand french, but I can understand the beginning of your current blog post using google translate, so I will try it that way when you say it’s ready.)

I have not heard of the work of Christophe Chalons, and I’d also be interested to hear more about that work.

]]>As my comment was too long to fit, I used my own blog to answer. I did’t know I had a blog, and I will soon take advantage of it to make the comment more easy to read (I will do an little abstract and put more subtitles…) anyway as it is quite long, I don’t expect to be read yet, so I feel more confortable that it is not a long comment anymore but a page that can be read if wanted.I still wanted to writenotes and thoughts, so it seems like a good compromize : I put ideas but the volume of the text is not anymore kind of “impolite”, as I don’t especially aspect to be read (of course if it is the case I would be very happy!)

]]>]]>Réponse à Tim Gowers, à propos de l’automate [trop long pour un commentaire]

I’m not sure that motivated proof is about motivated prooving, and that, for examaple, showing” where it didn’t work” is an acceptable “motivation” to understand the “natural keys”, but it is also IMHO.

However, it is still a good extremum for the caracterisation of a “motivated proof”, the idea of “explaining the steps” seems to me as if either the proof is not enought motivated, either the explainations are part of the proofs, in this last case, a motivated proof can be very long… why not. The other extremum would be to have a conception of motivated proof (MP) that implies that it should be more or less very close to the shortets proof.

Anyway, the exploration/exploitation of mistakes is, I think, a important point of the process, not so much for the definition of M vs B\M, but for the automate itself.

The idea of giving a library is also imho a good way to parametrize difficulties, and I thing it should be a good thing to use it in an extended way as follow (it has a link with the “mistakes” discussion) :

We can say “library” or “oracle” : it is the data of a “intermediary result” (that we can call a “cut”)that the automate is alowed to use. But “we” know that it is intermediary…. if the automate is able to kind of conjecturate that it is an intermediary result, then it would be a “dual” subject of happyness ,as we would be sometime even more happy that the automate finds that a result is a good “intermediary” candidate, then if the automate is able to proof the intermediary result. So the idea that I have, and that will seam a bit strange, is that we could encourage the automate to MAKE HIS OWN CUTS, without caring “too much” if it is right or wrong. The difficulties are principally included in the “too much”. A good begining for a framework of this idea could be to precize, the most formally as possible, what could be a good cut (some how, independantally of its truth)

I have got three main ideas too bring up the subjcet, I discuted them in a very long comment that I posted yesterday and that were maybe too long to be published, so I will just give the 3 main ideas and eventually discuss them later :

1) use a small set of “mental images” to lead the “cut searching”

2) developpe a “sens of complexity” for the automate, it would be a sens like we have “sight” and “hearing” to evaluate distances

3) exploring the “degrés ludiques” , theory developped by Chalons

————-

By the way have you heard about a result by the same mathematician (Christophe Chalons) that informally sais that “any theorem is the obvious concequnece of some obvious statement” (note the two occurrences of “obvious”, and that “obvious” is formalized in a way that (according too what I’ve been said) is really what we call obvious, the difficulty (the not obvious task) is to find of WHITCH obvious statement, the theorem is an obvious concequence) I will ask for more details, including the formal statement if anyone is intersted

]]>– the data structure of a “motivated proof” (optionally including the full story of its generation);

– how “prover modes” (as discussed in the manifesto) fit into that;

– a “story editor” UI, for developing motivated proofs and their prover hints.

(As in all my comments, everything is merely “IMHO”.)

==

I think the general case of a “motivated proof” has a modular or hierarchical structure, not just the linear structure of a ROBOT proof. This is the same kind of structure as in a normal written proof, if that contains subsections for establishing propositions or lemmas, whose details can be ignored outside them, except for the “output” itself (e.g. the proven sub-theorem). (Within the sections, the structure might be much like that of a ROBOT proof.)

When a motivated proof includes the full story of how it was made, it also needs subsections for goals which were attempted but not achieved. Those would have “failure outputs” which (hopefully) say something about why they failed (which can help guide higher-level decisions in the prover). A reader interested only in learning math from the proof would skip the failed subsections; a reader who wanted to understand the proving process might see their inputs and outputs, but skip their internals; a reader wanting a complete “debugging view” of the prover run would need to see everything inside the failed subsections.

(Likewise, the database of all “motivated proofs” ought to include the ones in which the entire proof failed, though only some readers will want to see those in search results. Strictly speaking, it’s a database of “motivated proof attempts”, some successful.)

==

If the proving algorithm maintained several “mental images” which it periodically worked to improve or expand, or later retried a failed subsection with revised parameters or other new input, the overall structure would be more complex, but should still be understood in a modular/hierarchical way.

==

When a subsection starts running, it has goals (e.g. “prove this” or “prove something of this form”), and several kinds of inputs — the assertions and external data it can use (e.g. theorem libraries), and things affecting the prover algorithm, i.e. “hints”, “skills”, the “mode”, and maybe other parameters.

The nature of those prover algorithm parameters is up for much discussion and experimentation. But it seems clear that, since each subsection is created due to some rule running at a higher level, that rule may want to alter some of those parameters inside that subsection it creates. That would be how “changes of mode” were organized — the mode (or any other parameter) could differ in different subsections, or in a subsection compared to its enclosing section.

==

Finally, a specialized UI for browsing a motivated proof can be used not only for understanding it or debugging the prover, but for developing new hints for the prover — that is, as a “story editor”. The “story” is about “how the prover managed to solve this problem” (or perhaps “how we hope it will solve it someday”); we edit it by adding or changing hints or other parameters (and seeing immediately how they change what happens), or by adding comments about what we hope can happen, perhaps adding hoped-for outputs “by hand” so we can debug later sections of the proof before earlier sections are fully working. (Of course, the UI needs to clearly warn us when the proof contains any hoped-for goal statement that is assumed but not presently achieved. We might then alter some hint, and observe that some parts of the proof work better and others worse.)

A “proof story” might start out as mostly informal comments, just recording how someone thinks a specific problem could be solved. It might be divided into proof sections with formalized intermediate states “assumed”, but with the proving itself replaced by comments about the kinds of hints needed to reach those states. Then working hints could be developed gradually. Once the proof worked, if we still thought the hints were too specific (i.e. they were “cheating”), we could try editing them and getting the proof to work again, perhaps with more steps required as the tradeoff for using a more general “hint”.

]]>gowers wrote, replying to “Anon from May 1st”:

> … the way we think about smallish positive integers is heavily influenced by the kind of “play” you allude to … The short-term challenge that creates for developing a human-style prover is to try to provide the prover with the fruits of that kind of play without requiring it to do the playing and consequent learning for itself.

From your manifesto and other comments, I think your approach to that challenge is to formalize the results of that kind of play in hand-programmed “hints” or “built-in skills”, then construct the prover so it can make use of those, presumably in a flexible way to permit experimentation.

I agree. I think it’s important that the “database of explicitly motivated proofs” can include multiple proofs of the same theorem, in which different sets of hints were used, so their effect can be compared. It’s also desirable for the proofs to be “reproducible” — that is, if the “prover runs” which lead to those proofs can be reconstructed precisely later (by recording their exact inputs, including hint sets used, other parameters, and exact version of the prover itself), so project observers can browse proofs (or the stories of finding them) at any level of detail, and can even create tools to statistically study those stories (e.g. for comparing effects of different hint-sets over large problem sets).

Then instead of arguing about whether use of some hint is “cheating” (which I fear will inevitably be subjective and relative, and often controversial), we can discuss whether it helps many problems or only a few, whether it slows down other problems, whether it can be effectively replaced with other hints which are more primitive or general, etc. We can even discuss whether a hint is “human” or “superhuman”, based on whether it makes the system better than any humans at certain kinds of problems, or if the stories of how it’s being used don’t look “natural”.

(If a project observer doesn’t like a hint, they can contribute a better one, along with new experiments (i.e. new reproducible motivated proofs) showing how their hint affects certain problems in ways they like.)

==

The more advanced question of how a hint can be learned also becomes more definite that way, at least for a hint represented as a formal expression (as opposed to a “built-in skill” represented by an optionally-used software module). It turns into the more concrete question “how could this formally-expressed hint have been invented or discovered from this database of proof-finding-experience”? At some future time, we could even repeat the same experimental process to try out various “hints about how to learn new hints from experience” on a fixed proof-finding-database.

]]>I suggest that a better term would be either “motivated proof”, or (if you think that fails to imply the motivation is included with the proof), “explicitly motivated proof”. (Or maybe there is something still better.)

I think “justified proof” is too likely to be interpreted as just meaning “valid proof” (one with reasoning that ought to be persuasive). That is, any proof in a formal language using an accepted set of axioms (and passing a well-tested proof checker) could be arguably called “justified”; so could a clearly written informal but correct-seeming proof.

]]>Let me try to answer part of your question (in English, as that will be a lot quicker for me). I definitely don’t think that P=NP, though in a way that doesn’t make too much difference to the project at the moment, since even if P=NP we have no idea what an efficient algorithm for solving NP problems could be like, and much more of an idea of how to solve “natural” maths problems, even if there are plenty of mysteries about it.

But your follow-up question about whether there might be some statement that isn’t P=NP but is nevertheless still very interesting aligns with a fantasy I have, which is that it might be possible to identify a complexity class within NP that consists of NP problems with some extra property that makes them feasible. One difficulty with making this fantasy real is to come up with even a conjectured property that doesn’t make that statement trivial and uninteresting — I don’t want to end up saying little more than that a proof is easy to find if it is easy to find, or to say that it’s easy if some particular proof-finding algorithm finds it in a short time (or short expected time if it’s randomized). What I’d like is to identify structural properties of proofs, or rather “fully justified proofs” (that is, proofs together with convincing motivations for the steps) and for it to be a non-trivial theorem that proofs with those properties can be found in reasonable time.

The question about how our physical intuition feeds into our problem-solving ability is of course an important one. I’m hoping to be able to sidestep it for the time being, because it seems difficult to design a model of the world that would be suitable for providing that kind of intuition to a program, but it may be that that will restrict the kinds of problems we can hope to get a program to solve.

]]>I don’t think that the project will hit a brick wall. In fact, I believe the idea is really good and I hope it will succeed. I think logic (and early formalization) was done with a similar goal in mind back in the days. It is unfortunate that it did not help in proving theorems a lot. I find it interesting to ask whether a closer look at our thinking can help with that (solving problems algorithmically).

I just want to highlight that parts of mathematics are “cleaner from humans” than others. I think (even advanced) questions from algebra, like “what are the finite simple groups”, can simply pop up with just playing with numbers/structures/abstraction, noticing stuff and so on.

Meanwhile the Hausdorff question, unless you are guided by human apriori knowledge, is further down the line. For example, it is not immediately obvious that a continuous extension of the rationals, as in the real numbers, is useful. We know that it is a good model for the line, but I would count adding this knowledge as cheating.

Anyways, I’m excited to see what new information this project uncovers about the way we think.

]]>I agree with a lot of this. As an example, the way we think about smallish positive integers is heavily influenced by the kind of “play” you allude to. For example, if the number 1023 comes up in a problem, I will, thanks to a lot of playing with numbers, immediately notice that it is , and although that may be irrelevant, it’s actually quite likely to be helpful, since numbers of that sort of size don’t tend to be one off a power of 2.

The short-term challenge that creates for developing a human-style prover is to try to provide the prover with the fruits of that kind of play without requiring it to do the playing and consequent learning for itself. In the longer term, perhaps one could (almost certainly with the help of machine learning) create a system that could explore and discover “useful number facts” for itself (and similar facts in other domains) and store them in a way that made them accessible at the right moments, but that seems like an ambitious project, though I would guess that it’s one that people are already working on.

It may be that we have a slight difference of opinion in that I think one can set that last challenge aside for the time being and still make substantial progress, whereas I think you think that without it we’ll hit a brick wall fairly soon.

]]>I think our attitudes here are very well aligned!

]]>