Hacker News Reader

Comment by wolfgke | Hacker News Reader

To quote this site: "Review the intuitive definition. Rephrase technical definitions in terms that make sense to you."

I openly admit that the technical definitions are often how I imagined the material intuitively when the material was taught in school. But first when studying mathematics these definitions occured. I really wish that calculus (and the rest of mathematics) would be taught in a much more abstract way in school - it really makes understanding the material much easier since the "intuitive" definitions suffer a lot from being leaky abstractions (and mathematics is all about banging to the boundaries of the definitions until they move or fall down).

View on HN

I'm the opposite (which, I admit, is backwards for a lot of engineers.) I need to have a high-level view to provide a context for the details. It doesn't help me to spend a week on defining and proving integrals without first understanding that the goal is to find the area of a rectangle or circle, or to track planetary motion. Once I see the problem, I can think about how we arrived at the solution, rather than present it as a solution in search of a problem. Newton wanted to describe planetary motion, so he invented calculus (Leibniz too, etc.) to solve it, not the other way around.

> It doesn't help me to spend a week on defining and proving integrals without first understanding that the goal is to find the area of a rectangle or circle

I will only discuss this point (but for your other points similar arguments can be made). So you want to measure some n-dimensional volume? This is a highly non-trivial problem, since it is quite possible to find subsets of R^n where you can't assign volumes in a sensible way:

> https://en.wikipedia.org/wiki/Banach%E2%80%93Tarski_paradox

If you don't care about this subtlety you end up in such a paradox.

So you think hard about how you can define "measureable" in an accurate sense and come up with the definition of a sigma algebra and think about how you can even define measures (say of volume) on a sigma algebra. Because these can be ugly to describe, you will immediately think about how one can describe the sigma algebra and the measure in a more easy way. So you come up with generators and note that the measure is defined uniquely by its value on the generator.

Doing this process on the real line using the Borel sigma algebra/measure is not that complicated (so you solved the problem for the real case). From here it is only a small step to the Lebesgue-Stieltjes integral in R^1 that is really worth doing.

But now you remember that you wanted to compute higher-dimensional volumes. So you ask how can you recycle what you've already done? The answer is obvious: You define product sigma algebras and product measures.

As you have seen (Banach-Tarski_paradox) all this is necessary just to even define volumes. I really know no easier way that is both useful in practise (at least be able to obtain the volume of spheres (i.e. not just "simple objects as simplices")) and avoids the problem that was laid out by Banach and Tarski-

I don't like this attitude at all. Euclid, Archimedes, Newton, Leibniz, Riemann, and many others did a fine job correctly calculating areas, volumes, and so on without need of measure theory.

Why is it so important to avoid the problem laid out by Banach-Tarski on the first go through the concept? We, as a species, did not even realize such a problem existed until about 1920, and yet we still managed to build stuff based on what we knew.

> I don't like this attitude at all. Euclid, Archimedes, Newton, Leibniz, Riemann, and many others did a fine job correctly calculating areas, volumes, and so on without need of measure theory.

The history of mathematics is a history of ever-increasing standards for proofs. "Proofs" that, say, Euler wrote down that were perfectly valid for the standards of their time would probably not accepted in todays standard. I personally also think it's plausible that today's proof standard in "typical" math papers will not be acceptable in 100 years anymore, when they perhaps will additionally have to be computer-checkable (and computer-checked).

The issue of proof is very different from the issue of learning. I thought it was the latter being discussed.

Mathematics is about proofs. Learning mathematics thus means learning about proofs.

I do not agree with your first statement. Mathematics is about developing and studying tools to solve problems. Proofs are only one aspect of that.

> Mathematics is about developing and studying tools to solve problems.

There clearly exist methods for solving problems that have nothing to do with mathematics. This should falsify your thesis.

I think maybe you made a mistake, because the exchange reads like this:

A: Knives are for eating.

B: Eating is only a part of it. Knives are for handling food.

A: You can handle food with a fork. Your claim is false.

Specifically, "math is for solving problems" does not imply "problems are only solved by math".

> I really wish that calculus (and the rest of mathematics) would be taught in a much more abstract way in school

That's valid, but you're probably in a very small minority. I took calculus in high school and then real analysis in college, and I still usually think about calculus geometrically whenever possible.

They should be taught in their historical context. Calculus was a very practical field, with axioms being discovered, and theories written based on engineering need.

A strange opinion: Do you also think that programming languages should be taught in the historical context? If not: How do you think mathematics should be taught this way.

My opinion is clear: One should teach the material in the best modern understanding that is possible. If this is more complicated but worth it this is perfectly fine and even necessary.

Completely agree with this.

I used to marvel/sob quietly at how an entire PhD/lifetime's work could be summarized into a single sentence in a given textbook, but human's single greatest advantage is that we can absorb other people's knowledge and wisdom orders of magnitude faster than it took them to acquire it.

A given human life is finite in length and that length is relatively narrow in distribution. We are able to progress as a race as we don't have to waste time relearning how to start fire or engineer a wheel from first principles, much less derive calculus in the absence of other knowledge. If only we could find ways to teach current maths at a younger age, we would faster raise the next generation of mathematicians!

In particular your last sentence could come from me. :-)

> Do you also think that programming languages should be taught in the historical context?

Not the OP, but: yes, absolutely.

So instead of teaching C in a semester one should teach you

- Fortan

- ALGOL 68

- B

- BCPL

- K&R C (with its historic syntax containing elements that are now disallowed)

- C89/C90

- C95

- C99

- C11

and what reasons there were to introduce the changes/extensions?

My opinion is clear: Teach the most modern version with its best practises and leave away all the historic baggage that is only of historic importance.

Some of those can and should be skipped.

You're also missing a native assembly language.

Programming should be taught from the point of view of writing your own forth interpreter, up through BIOSes, based off of it, then in to higher level languages.

Logical composition, however, should be taught inversely. Take a high level language (SQL comes to mind, yes that's high level in some respects!) and teach how to isolate and logically differentiate between elements.

However I'm also for the more simple base test first.

Show someone a few examples of how to play Mastermind (game), see if it clicks.

Show someone basic register algebra, as one labeled context, and then show them VHDL style flow definition statements as another context. Keep the contexts labeled.

Anyone that can apply those rules to 'play the games' is probably capable of being a programmer; and anyone that doesn't find it fun probably shouldn't /be/ a programmer.

Your approach might make sense: But this is clearly not teaching programming from the historical context.

This might be good for a "History of Programming Languages" course. To teach programming languages in an historical context, is a different task. While teaching the most modern version with its best practices, one could mention that feature X was first used in language L, for example.

> To teach programming languages in an historical context, is a different task.

To present the topic in a historical context the students first have to know what was context/standard at that time, under what circumstances the solutions of their time were developed, whether the restrictions still hold etc. In other words: You would have to include half of a "History of Programming Languages" course, since this is surely not common knowledge.

Reply on news.ycombinator.com