[HN Gopher] Difficult math is about recognizing patterns
___________________________________________________________________
Difficult math is about recognizing patterns
Author : klevertree
Score : 26 points
Date : 2021-08-09 20:49 UTC (2 hours ago)
(HTM) web link (get21stnight.com)
(TXT) w3m dump (get21stnight.com)
| wombatmobile wrote:
| Don't most experts in most domains work the same way -
| recognising patterns they've seen before?
|
| That's why an expert can charge so much for 1 hour of time. It is
| more valuable than days or weeks or months of a non-expert's time
| who doesn't have the library and can't recognise the pattern.
| jstx1 wrote:
| I mean "recognising patterns" is a such broad term that you can
| use it to describe pretty much any mental skill.
| resters wrote:
| A lot of math is taught in a sloppy way, which thwarts the
| pattern recognition progress in brains trying to learn it.
|
| Programming is significantly easier than math (for something
| equivalently complex) because of things like syntax checking and
| compiler/interpreter errors. This speeds up the pattern
| recognition process in the human brain.
|
| People who are identified as being skilled at math or programming
| at a relatively early age are usually those who understood it in
| spite of the teacher/curriculum, so the ability comes as a
| surprise.
|
| But many such people do not go on to distinguish themselves in
| either field in any way. There are always things that come easily
| to one person vs another, but in math and programming, the early
| birds are typically the only ones whose interest in the subject
| isn't destroyed by the teaching methods (because the learning
| happened in spite of them).
| JacobiX wrote:
| In discrete mathematics (combinatorics) there are definitely some
| tools and techniques but seemingly every problem is unique, I'm
| not quite sure that pattern matching is very useful in this
| subfield of mathematics ?
| Ericson2314 wrote:
| That's why combinatorics is a bit of black sheep :D
| paulpauper wrote:
| Combinatorics is just counting but can be so hard finding the
| shortcuts
| contravariant wrote:
| Yeah this view that it's all pattern matching isn't too
| helpful. I find it more helpful to consider mathematics the art
| of generalization.
|
| Discrete math is frequently about things with very little
| structure (e.g. graph theory, where you basically just have
| _any_ binary relation), so inevitably ends up trying to prove
| things that are _way_ too general. The flipside is that those
| theorems do tend to crop up everywhere.
| tarxzvf wrote:
| Everything is pattern matching (or memorization). You can use
| this approach to half-automate the solution to a known existing
| class of problems, but how do you come up with anything new? How
| did Paul Cohen came up with the forcing technique? Who figured
| out probabilistic proofs as a possible vector of attack?
|
| "Both these properties, predictability and stability, are special
| to integrable systems... Since classical mechanics has dealt
| exclusively with integrable systems for so many years, we have
| been left with wrong ideas about causality. The mathematical
| truth, coming from non-integrable systems, is that everything is
| the cause of everything else: to predict what will happen
| tomorrow, we must take into account everything that is happening
| today.
|
| Except in very special cases, there is no clear-cut "causality
| chain," relating successive events, where each one is the (only)
| cause of the next in line. Integrable systems are such special
| cases, and they have led to a view of the world as a
| juxtaposition of causal chains, running parallel to each other
| with little or no interference."
|
| - Ivar Ekeland
| mkl wrote:
| Mathematics is the study of patterns, any kind of pattern, in
| anything. "Difficulty" of maths problems is a kind of measure of
| how well you know the patterns involved (which is related to how
| good our notation, terminology, and visualisations for them are).
| That means research developing brand new maths or applying it to
| new problems is often difficult, because no one knows the
| patterns yet, or has good ways of describing them.
| bob1029 wrote:
| > What's important to recognize is that these same attributes
| apply across all levels of math.
|
| Functional/Relational programming models are just a trivial layer
| on top of math. Everything is pattern recognition at the end of
| the day.
|
| Domain modeling is the logical extension of building standardized
| "patterns" that can be leveraged for rapidly building &
| replicating similar ideas.
|
| Using good modeling techniques is the most important thing for
| managing complex systems. If you aren't sure, you can always
| start modeling at 6th normal form, then walk it back to 3NF as
| the various pieces start to make sense together. If you have your
| domain in 6NF and are using purely functional/relational
| programming, there are mountains of mathematical guarantees you
| can make about the correctness of your software. For instance,
| 6NF gets rid of null. It forces you to deal with the notion of
| optional facts using 0..1-1 relations and applicable query
| constraints.
| saeranv wrote:
| Is there some high-level mathematical way to interpret these
| normal forms?
|
| I am not familiar with relational databases and just googled
| database normalization to get a kind of crude idea of what you
| are saying, but all the examples I find don't seem to give some
| high-level mathematical interpretation of database
| normalization. And it seems like there should be one (I could
| be way off here) based on how you are talking about forms here.
| Ericson2314 wrote:
| My guess is that stuff is kinda iffy from a math standpoint.
| Relational databases are good but I've long suspected the
| theory needs to be overhauled a bit as we've gotten a lot
| better at connecting CS to math foundations than in the
| 1970s. (And indeed math foundations is itself getting better
| from that process.)
| gyam wrote:
| I want to learn these. How do I start learning good modelling
| techniques? Are the NFs you're referring to is same as in DB
| design? If so, how does that translate to general code/system
| design. Any pointers you can provide for learning material,
| concepts, or books will be greatly appreciated. Thanks!
| Ericson2314 wrote:
| The Codd 1971 stuff on Wikipedia looks like a mess, and I
| think the original is propbably a bit crufty too (though I
| don't want to disrespect the old masters, SQL was a high
| water mark of business thinking about computing in many
| ways).
|
| I would follow the citations of
| https://ncatlab.org/nlab/show/lens+%28in+computer+science%29
| instead. Whatever Spivack can say about this stuff I think is
| going to be much more worth your while.
|
| Looking at https://arxiv.org/pdf/1602.03501.pdf now.
| TrackerFF wrote:
| Same goes for problems in data structures and algorithms (read:
| hackerrank / leetcode problems)
|
| Some people will recognize patterns pretty fast, while others
| must solve literally hundreds of different problems, before
| becoming comfortable with the concepts.
|
| People always seem amazed and baffled that some candidates can
| practically walk into white-board interviews unprepared, other
| than what they learned / did in their DS&A classes in college,
| and nail the interviews, while others have to basically prep 6-12
| months before passing the same interview.
| mkl wrote:
| I like the teaching idea, but I feel like there is a step missing
| in here:
|
| > When my students encounter a math problem they can't answer, I
| have them put it in the error log with an explanation of how they
| did and how they knew how to do it.
|
| If they can't answer it, where does the "how they knew how to do
| it" come from? Their teacher/tutor?
| csours wrote:
| Math is about symbol manipulation. Some of those symbols are
| numbers, and some of the manipulations are arithmetic.
| anyfoo wrote:
| I'd personally say the symbols and their manipulation are a
| good _representation_ of what 's going on in math, but math is
| overall more general. (By the way, arithmetic is about numbers,
| maybe you meant algebraic.)
|
| Sometimes manipulating symbols towards an answer is great, but
| sometimes taking a step back, and looking at a problem through
| a different lens (e.g. at what you are trying to do
| intuitively) is vastly superior, and the symbol-manipulating,
| rigorous formalization (and verification) part comes
| afterwards.
|
| A few examples (out of very many):
|
| * In signal processing (both digital and analog) it can often
| be much more insightful to play with visualizations of time
| domain, spectra, and convolution and multiplication thereof.
|
| * Related but more general: Thinking about the complex
| exponential as spinning in a circle, or tracing out a corkscrew
| in 3 dimensions, is a way easier method to grasp it than to
| look at the equations, which for someone getting into it will
| look like abstract nonsense[1].
|
| * Topology is about "shape" and "deformation" of objects.
|
| * Discrete Structures is about trees, graphs, and so on.
|
| In all of those, you can hit paths where an intuitive
| understanding may stay out of reach, and symbolic manipulation
| through e.g. algebra might remain the only way to work with it,
| but that is often not generally true for the whole field.
|
| [1] Funnily, that's an actual term used by mathematicians, but
| usually in another field:
| https://en.wikipedia.org/wiki/Abstract_nonsense
___________________________________________________________________
(page generated 2021-08-09 23:00 UTC)