7 ms·

I hear regularly completly opposite opinions: - the ones that wish programming would be more elegant and expressive like maths notations - the ones that wish

I hear regularly completly opposite opinions: - the ones that wish programming would be more elegant and expressive like maths notations - the ones that wish paper would publish a Python algo instead because maths notations are inconsistant and hard to read I'm not a maths person, so can people with a lot of experience with it help me decide which one is the more reasonable?

y7 6y ago
Neither. Mathematical notation and programming languages serve two different purposes, and I think they both work pretty well for what they're designed to do. Math papers are about communicating with other humans, so they use the shortest language that is effective for the particular problem they're studying. Notation is not meant to be universally unambiguous, because that leads to a much larger language.
- Koshkin 6y ago
  This difference must not be exaggerated. Mathematical notation is declarative/functional, and programming languages designed in a similar vein are not unheard of.
yodelshady 6y ago
No question about it. Mathematical notation is pure evil that should be cast into mount doom and then some. Mathematical notation makes Javascript operators look sane. There is barely a single operation in the last few maths papers I've read that doesn't have at least four possible interpretations at first glance, so the only way to understand a single line is to understand the entire theory at once. Needless to say, all variables are described with single letters. The best defense for it is that it evolved from handwriting, where the difference between `matmul(a,b)` and `a x b`, repeated a few dozen times, is significant. These days, as I type, I define commands to turn the unambiguous longhand into the shorthand. ("But yodel, a and b aren't bolded or uppercase so according to convention they must be scalars!", I hear you say. Ha, ha, ha.) I am genuinely angry about this. A great deal of practical mathematics is not hard. Mathematical notation is hard, and everyone using it should be a little bit ashamed at how needlessly difficult the field is.
- Garlef 6y ago
  While I get your reasoning, I think it misses a few important points. -- 1. Having the same symbol for several things is the mathematicians way of having polymorphism and is a very nice feature. Take for example the plus sign. Everytime we encounter it, we will most likely be dealing with some kind of abelian group. So just from seing the sign, we can already tell a lot about the context. Another example would be the sign for the tensor product. I we see it, we are most likely dealing with some symmetric monoidal category . It might be vector spaces, modules over some commutative ring, coherent sheaves, objects in some derived category, etc. But still the important part is that all the stuff we know about this context can be applied. -- 2. "so the only way to understand a single line is to understand the entire theory at once." What do you expect out of a single line? Just think of a codebase with 800k lines. Would you expect to understand what the codebase is about by just looking at a single line? I guess not: You'd rely on the naming of the functions/classes/etc. and how they are composed to understand what the codebase is doing. You'd also need a lot of knowledge about the area the codebase is concerned with to tell what is going on: Is it about a webserver providing a SPA? Is it a database? Is it a compiler? You also don't expect to understand the whole codebase and it's dependencies (including low level abstractions)in its entirety: If you write a frontend `<div>` tag as part of a frontend do you really need to know the exact way this will end up as instructions on the chip of the computer that is running running a specific version of a specific browser running a certain version using drivers for a specific monitor, graphics card, etc... All this is also true for mathematics. -- 3. "A great deal of practical mathematics is not hard. Mathematical notation is hard ..." Of course mathematics is hard. In fact: If anything related to human thought is hard, it is mathematics. And more explicit notation will not make it easier. Do you think the twin prime conjecture is still unsolved because a layperson may misinterpret the meaning of a plus sign?
  - secondcoming 6y ago
    Yes, but sometimes you just want to code up a formula from a book.
  - BiteCode_dev 6y ago
    Aren't the key words, "most likely"?
