0

I come from a mathematical physics background, so I have very little experience with other areas of Math, so what I say may not apply to mathematics research in general obviously (and probably much less for other areas of theoretical sciences). Please let me know if this question is suitable for this site.

In short, what I observed my field of mathematical physics is that most recent advancements generally consists of either finding links between physical models (like percolation, random walks, and spin models), or making an incremental (yet non-trivial) improvement over previous state-of-the-art techniques to solve major open problems. I suspect this to be true for most science fields as well (say theoretical physics or computer science).

I think the latter is exemplified in a very important paper by Duminil-Copin that rigorously establishes the criticality of the self-dual point for the random-cluster model. The paper is almost 30 pages long, but most of it is just basic motivation and introducing standard definitions or classical theorems to set up the main arguments. The core idea is encapsulated in exactly one figure (Figure 6 in the paper), and that is a modified box-crossing argument for percolation models satisfying the FKG inequality. However, to convey this very important argument, the author had to (justifiably) spend much ink on giving context, and I think this is a fundamental inefficiency of the paper-publishing medium.

On the contrary, I find that many software-development principles/techniques may address the inefficiency of paper-publishing, and perhaps they can be implemented in some sort of online system like Github. Note that I'm not suggesting that we should do mathematical research programmatically, or invent a new language that allows us to "code-up" proof. These software-development principles should only pertain to organizing and communicating the mathematical results (and not the act of deriving them). To give a few examples for concreteness.

Reducing code repetition: this one translates to collating and organizing a list of classical or recent results that is verified and deemed useful by most researchers into a "repository". Whenever a researcher wishes to communicate a result that heavily relies of them, they can simply "import" them from the corresponding repositories accepted by the community. Similar to how you would pip install and import numpy for Python projects, instead of rewriting these packages yourself from scratch (which most likely contains errors or be inefficient).

Incremental updates and version control: if one finds an improvement of an existing theorem/technique, then they should "clean-up" the findings and make the minimal changes necessarily to the existing "codebase". The referee process would then be some sort of pull-request review, and the "moderator" can then choose to accept or reject the changes based on correctness and relevance. Of course, this may be very difficult in practice, as it is unclear who that "moderator" should be, especially if the "commit" is exceptionally novel or difficult to understand. Of course, if the commit is later discovered to be incorrect, some sort of version control system would allow it to be easily undone.

Abstraction and inheritance: The act of "finding links between models/areas" would be analogous to a code-refactoring effort, which would better organize the existing "mathematical objects". For instance, the Ising model is a special case of the random-cluster model, so the former can simply subclass from the latter, inheriting the latter's "attributes and methods". Of course, the Ising model has many attributes/representations that the random-cluster model does not have, such as the random-current expansion. To handle this, one can simply add new attributes to the Ising model class without repeating the attributes inherited from the random-cluster model.

If everything goes well, the paper-publishing process would be akin to writing some custom scripts that rely on existing packages. For example, you would organize all the technical lemmas (that are not sufficiently general for committing to a major repo) into utility files, and the "paper" itself would be a main script that contains the actual logic of the proof using these lemmas and packages.

My questions are:

  • Are there already existing systems that attempt to organize scientific research, or at least a very small research topic, into this sort of system? I know about the polymath project, but it's still a bit lacking in terms of the above-mentioned Github-like functionalities.
  • Is this system any practical for mathematical research in general, especially for fields where results are generally less incremental or less problem-solving in nature?
  • How would you think writing textbooks, monographs, or review papers would work under this framework, especially if they are pedagogical in nature?
8
  • It seems that the most important question is missing: Does this system have any chance to work at all in any field of mathematics? The answer is most certainly no, no matter how incremental the results in the field are. It also won't work in mathematical physics. The reason is that the evolution and the writing of new (and also old) maths is a much, much messier process than your suggestion seems to assume. Aug 31 at 6:18
  • (Maybe your second question is similar to the question I mentioned, but it seems to assume that the proposed system will at least work in some fields.) Aug 31 at 6:20
  • @JochenGlueck, thank you for your input. I guess I should have restricted my field to really mathematical physics dealing statistical models (like Ising, GFF, Euclidean fields, etc.) Some of the recent problems are solved by mainly discovering links between these models, or new representations of old ones. This plus careful handling of probabilistic arguments are the main recipes of solving certain open problems
    – PeaBrane
    Aug 31 at 6:27
  • @JochenGlueck, for other fields with a more messier research process. Would you think it's at least possible to maintain a package of classical results (that everyone would agree is correct and relevant), and writing a paper would not necessarily be making incremental commits, but rather building your own custom software not meant to be maintained, etc
    – PeaBrane
    Aug 31 at 6:31
  • 2
    Maintaining code consistency and quality across anything larger in total than a screen or two of code is hard. Look to the successful open source projects out there - without dedicated maintainers who rule with an iron fist, it becomes chaos. Random folks 'simply adding new' stuff to code will render the experiment useless very rapidly.
    – Jon Custer
    Aug 31 at 13:07

1 Answer 1

0

Your approach is the tipical top-down approach of people trying to optimize something already existing. This approach is well known to bring unstable steady state and inefficient systems.

However, you are welcome to publish a paper showing a proof of concept of your novel system of publications, there are many discussions on the failures of the current system and your voice will be listened, if you have the patience of carefully exposing your ideas.

Regarding exposing your ideas, I must note that I am deeply offended you mention GitHub as the archetype of the "central" repository. This denotes either:

  • ignorance of the many subversioning system that have been developed over the years and therefore your refer to the successful commercial one (OP in a comment states

And no, I have not used any other subversioning system (nor do I know of anyone that does)

so I suggest OP to have a look at least to GitLab (to be based on Git), if not even Mercurial to see a different philosophy;

  • typical ego and superiority feelings "of course I know GitHub is just an example, but it is to explain my very important and complex idea to the mass of ignorant".

Don't take it personally, I am just offended by the exposition of your idea, not by the idea or by you.

At last, but not at least, do a deep literature research on what is already being tried, for example regarding your goal of

the paper-publishing process would be akin to writing some custom scripts that rely on existing packages

there are some beautiful tools and trials out there, for example this interactive paper based on Jupyter.

Good luck!

4
  • The discussion about Gitlab has been moved to chat.
    – cag51
    Aug 31 at 14:02
  • Also, this answer does come across rather hostile against the question-asker (e.g., "typical ego and superiority feelings"). I'm sure this was unintentional, but I recommend trying to rephrase a bit to avoid this.
    – cag51
    Aug 31 at 14:05
  • @cag51 Thank you. However, I still believe this answer does not address my question (besides being unnecessarily hostile, unprovoked nonetheless). Also, the resource provided is irrelevant to the question. The question pertains to theoretical research not experimental, and explicitly states that the goal isn't to make Math programmatic.
    – PeaBrane
    Aug 31 at 14:57
  • @PeaBrane - I believe EarlGray is providing what we call a frame challenge; instead of telling you how to do a thing, they invite you to step back and consider whether you are doing the right thing. And there is some attempt to address your question of whether your idea is practical. I understand this may not be what you wanted, but mods do not delete answers (even if they are objectively incorrect); that is left to the voters. Rather, we only delete clear nonsense that does not even try to answer the question. But relax, some other answers are likely to come in if your question stays open
    – cag51
    Aug 31 at 15:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .