How to Read Mathematics
people.vcu.edu
people.vcu.edu
Mathematics is (usually) written for humans, not computers. Don't attempt to read mathematics as you read code. To keep making bad analogies, it's a bit more like reading music. Picking the right tempo, the notes to accentuate, the interpretation -- this all requires a human. Computer still make crude approximations.
I have a deep dread and fear of numbers and mathematics in general because I don't understand them and I have never learned. Now I learn that there isn't one thing to learn but a vast array? No thanks. I had this apparently romantic view that an equation is an equation (the same equation) anywhere in the world.
We may take advantage of libraries in programming (but even then they may not work on all of the physical platforms), but it's not that well defined, what is "the fundamental language" of mathematics; at least not as of today.
Although I find it cool that tools like Coq are getting increasingly popular, so we will eventually get there.
Or to take us a step further, that a certain arrangements of electrons is "negative" and the inverse arrangement is "positive"
I often tell CS people that everything in computing is metaphor and it honestly disturbs me that 80% of the time I get blank looks.
This is why people think Machine "Learning" means that the Singularity is near.
You mean like Lojban (https://en.wikipedia.org/wiki/Lojban) ?
It's not as bad as that! You're very unlikely to hit this sort of issue until you're reading research papers (unless you decide you're very interested in mathematical history). Pretty much all the material youll come across up to ~undergrad level will use very, very similar notation.
Later, at high-school (UK, 16-18yo) we used both d/dx type notation for differentiation and x-dot (a dot above the letter for each level of differentiation).
There would be 3 versions of x= ut + (at^2)/2 that we'd know, this one, d/dx, and dot-notation; primarily the former was used in physics and the latter in maths. We'd also use suffixed numbering, u_0, u_1 on occasions and use u, v, w on other occasions.
One important point - they're not different equations, just written differently.
You write for your audience, in an advanced paper you can abbreviate and use shorthand because you know the reader (in general) will understand.
As an undergrad I found that each department I studied in would tend to use different notation - chemistry, ecology, maths, physics, computing - for the same things. Though sometimes different professors would buck the trend ... they also had different accents and vocabulary, our QFT professor loved the word recapitulation.
You also get different symbol use, like rho for density in one domain and d in another; but that's not really notation per se.
TL;DR sometimes you come across different notation earlier. Different notation doesn't change the equation.
There is one, it's called formal logic. The problem with it is that it's not adequate to explain things, only to prove theorems formally; any strict unambiguous proof written in formal logic looks more like a debug trace than a scientific article.
To provide a proper explanation of a mathematical result, at many points in the proof you need to summarize the hundreds of intermediate mechanical steps and write the insight behind them in common language, using potentially ambiguous words.
I think a more intuitive answer is that in math you are generally talking about relations between infinite sets of objects, whereas in programming you are living in a (in practice) finite space and are evaluating everything into an integer. Programming is about calculating integers, mathematics is about proving theorems. The language has to be very different because what is crucial about evaluating integers unambiguously is peripheral to proving theorems and vice versa.
You can ask, why is it so painful to give a formal proof of correctness of your program? It's impossible to do for all but the most trivial programs. You know that a brilliant person, given years of work, might be able to come up with a proof of correctness, but you also know that the language they would use to do that would be very different from the language that you as programmer would use to write your program. So it goes in both directions. Programs evaluate numbers, they are essentially adding machines, and central to that is the erasure of state via addition.
Math is about symbolic relations and erasure of state is via relations on infinite sets. For example, you want to prove that if a group has a prime number of elements, then it must be cyclic. So pick a generator, raise it to powers, and get a subgroup. Then by Cauchy's theorem, the order of the subgroup has to divide the order of the main group, and that order is prime, so therefore the subgroup has to be the whole group.
There are many things to unpack in that statement. For example, Cauchy's theorem, which says that if a A is a subgroup of B, then the order of A divides the order of B. So
Cauchy's theorem + Group is prime order => non-zero subgroups must be the whole group.
And then every non-zero group has a non-trivial cyclic subgroup + non-zero subgroups must be the whole group => the whole group is a cyclic group.
So it's bit like adding numbers, in that you forget state, but the rules are much more complicated involving quantifiers and a huge universe of sets.
To build a computer that could reason that way, you'd need an infinite set of registers, rules for quantifiers, etc. and your unit of memory would be abstract set relations instead of a zero or 1.
You can try to simulate special cases of that in software, say with an SMT solver. If you look at the DSL of writing code for SMT solvers, it looks different from the code that a programmer is used to writing, and the best SMT solver can't really do anything too interesting from a math point of view, with very rare exceptions.
Moreover in math as practiced, no one (except some logicians) writes in formal logic. It would be too cumbersome. Simple statements like "a harmonic function on a disk achieves its maximum and minimum value on the boundary of its domain" would require thousands of pages of formal symbols and quantifiers. No one can think like that, and so we don't write math that way because we also want to forget things and make compact statements, but what we forget in math is relationships among infinite sets, things like, what are the real numbers, what is a function on the real numbers, what is a differential, what is a harmonic function, what is the maximum of a function, what is a disk, all of that is packed into our statement and replaced with a math statement that is much more compact in the same way that 1 && 0 are replaced by 0 in a computer register, but the computer register is not rich enough to model relations on sets.
It's not!
It turns out that the dependently-typed lambda calculus is sufficient. See the research into Lean[0].
It seems we had discovered a portal called, Curry-Howard. You can throw in theorems in one side and out come proofs on the other. Programs are mathematical objects. And programming is a subset of mathematics. I like to think of it as an applied mathematics.
It just so happens that practitioners of this language don't require knowledge of the other side of the portal in order to write their proofs. They just write their proofs without any theorems, or at best, a large suite of examples.
To me writing proofs is programming.
Tell this to anybody who is familiar with, say, algebraic topology. This is a very narrow view of mathematics. Mathematics is much, much deeper than that. Even the pure algebra is no longer about "symbolic relations".
In fact, today the correct view of mathematics would be much closer to that of theoretical physics: both study one or the other form of reality, using pretty much the same method.
Admittedly, there are no big tables containing "definitions" of these languages. But I think it is common opinion that if you don't understand the language a paper is using, then there is a very large chance you don't know the underlying theory, and the paper will make no sense anyway.
I asked a friend why he thought this was, and he suspected that the CS department's focus on formal languages and automatic theorem proving is what lead to their use of logical symbols.
Humans can infer. If it doesn't make sense, they realize something is wrong and attempt to make sense of it.
As to why the mathematician preferred 'English', I think it's because quantifiers aren't universal. Mathematical notation itself isn't universal. That is, while the student may be internally consistent and exact in their qualifiers, they are not universally consistent between students, nor with the professor's expectation. The professor wanted to immediately grok what the student was trying to do, not have to approach every single turned in assignment as though it was an unfamiliar mathematical paper, using its own notation, that he had to interpret (where some symbols may share a standard meaning across papers, others won't)
Your friend in math is definitions. IME clever definitions minimize the sheer amount of rigor you need to get from point A to point B through their abstractions. The more "natural" or easily understandable a definition is, the easier it is to use that definition as a ground truth in your theorems.
For example, I have an unpublished proof of a graph/game-theory conjecture. Proving the theorem's correctness is extremely convoluted if you rely on atomic definitions of graphs, valid actions, etc. However, as you define new relationships precisely, it becomes much easier. The more abstractly you approach the problem, the simpler the problem becomes, given the correct abstractions.
I would say we have come a long way.
Mathamaticians absolutly do spend effort on making their work readable. However, this readability is general not within the equations themselves, but rather in the prose around the equations and in how the proof is presented. Of course, skill levels vary in this, and most mathematicians only ever write for other mathematicians, so that is the audience they have practice with (and, if you read a math paper, likely the intended audience).
Also, generally the "equation" is not what mathamaticians are even trying to explain because it is vastly simpler then what they actually worked on, which is the proof.
For example, suppose quadratic equations were actually really difficult, and a mathamtician finally figured out how to solve them. She would probably say something along the lines of:
"A quadratic equation has solutions x=(-b +- sqrt(b^2 - 4ac))/2a.
[Entire paper talking about how to complete the square]"
The entire point of the equation is to be simple to write down and use. It is not intended to be understood.
Sometimes they say an equation without explanation. That is either bad writing, or knowing the audience. Ideally, every equation would come with either an explanation or reference; but if I am writing a research paper, I am probably not going to cite every fact that can be found in an undergrad calculus textbook.
What must be noted though is that historically the language of mathematical formulas, unlike more "human-readable" text, has been designed to serve several distinct purposes, and conveying the meaning was originally not the most important one; rather, the language of formulas serves the purpose similar to that of programming languages of today, which is to let one to efficiently and, to a large extent, mechanically perform - and thus radically simplify - 1) calculations; 2) logical reasoning; 3) transformations that lead to discovery of new facts.
”I can’t understand anything in general unless I’m carrying along in my mind a specific example and watching it go. Some people think in the beginning that I’m kind of slow and I don’t understand the problem, because I ask a lot of these “dumb” questions: “Is a cathode plus or minus? Is an an-ion this way, or that way?” But later, when the guy’s in the middle of a bunch of equations, he’ll say something and I’ll say, “Wait a minute! There’s an error! That can’t be right!” The guy looks at his equations, and sure enough, after a while, he finds the mistake and wonders, “How the hell did this guy, who hardly understood at the beginning, find that mistake in the mess of all these equations?” He thinks I’m following the steps mathematically, but that’s not what I’m doing. I have the specific, physical example of what he’s trying to analyze, and I know from instinct and experience the properties of the thing. So when the equation says it should behave so-and-so, and I know that’s the wrong way around, I jump up and say, “Wait! There’s a mistake!”
"I had a scheme, which I still use today when somebody is explaining something that I’m trying to understand: I keep making up examples. For instance, the mathematicians would come in with a terrific theorem, and they’re all excited. As they’re telling me the conditions of the theorem, I construct something which fits all the conditions. You know, you have a set (one ball) – disjoint (two balls). Then the balls turn colors, grow hairs, or whatever, in my head as they put more conditions on. Finally they state the theorem, which is some dumb thing about the ball which isn’t true for my hairy green ball thing, so I say, ‘False!’"
This is also useful to understand preconditions by reduction. I.e. if you want to understand a theorem, it can sometimes be useful to start by figuring out the reason behind the preconditions. "Why does this apply only to balls that have hair?" Simply go, "What would the theorem imply if I start with a smooth ball instead?"
This practise can also lead to generalisations. Oftentimes starting with a smooth ball will make you go "What? That't can't be possible."
But sometimes, starting with a smooth ball leads you to, "Huh, that's really, really weird. But it's not a contradiction in and of itself. I could use that result in another context!"
I upvoted you, but clearly didn't undo all the downvotes.
https://www.amazon.com/Counterexamples-Analysis-Dover-Books-...
These counterexamples are sometimes a bit involved, but I find they are often useful for understanding the purpose of the technical assumptions that accompany many theorems.
When you're talking about complex abstract systems, I have 2 or 3 real world models going on in my head and playing out chains of consequences at the same time. When your abstract system falls down I can tell you where and what caused it despite not understanding a word of your explanation as to why it should. All those mathematical equations and models may as well be Greek to me.
First you want to see if this paper is even worth reading. Scan the Abstract and the conclusions. If it is still relevant then do a quick scan of the whole text and look for the things you don't understand. For everything you don't understand look up on wikipedia. Once you have found those pages then look on the citations on wikipedia to gain more understanding. If you still can't understand the paper reread it and then attempt to redo their calculations. If all else fails ask someone to help you read it. Whenever you get confused write on the paper questions. If you figure out that this paper is meaningless then look for another one.
If you figure out a new question that you want to persue more then try to answer that question. If you don't have access to professor or if they are impeding your work then use stackexchange. Either that or try to invalidate your new theory yourself. Recognize that you can be wrong.
The author sometimes forget to mention what B actually is, changes the meaning of the multiplication operator implicitly, assumes the formula given is inside an integral.... I could go on.
A maths article is an article. A lot are imperfect, quite a few are bad. Some times it is not the reader that is lacking.
That being said, do your homeworks and only consider that possibility after giving the article one hour of your time or so.
Would anybody be able to provide the blog post I believe we both read, which says almost exactly what Iv wrote? I could have sworn Michael Nielson wrote it, but I was unable to produce it last time I searched. So I am following OP's advice and am asking here. :P
https://news.ycombinator.com/item?id=666615
In particular, this piece of advice he gives still rings true to my ears:
Often, when struggling with a book or paper, it's not you that's the problem, it's the author. Finding another source can quickly clear stuff up.
Short of bugging the author, you can also go to Wikipedia's entry for SciHub and see what their latest known domain suffix and/or IP address is.
Or, go directly to arxiv, scihub or a similar service.
Fully agree with the following steps, though.
All of this just to have the paper. During reading, you still need to check the Russian original and ask a Russian friend (as Google translator is not necessarily to be trusted on mathematical texts) for some points that make no sense and turn out to be mistranslations. Not to mention the references to other Russian papers from the sixties that could be even more difficult to find.
On the other hand I have to mention that the paper actually contained the theorem I wanted and the proof was reasonably clear. The author also replied helpfully to an email I sent him! So this was definitely worth the effort. I was lucky!
You can replace all that by a trip to sci-hub ;)
The trick is to find out the IP address of a DNS server or two that knows about Sci-Hub, and put those in your /etc/resolv.conf file.
Note: They have to come first in the file, before any 'compromised' DNS servers like Google's or your ISP's, that will always report 'sorry, I don't know how to find this "Sci-Hub" you speak of'.
If you're on a Windows machine, do it in Control Panel instead; dig down in Network settings, TCP/IP, Advanced, DNS to find the place to type in new DNS server IP addresses.
Do that, and Sci-Hub works fine. Twitter is a good place to find the latest working IP addresses for their DNS server. Last time I looked, they were 80.82.77.83 and 80.82.77.84.
"A well-written math text will be careful to use a word in one sense only"
So many papers are not that careful, and thus, not so precise. There are only so many greek letters, so they end up overloaded. I can't count the number of times I've struggled over an equation, only to find out that the reason it made no sense and/or the value for a specific example came out differently was because the author assumed one variable to mean something differently than I did (and my assumption was perfectly valid in another context. Sometimes another context in -the same paper-). The whole experience is incredibly frustrating.
Echoing another point here, if you just show a sufficiently non-trivial example and walk me through it, I grok it quickly. -Then- give me the equation if you must.
E.g. I did my MSc. on statistical approaches to reducing error rates in OCR, and so many of the papers I reviewed for my literature review suffered from leaving out absolutely critical information when they presented equations etc. that most of the time I spent implementing a lot of the methods presented tended to be to try to reverse engineering missing information (and often that was only possible because many of the papers used one of a few well established public datasets for their experiments).
To me, for those CS papers, maths was a warning what was lying ahead was likely not precise or well defined. It's incredibly frustrating as there were generally no good reason to do so - it wasn't a matter of leaving out large bulks of complicated code. Often it could be as simply as leaving out the concrete values of given parameters.
I'm not implying maths have no place in CS papers, but the CS papers that I've seen that have used it best have tended to also present code fragments, or use maths very sparingly and coupled with painstakingly defining variables etc.
I had a 4.0 departmental in CS from the same school I tried to get a master's in, but yeah, the master's experience was so bad, and working through those issues so time consuming, I just said "Screw it, I can get a better return on this amount of time doing my own things". Even if it's learning the same things, but to an explicit goal rather than just 'understanding' (and an eventual test/assignment that may or may not relate to what I care about), and where I'm not constrained by an academic policy that prevents me from going to others to have them explain exactly what I need to know.
>>> One can now check that the next statement is true with a certain amount of essentially mechanical, though perhaps laborious, checking. I, the author, could do it, but it would use up a large amount of space and perhaps not accomplish much, since it'd be best for you to go ahead and do the computation to clarify for yourself what's going on here. I promise that no new ideas are involved, though of course you might need to think a little in order to find just the right combination of good ideas to apply.
I hate that. When I program my computer, I specify all the steps to accomplish something. If it's too verbose, then I abstract it in a function.
I even add comments to make sure that a human reader easily and completely understands what I do.
I do that because I want the computer and the human reader to be productive in their understanding of what I do. And because I want the human reader to see that it's either elegant or just mechanical.
I'm not that pretentious to say "hey, I've hidden a few details because if you are as smart as I am, then you'll understand easily".
I had this when learning maths. As a student I was sometimes lost because I always thought maths were hard. Should I have had all the details, I'd seen it was indeed much easier than I thought and wouldn't have been intimidated. Now, I'm older, and I know all of that and I'm much better at mathematics. But what a waste of time.
And the space argument, come one. Just put all the stuff in annexes and it'll be fine.
> I even add comments to make sure that a human reader easily and completely understands what I do.
Yeah, honestly, any single time I read a maths-related paper I feel like I would be better off with an example, well-written, implementation in any programming language.
Then I recall what the code, written by mathematicians, tends to look like, and I'm not so sure anymore...
Seriously, the fact that math people choose to ignore the last 50 years of software engineering development, which was in a large part focused on readability and maintainability, instead of incorporating the techniques for themselves is really baffling. As it is, aside from a couple of really well-written articles, reading any paper has a high chance of frustrating me to tears...
That's a pretty minor part of all the papers produced every day.
> to be completely up-to-date
Did I say anything about being "completely" up-to-date? Most of the good practices for readability and maintainability of code were known in the 80s, with almost all of the bad practices disappearing in the late 90s. That's twenty years.
> the latest research in software engineering development
That's not even a research, actually. Things like using meaningful function and variable names (I can never, for the life of me, understand why someone would prefer `X` over `training_set` or `x` over `element`), using comments, using uniform, standard formatting, abstracting - but not hiding or omitting - mechanical details and so on don't come from standard research (I think?), but from the practice of programming.
It is completely reasonable to expect people to improve their craft and to change their ways to better fit a changing environment. The arrival of general-purpose computers and later the Internet had a huge impact on almost every other occupation, from accountants to physicists, to biologists and medical professionals, to writers and journalists... just not on mathematicians. I may be wrong on this, of course, it could have changed in the meantime, but when I was a university student I learned algebra - as I've been told to - from a book printed in 1978. And that was ten years ago.
When you say "I abstract it in a function" that's surely what a mathematician is doing when they say "then we have a BVP and it naturally follows ...", they're applying the function "treatAsBVP". If you don't understand that step then you go and learn that, just as someone would have to find a library and look at an abstracted function used in your code to understand what it returns.
In principle, yes.
In practice, I can right-click on any such function and get to see its source (edit: instantly, automatically) whenever I need it. That doesn't work at all with math papers.
EDIT: Furthermore, when writing about something where bubble sort is used, for the general audience, I would simply link to an explanation of what it is, visualization of how it works and an example code, so that anyone who doesn't know it can quickly get up to speed with it, then I'd explain how exactly that sorting method fits with the rest of topic.
In maths, papers are devoid of any links, the teaching materials are up to 50 years old and never updated to take advantage of new presentation techniques, authors frequently name-drop some algorithm and then forget to say what parameters they used or how exactly it connects with preceding and following paragraphs. It's really bad from UX point of view. That's why sites like BetterExplained are so important.
EDIT2: so, in short, I'd do everything I could - without spending huge amounts of time on it - to make the article as accessible and easy to follow as possible and to make it useful even if someone is not able to understand it whole. I'd really like to see mathematicians to at least try doing the same.
That there is the crux. If math articles/papers were written in a different medium then you could drill down (right click, view source) from the most abstract level down to the basics. Some kind of tool would need to exist to make this possible.
Not really. Math papers have citations; and important references to prior work are mentioned in the text. It would be a nice quality of life improvement if these were as easy to follow as clicking a link, but relative to the amount of effort you will spend within each link, it is pretty close. Assuming that the referenced paper is in an accessible location; although if it isn't and I need to track it down, I would prefer a standard citation over a broken URL with no archive.
Software engineering is a very different activity from the math that mathamaticians do. It makes sense that it has a different standard for what mathematicians do.
There are undoubtadly ways to improve mathematics, but it seems highly arrogant to say that your <100 year old field has discovered a massive improvement that mathematics has missed for centuries.
Occasionally they are right. Most of the time however, the domain experts are right.
Could you please tell me why do you think that the name `x` is better than `element` (when talking about some set), the name `X` is better than `training_set`, and the `∑` is better than `sum`?
We should not forget that the progress that science, mathematics and technology have made in the past 100 - 150 years by far exceeds all that had been done before.
Even if a domain is over 1000 years old, some domains have only existed for about 150-200, which means that before, the world did not have the benefit of those lenses. Now that we have them, it is only natural to mix and match to see if easy insights come out.
Is there not also a risk of arrogance to demanding that another field understand everything about yours before attempting to share knowledge? It suggests that the time of day is so limited, and you have business of such importance, that you will not hear ideas below a threshold. That seems like a fine strategy for accruing quality up to a point, but it can run into local maxima more easily.
No, actually, they learned to write math in a way which is a trade-off between readability and ease of writing (which is perfectly ok). The problem is exactly with thousands of years of history: the notation which is convenient to write on a clay tablet or papyrus scroll is not necessarily the best notation to use in an interactive document format displayed on computer screen.
Fiction writers have as long a history as mathematicians (or much longer) but they don't insist on writing in Latin or Middle English. It is arrogant to think that the notation and practices of contemporary mathematicians are ideal and impossible to improve in any way.
Lastly, writing for other mathematicians is a problem in its own right. There is a difference between conducting your day to day work, where you can write your equations on clay tablets for all I care and writing an article with a purpose of explaining your work to others. Most of the math papers completely ignore this and instead of honestly explaining the matter, authors focus on promoting themselves as great scientists.
There is a lot that can be done to improve understandability (I used "readability" for this earlier, but understandability seems to fit better), to reduce the time needed to read and understand math papers. It would benefit everyone, yet almost nobody does it. There are reasons for this, I'm sure, but it still makes everyone worse off.
You certainly do not specify all the steps your computer must take to run the program because that would make even the simplest program a nightmare to read. In the same way, specifying all the steps a reader must take would make math papers completely unreadable. There's a line which should be chosen wisely, but it's not as simple as "just explain everything".
> If it's too verbose, then I abstract it in a function.
Yeah, not everything has to be included in your source and you do rely on abstractions when writing code. On the other hand, these abstractions are always there, and it "easily follows" that you can take a peek at them at any time, up to and including disassembling a binary executable. You can't do this with a maths paper - you can't just go to Github to check the source of a library, you have to "reimplement", again and again, pieces of the paper that an author decided to omit.
Analogous to Github would be the entire mathematics ecosystem - it is not unreasonable to expect your reader to read another referenced work rather than reproduce it yourself.
I think a better analogy than Github for work just assumed to be worked through by the reader, would be uncommented sections of code. Despite what anyone says about best practices, there will always be plenty of uncommented sections of code in any serious codebase, although the hope is that they would all be fairly trivial (and this is the same hope with mathematics papers).
I would expect anyone reading my code to understand that if I loop through an array of integers, add them to a sum, and then divide by the length of the array, I am taking an average, even if I would be better served using a method that describes this properly.
I would expect anyone reading my code to intuitively understand what I am doing if I build a reverse lookup map to some other map data structure without me commenting every little line and type to explain the idea behind the construction.
Similarly, it is not always unreasonable for mathematicians to assume their reader can step between lines using elementary techniques. If you want someone to perfectly walk through every single assumption in a proof with zero ambiguity, you have arrived at Principia Mathematica.
Certainly some mathematicians are worse than others, but this is no different than the world of software. I cannot begin the number the times I have stepped into some old enterprise code and immediately wanted to scrub my eyes after viewing some thousands-of-lines method with few to no comments and code branching in every direction for hundreds of lines at a time.
Skim all. Skim again the next day. But the third time, get pencil and paper and take notes, and effort. If it's neither uncomfortable nor exciting, you're doing it wrong.
I think that people that read it linearly don't miss important info, but I just can't
It's not even the writing per se - it's the structure, or omissions instead. I would rather skim first to find which parts I may not be able to grasp right away and to find out if there's any point spending time on this, rather than go on and read the pieces from the citation list.
What specific papers are you talking about? TFA doesn't contain a single occurrence of the word “paper”. On the other hand, it contains several occurrences of the word “book”. And, most importantly, it is obviously written for newcomers to mathematics, who for obvious reasons will spend more time reading carefully written books rather than papers written in a rush.
For each symbol, I try to make an analogy. For "e", for example, I have the notion of "continuous growth". The formal definition is this:
https://betterexplained.com/ColorizedMath/content/img/E_(mat...
"The base for continuous growth is the unit quantity earning unit interest for unit time."
Once you see the role of each part of the definition, the idea snaps into place. I just wrote about it here: https://betterexplained.com/articles/colorized-math-equation...
Hope that helps!
Analogies are utterly unhelpful without a thorough understanding of the actual definitions.
or rather like net to catch the fish. once you have the fish, you can forget about the net.
this is not far removed from words, which are used to convey meaning. once you have meaning you can forget about the words ;)
edit-001 : fmt changes.
>or rather like net to catch the fish. once you have the fish, you can forget about the net.
So you can forget about the net ... like a raft to cross a river?! ;o)
Why?
For example, an approximation of e would be (1 + .01)^100, where the 100% interest had been chopped into 100 separate segments of 1%.
This has been great for helping me figure out what to even call various symbols so I can then go look up what they actually intend you to do.
Anyway, I still read some symbols differently.
It's difficult to google mathematical stuff, especially since each symbol has many different meanings depending on which branch of mathematics you're dealing with - this book solves that problem nicely by letting you look up by the roman letter a symbol is similar to, by mathematical discipline, etc.
Pity there's little mathematical writing that actually _does_ contain these blind alleys and mistakes. Part of why I enjoy "Concrete Mathematics" by Graham/Knuth/Patashnik is that it's one of the rare counterexamples.
I usually space out at that point. I understand the utility of it, but I find it worthless in most cases. I'd rather understand a concrete example well, then check my understanding by trying the random case, then try to think of some clever or experience based edge case or counterexample.
I think Feynman, especially later in life, probably had the gift of jumping straight to step 3: he understood that his most valuable contribution could often be simply expanding the space of possible examples. And random doesn't really get you the whole space, and certainly doesn't get you the interesting parts of the space.
"Proofs are not meant to be understood by reading them from beginning to end. They are usually meant to be `checked` that way. Most of the time, I start reading the proof from the conclusion and work backwards. Often I write my proofs that way as well."
IMHO it is very easy to waste tonnes of time reading papers / books that are OK but still vastly inferior to an account of a master.
Want to learn index theory: read Atiyah and Singer's original papers.
Interested in the classification of quadratic forms: read Serre's course in arithmetic.
Need to learn about the recent breakthroughs on prime tuples: read Tao!
Find time to read Weil, insist on reading Poincare, come up with an excuse to read Scholze etc.
Top mathematics literature is often spectacularly well written.
See also: https://mathoverflow.net/questions/28268/do-you-read-the-mas...
One gripe is the circular > Before you start to read, make sure you know what the author expects you to know.
How can you know what the contents of the text require before you know (read) the contents of the text?
Then brew a fresh coffee, grab pad and pencil, roll up your sleeves, and make notes as you go.
These days I can even toy with the idea in Lean[0] or TLA+ and find different ways of formulating the results. What a time to be alive!
(that's why, today, I use numpy, where the operations are much easier to see).
nevertheless, i agree for things like white papers the overloading of identifiers is frustrating.