xelxebar 6y ago
One huge advantage of the notation conventions in math is its concision. The current practice is, at its heart, that a we assign a single glyph to each concept. The notation is tailored for mathematicians communicating to other mathematicians. The terseness lets you communicate, visualize, and think about abstract concepts very directly. Humans are really good at pattern matching. Giving your concepts very terse names maximizes the ability for this tool to find actually interesting patterns. Of course, the terse notation sacrifices approachability. If your intent is to communicate to non-mathematicians then it's a bad language. That said, mathematical notation is full of historical quirks and irregularities akin to natural languages. Ideally, we want a one-to-one map between concepts and symbols, but in practice there are cases where the map ends up being more like many-to-many. There are competing notations, overloaded symbols, and often one needs significant context to actually resolve the symbol to its concept. In a way, programming languages are an inversion of the above good and bad points. Progamming languages are very precise with their syntax, meaning that you don't need to consider author's intent to figure out what a piece of syntax does. Also, programming languages, by virtue of being executable, are vastly more amenable to empower tinkering and exploration. There is something deeply satisfying about typing in some code and getting an expected result, and when the result differs from expectations, then you found a bug in your mental model. This is much harder to do with pen and paper. That said, most programming languages and their standard conventions fall short by being relatively wordy and verbose. What is a good one-liner in math symbols often takes up a page of code or more, not including definitions. This severely hamstrings the ability to grok the big picture at a glance, and opting for "words" over "symbols" intruces noise that kills our natural visual pattern matching abilities. So if you take the above thesis to its conclusion, one would want executable math notation. I'm not sure such a thing exists, but the APL family certainly is a solid experiment in this respect.
dataduck 6y ago
OK, given yodel's answer, I'll go to bat for mathematical notation. - It doesn't change very much, so you can just pick it up and understand it using what you learned at school. Cf e.g. looking at modern Javascript and wondering wtf all those JQuery selectors are. - Relatedly, there's not a lot you need to know. I'm not a mathematician, but I can understand most mathematical theorems I've needed to look up with just basic high school algebra, derivatives, integrals, sums, products, trig, and matrix / suffix notation. Find me a piece of code that does anything interesting which has less than six calls to library functions. - It's extremely concise, so you don't have to scroll through pages of code to get to the point - each line communicates a lot. This is really important, because it stops you getting lost or distracted in the middle of figuring things out. - It's declarative, so it tells you what you're actually doing, rather than just how to do it. This is like the difference between saying "get me an orange", and giving full instructions for finding a shop that has oranges, navigating to it, etc. I know declarative programming exists (and it has these advantages) but I've never seen it used outside CS courses. I honestly prefer mathematical notation; it has more upfront work to get good at it, but is much easier to use once you clear that hurdle. I haven't found ambiguity to be a big issue (especially compared to code; how often have you used a function which does something subtly different to what you expected?) although this may be due to the fact that I'm not looking at super advanced stuff (a couple of papers on deep learning, skew normal distributions, the rocket equation, that sort of thing). Especially with the deep learning papers, I found it infuriating how long they spent using confusing diagrams and wordy explanations where a couple of lines of algebra would have made their point instantly. The true answer is almost certainly YMMV.
- TeMPOraL 6y ago
  > It's declarative, so it tells you what you're actually doing, rather than just how to do it. This is like the difference between saying "get me an orange", and giving full instructions for finding a shop that has oranges, navigating to it, etc. I know declarative programming exists (and it has these advantages) but I've never seen it used outside CS courses. I find this to be a problem quite often. Maybe my brain is wired differently, but I can't keep declarative definitions in my head and apply them unless I know of an imperative strategy to make them work. I've first noticed this when, in high school, I was struggling to understand the epsilon–delta definition of a limit. The one that goes like this: https://wikimedia.org/api/rest_v1/media/math/render/svg/619debbeb78a82c1c368a3e53470dbc167a088bd https://wikimedia.org/api/rest_v1/media/math/render/svg/619d.... Only after many hours of classes, followed by many hours of staring at the formula, all over the course of weeks, I finally understood what it means. The one missing puzzle piece that no one explained to me was that, when you see "\forall _{sth > 0}", you should read it as "in particular, for a sth arbitrarily close to 0". Declarative notation is fine if you comprehend all consequences of that declaration. In cases where you don't, it would be nice to have it spelled out which consequences are relevant.
