Comment by 6gvONxR4sf7o | Hacker News Reader

Comment by 6gvONxR4sf7o | Hacker News Reader

> Proving that something is impossible is a powerful act of mathematics. It shifts our perspective from that of rule follower to that of rule enforcer. And to enforce the rules, you must first understand them. You need to know not just how to apply them, but when they don’t apply. And you also need to be on the lookout for situations where rules might conflict with one another. Our octagon exploration exposes the interplay between polygons, convexity, right angles and angle sums. And it highlights how S = (n – 2) × 180º isn’t just a formula: It’s one condition in a world of competing conditions.

This paragraph puts to words something I’ve been mulling over for decades. Looking back to math class, or just looking at any discussion of math education, there’s always a discussion about students who just memorize and plug in the formulas, mentioned as the kinds of students who don’t understand what they’re doing. But that’s an incomplete explanation of what those students are missing that I believe the quoted paragraph completes.

It’s not about knowing how to apply a formula. It’s about understanding a formula as a property of the system you’re working with. It’s a great insight and one I’m probably going to mull over for a long while.

There's a story about when Gauss was a kid - a teacher asked the class to add up all the numbers between 1 and 100. Most kids licked their pencils and started working out the sum the hard way. Gauss immediately intuited that 0 could be paired with 100, 1 could be paired with 99, 2 could be paired with 98... and the total was obvious.

That kind of Gauss-level insight doesn't seem to be about properties so much as about understanding the relationships that define a domain - and being able to view problems in a kind of conceptual relationship space which can generate insights that massively simplify simple problems, and make harder problems tractable at all.

I remember school math was mostly rote learning, but some problems required that creative insight. Academic math seems to lean more heavily on creative insights.

Software dev is similar. You can always do things the hard way, but it takes a certain kind of insight to see time-saving shortcuts and simplifications that cut right to the heart of a problem. I suspect some people have a natural talent for that insight, while others are more likely to take the long way to a solution.

Gauss turned a O(n^2) problem into O(1)

The naive version is just O(n), right?

Addition is O(log n), so the naive version is O(n log n).

Gauss would have used a pre-[1960](https://en.wikipedia.org/wiki/Karatsuba_algorithm) multiplication algorithm, with complexity at best O((log n) ^ 2).

Using an algorithm discovered in 2019 (cf. Harvey and van der Hoeven), it's possible to multiply in O(log n * log log n), if you have a lot of time. This is presumably optimal.

Sure, or you just define the input (the n) to be the number of digits in (the logarithm of) the number you’re summing up to. That’s generally how people talk about big O notation when it comes to basic arithmetic operations, mostly because we’re usually talking about computers with constant-time instructions for basic arithmetic operations (granted, only up to the maximum integer or float supported by the software).

"Young man, in mathematics you don't understand things. You just get used to them." John Von Neumann to Felix Smith

One level of mathematical understanding further would be to understand which properties (or even concepts) are the necessary consequences of other properties.

To given an example: the Pythagorean theorem, the parallelogram law, angles, transposes etc. are all properties/concepts a space has because it has an inner product.

> To given an example: the Pythagorean theorem, the parallelogram law, angles, transposes etc. are all properties/concepts a space has because it has an inner product.

Could you elaborate a bit? This sounds really interesting.

The axioms for a vector space and an inner product are exactly what you need to derive a full formal proof of all those.

Well in short those properties all have (generalized) definitions that rely on the inner product one way or another. Denoting the inner product as <x,y> you get:

Pythagoras: <x,y> = 0 implies <x+y, x+y> = <x,x> + <y,y>.

Paralellogram: 2(<x,x> + <y,y>) = <x+y, x+y> - <x-y, x-y>

Angles: cos(angle from x to y) = <x,y> / sqrt(<x,x><y,y>).

Transpose: x^T is the dual vector defined by: x^T(y) = <x,y>.

the last one is especially subtle because most people think you can get the transpose by just flipping the vector, which is technically true but means you're basing your results on a possibly arbitrary choice of basis.

As an example of why knowing these relations is useful, imagine you want to measure angles on a map, then you might notice that there's no easily identifiable inner product, and indeed just measuring angles in an arbitrary projection will give different results depending on which projection you happen to be using. The trick is to go back to 3D space and measure the angles there (relying on the canonical inner product of 3D space) or to use a projection that preserves those angles like Mercator.

As another example conjugate gradient descent works better by using directions that are orthogonal through a more natural inner product rather than ones that just happen to be orthogonal because of your choice of basis.

Reply on news.ycombinator.com