bombastry

The recent book Mathematica by David Bessis attempts to describe this exact topic. One core theme of the book is that math is done by building mental models and using our intuitions that come from. Formalism is then used to shape and refine these models. By spending time developing these models, insights eventually become obvious. These mental models are the essence of mathematics, not theorems. The author explicitly uses neural networks as an example to describe how this negative feedback could work to make these changes to our mental models happen in our brains.

The core premise of the book is to describe how mathematicians work and think and to show that this is a process that everyone can do (although some will be better at it than others). It includes interesting accounts of Grothendieck, Bill Thurston, and Descartes as well as from the author's own research career at Yale and École normale supérieure. The book is targeted at the general reader and at times reads a little like a self-help book, especially in the first third or so. However, I found it to be an enjoyable and fascinating read. It provoked a lot of interesting questions about the nature of learning and provided a framework to begin to answer them (e.g. "How can I have proved something and yet feel no understanding of it?", "How can some people solve problems orders of magnitude faster than other smart people, as if they don't even have to think about it?", "Why do I sometimes watch a presentation on a new topic, follow every step, and come away feeling like I've learned nothing?"(* see except below)). I don't think I'm doing it justice here, so I'll stop by saying I highly recommend it based on your comment.

_______

* I'll use this as an excuse to provide a related excerpt featuring Fields Medalist and Abel Prize winner Jean-Pierre Serre:

One day, I had to give a lecture at the Chevalley Seminar, a group theory seminar in Paris. I didn't have substantial new results to announce, but it was an opportunity to make a presentation even simpler than usual. [...] A couple of minutes before the talk was to start, Serre came in and sat in the second row. I was honored to have him in the audience, but I let him know right off that the presentation might not be very interesting to him. It was intended for a general audience and I was going to be explaining very basic things.

What I didn't tell him, of course, was that his presence was intimidating. Still, I didn't want to raise the level of my talk only to keep him interested. I just kept an eye out to see if he'd taken off his glasses, which would mean he was getting bored and had stopped listening. No worries there—he kept his glasses on till the end.

I gave my presentation as I would have without him there, speaking to the entire audience, especially the students seated in the back, whom I was pleased to see listening and looking like they understood. It was a normal presentation, fairly successful, not very deep but well prepared, clear, and intelligible. At the end of the seminar, Serre came up to me and said—and here I quote verbatim: "You'll have to explain that to me again, because I didn't understand anything."

That's a true story, and it plunged me into a state of profound perplexity.

Apparently, Serre wasn't using the verb to understand the way most people use it. The concepts and reasonings of my talk couldn't really have caused him any difficulty. I'm sure he wanted to say that he understood what I had explained, but he hadn't understood why what I had explained was true.

There are two levels of understanding. The first level consists of following the reasoning step by step and accepting that it's correct. Accepting is not the same as understanding. The second level is real understanding. It requires seeing where the reasoning comes from and why it's natural.

In thinking again about Serre's comment, I realized that my presentation had too many “miracles,” too many arbitrary choices, too many things that worked without my really knowing why. Serre was right; it was incomprehensible. His feedback helped me become aware of a number of very big holes in my understanding of the objects and situations I was working on at the time. In the years that followed, research into explanations for these various miracles allowed me to fill in some of the holes and achieve some of the most important results of my career. (However, some of the miracles remain unexplained to this day.)

But the most troubling aspect was the abruptness, the frankness with which Serre had overplayed his own incomprehension.

The prefix notation may be throwing you off or perhaps you have mistaken the function `bottles` for the string "bottles".

The code `(bottles i)` in the loop is calling the function `bottles` (defined at the top) with the argument `i`. The value of `(bottles 99)` is `(string 99 " bottles")` which evaluates to "99 bottles", as expected.

I really enjoyed the second example of paying Netflix by the second. The blockchain has invented movie rentals.

These books are surprisingly satisfying and fun to work through. The instant feedback from the proof checker makes them feel like a game of logic puzzles.

If you get the word right on your 6th guess, the game still counts it as if you lost in the stats.

I wasn't thinking about that when I commented, but you're absolutely right. I definitely missed the point.

I don't think there is any way to generalize the algorithm in the article to work on the method I described. However I was able to find an alternate algorithm to find the initial node of the cycle. It also has linear time complexity and constant storage, but it requires that the pointers in each node be mutable. It is also worse than Floyd's algorithm in almost every way. The algebra gets a little annoying, so I've just provided the informal algorithm below.

0) Find the meeting point as described above.

1) Find the cycle length.

2) Find the distance to the meeting point k+x (where k is the length of the linear portion and x is the number of nodes from the start of the cycle to the meeting point).

   2a) If the hare speed is double the tortoise speed and the tortoise speed is less than the cycle length, this can be found directly.

   2b) Otherwise, we can send a probe from the head until it reaches the meeting point.

This unfortunately this isn't enough information to find the initial node of the cycle, so more drastic measures are needed.

3) Reverse all of the nodes of the cycle (We can actually do this during step 1 if we want to be more efficient, although some care needs to be taken (e.g. that step 2b is performed first).)

4) Send a probe from the head and count the steps until it reaches the meeting point node. This will have gone k + m - x steps.

5) Now we use some algebra to get x in terms of k and known values. We can substitute this into our equation that gives a known value for k+x (from step 3) to find k.

6) Reverse all the nodes of the cycle so they are back to how they originated.

7) Advance k times to reach the first node of the cycle; return this node.

The additional steps have a linear order complexity with respect to the number of nodes of the linked list. And like the OP algorithm, only a constant amount of storage is necessary, although reversing the list will require a couple more pointers to nodes. I'm not sure if there are many cases where this would perform better, but if they do exist they seem like they would be extremely rare.

If you check every node that the hare enters, you don't need the relative speed to be coprime to the cycle-length. This eliminates the need for the hare and tortoise to finish a round on the same node; the hare passing the tortoise is sufficient evidence to detect a cycle.

This change adds a performance penalty with the extra equality checks, but can reduce the total number of steps in certain contexts (e.g. lists with long cycles that appear at an early node can benefit from a much faster hare).