Koshkin 6y ago
The idea of using code to represent math in a paper is similar to an “idea” to stick with printing code in TeX instead of letting it be converted to the neatly typeset result.
bonoboTP 6y ago
From experience in reading machine learning and computer vision papers (shared by many of my peers), it's often way more enlightening to see the code corresponding to a paragraph of equations. Some non-programming math people are angry at this view, but really a lot of mathy presentation is there to impress and obfuscate. Many times the code is straightforward and clear but it has to be artificially dressed up in fancy Greek letters and symbols to make it look like "proper science". Also a lot of math notation is very sloppy, the opposite of unambiguous. Math people will say it's necessary for brevity, context is important, you must take the relevant courses beforehand etc, be properly initiated etc. then you will understand. But for me it's still annoying even after a CS master's with many math courses. In code, I can jump to the definition of anything and see precisely what is meant. But a math person would say ambiguity is a feature because, say, the integral sign may stand for different definitions, but in this context we don't care which one it is. They'd often say, well, here you could substitute anything, you could use anything here, it doesn't matter what we use for this and that. But really anything? Can I use a pound of dog fur? No. In working code there is at least one working example to suggest what you mean. I will have a much easier time to understand your abstraction and though process. I think people often think in concrete terms but intentionally keep this secret because abstract ideals are more prestigious, so it becomes the reader's job to figure out what the actual motivation and reasoning of the author was. Thankfully AI papers now mostly release their code so it's possible to see what they actually do behind the smokes and mirrors on the ground level. I'm all for abstraction and general patterns and proofs but there is such a thing as too much.
- a-nikolaev 6y ago
  I think, in some areas math language is more appropriate, in the others programs and algorithms are more appropriate. There is not wonder that a machine learning or a computer vision idea might be more accessible as an algorithm program, but this is not universally true for any kind of math. A well written paper would describe things in clear terms, choosing the most comprehensible means to convey their idea. So, they might provide all three: 1) concise math formulas, 2) corresponding algorithms, and 3) an explanation in English. Not always all three presentation forms are achievable, but all of them can be useful and enlightening for the reader. Unfortunately, in reality, there might be problems with presenting things in clear way: 1) A scientist might think that it is too verbose to repeat themselves, so they present the idea in only one form, at a single place in their paper, and think it's enough ("for the intelligent reader"). You want to find certain balance between conciseness and clarity, imo. 2) A scientist might be so immersed into the specific area of study they are writing about, so they don't see the reason for explanations for the more general audience. Here, it depends what audience the scientist is trying to reach. Also, not all papers present a good exposition of the field of study anyway. So try finding good papers that explain things in clear terms at your level of comprehension. Read those, then move on to find new sources.
enricozb 6y ago
Depends on who the paper is for. Theoretical CS papers for example, often don't have any code, but sometimes have pseudocode (for example in page 4 of PRIMES is in P [0]), to describe their algorithms. If the paper is written for people with less math background then writing up the algorithm in at least once language as a sample implementation is the way to go. Also there's nothing wrong with doing both? [0]: https://annals.math.princeton.edu/wp-content/uploads/annals-v160-n2-p12.pdf https://annals.math.princeton.edu/wp-content/uploads/annals-...

y7 6y ago

Neither. Mathematical notation and programming languages serve two different purposes, and I think they both work pretty well for what they're designed to do. Math papers are about communicating with other humans, so they use the shortest language that is effective for the particular problem they're studying. Notation is not meant to be universally unambiguous, because that leads to a much larger language.

Koshkin 6y ago
This difference must not be exaggerated. Mathematical notation is declarative/functional, and programming languages designed in a similar vein are not unheard of.

yodelshady 6y ago

No question about it. Mathematical notation is pure evil that should be cast into mount doom and then some. Mathematical notation makes Javascript operators look sane. There is barely a single operation in the last few maths papers I've read that doesn't have at least four possible interpretations at first glance, so the only way to understand a single line is to understand the entire theory at once. Needless to say, all variables are described with single letters. The best defense for it is that it evolved from handwriting, where the difference between `matmul(a,b)` and `a x b`, repeated a few dozen times, is significant. These days, as I type, I define commands to turn the unambiguous longhand into the shorthand. ("But yodel, a and b aren't bolded or uppercase so according to convention they must be scalars!", I hear you say. Ha, ha, ha.) I am genuinely angry about this. A great deal of practical mathematics is not hard. Mathematical notation is hard, and everyone using it should be a little bit ashamed at how needlessly difficult the field is.

Garlef 6y ago
While I get your reasoning, I think it misses a few important points. -- 1. Having the same symbol for several things is the mathematicians way of having polymorphism and is a very nice feature. Take for example the plus sign. Everytime we encounter it, we will most likely be dealing with some kind of abelian group. So just from seing the sign, we can already tell a lot about the context. Another example would be the sign for the tensor product. I we see it, we are most likely dealing with some symmetric monoidal category . It might be vector spaces, modules over some commutative ring, coherent sheaves, objects in some derived category, etc. But still the important part is that all the stuff we know about this context can be applied. -- 2. "so the only way to understand a single line is to understand the entire theory at once." What do you expect out of a single line? Just think of a codebase with 800k lines. Would you expect to understand what the codebase is about by just looking at a single line? I guess not: You'd rely on the naming of the functions/classes/etc. and how they are composed to understand what the codebase is doing. You'd also need a lot of knowledge about the area the codebase is concerned with to tell what is going on: Is it about a webserver providing a SPA? Is it a database? Is it a compiler? You also don't expect to understand the whole codebase and it's dependencies (including low level abstractions)in its entirety: If you write a frontend `<div>` tag as part of a frontend do you really need to know the exact way this will end up as instructions on the chip of the computer that is running running a specific version of a specific browser running a certain version using drivers for a specific monitor, graphics card, etc... All this is also true for mathematics. -- 3. "A great deal of practical mathematics is not hard. Mathematical notation is hard ..." Of course mathematics is hard. In fact: If anything related to human thought is hard, it is mathematics. And more explicit notation will not make it easier. Do you think the twin prime conjecture is still unsolved because a layperson may misinterpret the meaning of a plus sign?
- secondcoming 6y ago
  Yes, but sometimes you just want to code up a formula from a book.
- BiteCode_dev 6y ago
  Aren't the key words, "most likely"?

xelxebar 6y ago

One huge advantage of the notation conventions in math is its concision. The current practice is, at its heart, that a we assign a single glyph to each concept. The notation is tailored for mathematicians communicating to other mathematicians. The terseness lets you communicate, visualize, and think about abstract concepts very directly. Humans are really good at pattern matching. Giving your concepts very terse names maximizes the ability for this tool to find actually interesting patterns. Of course, the terse notation sacrifices approachability. If your intent is to communicate to non-mathematicians then it's a bad language. That said, mathematical notation is full of historical quirks and irregularities akin to natural languages. Ideally, we want a one-to-one map between concepts and symbols, but in practice there are cases where the map ends up being more like many-to-many. There are competing notations, overloaded symbols, and often one needs significant context to actually resolve the symbol to its concept. In a way, programming languages are an inversion of the above good and bad points. Progamming languages are very precise with their syntax, meaning that you don't need to consider author's intent to figure out what a piece of syntax does. Also, programming languages, by virtue of being executable, are vastly more amenable to empower tinkering and exploration. There is something deeply satisfying about typing in some code and getting an expected result, and when the result differs from expectations, then you found a bug in your mental model. This is much harder to do with pen and paper. That said, most programming languages and their standard conventions fall short by being relatively wordy and verbose. What is a good one-liner in math symbols often takes up a page of code or more, not including definitions. This severely hamstrings the ability to grok the big picture at a glance, and opting for "words" over "symbols" intruces noise that kills our natural visual pattern matching abilities. So if you take the above thesis to its conclusion, one would want executable math notation. I'm not sure such a thing exists, but the APL family certainly is a solid experiment in this respect.

dataduck 6y ago

OK, given yodel's answer, I'll go to bat for mathematical notation. - It doesn't change very much, so you can just pick it up and understand it using what you learned at school. Cf e.g. looking at modern Javascript and wondering wtf all those JQuery selectors are. - Relatedly, there's not a lot you need to know. I'm not a mathematician, but I can understand most mathematical theorems I've needed to look up with just basic high school algebra, derivatives, integrals, sums, products, trig, and matrix / suffix notation. Find me a piece of code that does anything interesting which has less than six calls to library functions. - It's extremely concise, so you don't have to scroll through pages of code to get to the point - each line communicates a lot. This is really important, because it stops you getting lost or distracted in the middle of figuring things out. - It's declarative, so it tells you what you're actually doing, rather than just how to do it. This is like the difference between saying "get me an orange", and giving full instructions for finding a shop that has oranges, navigating to it, etc. I know declarative programming exists (and it has these advantages) but I've never seen it used outside CS courses. I honestly prefer mathematical notation; it has more upfront work to get good at it, but is much easier to use once you clear that hurdle. I haven't found ambiguity to be a big issue (especially compared to code; how often have you used a function which does something subtly different to what you expected?) although this may be due to the fact that I'm not looking at super advanced stuff (a couple of papers on deep learning, skew normal distributions, the rocket equation, that sort of thing). Especially with the deep learning papers, I found it infuriating how long they spent using confusing diagrams and wordy explanations where a couple of lines of algebra would have made their point instantly. The true answer is almost certainly YMMV.

TeMPOraL 6y ago
> It's declarative, so it tells you what you're actually doing, rather than just how to do it. This is like the difference between saying "get me an orange", and giving full instructions for finding a shop that has oranges, navigating to it, etc. I know declarative programming exists (and it has these advantages) but I've never seen it used outside CS courses. I find this to be a problem quite often. Maybe my brain is wired differently, but I can't keep declarative definitions in my head and apply them unless I know of an imperative strategy to make them work. I've first noticed this when, in high school, I was struggling to understand the epsilon–delta definition of a limit. The one that goes like this: https://wikimedia.org/api/rest_v1/media/math/render/svg/619debbeb78a82c1c368a3e53470dbc167a088bd https://wikimedia.org/api/rest_v1/media/math/render/svg/619d.... Only after many hours of classes, followed by many hours of staring at the formula, all over the course of weeks, I finally understood what it means. The one missing puzzle piece that no one explained to me was that, when you see "\forall _{sth > 0}", you should read it as "in particular, for a sth arbitrarily close to 0". Declarative notation is fine if you comprehend all consequences of that declaration. In cases where you don't, it would be nice to have it spelled out which consequences are relevant.

Koshkin 6y ago

The idea of using code to represent math in a paper is similar to an “idea” to stick with printing code in TeX instead of letting it be converted to the neatly typeset result.

bonoboTP 6y ago

From experience in reading machine learning and computer vision papers (shared by many of my peers), it's often way more enlightening to see the code corresponding to a paragraph of equations. Some non-programming math people are angry at this view, but really a lot of mathy presentation is there to impress and obfuscate. Many times the code is straightforward and clear but it has to be artificially dressed up in fancy Greek letters and symbols to make it look like "proper science". Also a lot of math notation is very sloppy, the opposite of unambiguous. Math people will say it's necessary for brevity, context is important, you must take the relevant courses beforehand etc, be properly initiated etc. then you will understand. But for me it's still annoying even after a CS master's with many math courses. In code, I can jump to the definition of anything and see precisely what is meant. But a math person would say ambiguity is a feature because, say, the integral sign may stand for different definitions, but in this context we don't care which one it is. They'd often say, well, here you could substitute anything, you could use anything here, it doesn't matter what we use for this and that. But really anything? Can I use a pound of dog fur? No. In working code there is at least one working example to suggest what you mean. I will have a much easier time to understand your abstraction and though process. I think people often think in concrete terms but intentionally keep this secret because abstract ideals are more prestigious, so it becomes the reader's job to figure out what the actual motivation and reasoning of the author was. Thankfully AI papers now mostly release their code so it's possible to see what they actually do behind the smokes and mirrors on the ground level. I'm all for abstraction and general patterns and proofs but there is such a thing as too much.

a-nikolaev 6y ago
I think, in some areas math language is more appropriate, in the others programs and algorithms are more appropriate. There is not wonder that a machine learning or a computer vision idea might be more accessible as an algorithm program, but this is not universally true for any kind of math. A well written paper would describe things in clear terms, choosing the most comprehensible means to convey their idea. So, they might provide all three: 1) concise math formulas, 2) corresponding algorithms, and 3) an explanation in English. Not always all three presentation forms are achievable, but all of them can be useful and enlightening for the reader. Unfortunately, in reality, there might be problems with presenting things in clear way: 1) A scientist might think that it is too verbose to repeat themselves, so they present the idea in only one form, at a single place in their paper, and think it's enough ("for the intelligent reader"). You want to find certain balance between conciseness and clarity, imo. 2) A scientist might be so immersed into the specific area of study they are writing about, so they don't see the reason for explanations for the more general audience. Here, it depends what audience the scientist is trying to reach. Also, not all papers present a good exposition of the field of study anyway. So try finding good papers that explain things in clear terms at your level of comprehension. Read those, then move on to find new sources.

enricozb 6y ago

Depends on who the paper is for. Theoretical CS papers for example, often don't have any code, but sometimes have pseudocode (for example in page 4 of PRIMES is in P [0]), to describe their algorithms. If the paper is written for people with less math background then writing up the algorithm in at least once language as a sample implementation is the way to go. Also there's nothing wrong with doing both? [0]: https://annals.math.princeton.edu/wp-content/uploads/annals-v160-n2-p12.pdf https://annals.math.princeton.edu/wp-content/uploads/annals-...