4 ms·
> just like you shouldn't expect to read Война и миръ without first learning the russian language, you shouldn't expect to read this paper without first learnin
by Asraelite 3y ago
> just like you shouldn't expect to read Война и миръ without first learning the russian language, you shouldn't expect to read this paper without first learning the language (i.e., math).
With the key difference being that math is an artificial and constructed language which can be improved. Criticising it makes sense. But while there are improvements to be in math syntax, I don't think that's the main problem here and I agree that you should be expected to learn the notation of a field before being able to understand a paper.
The problem is that academia has a culture of making papers needlessly complicated. If you try to use simple wording and explain things to the reader, you will get rejected by journals. They could easily structure it as something like "let δ be the probability of failure from 0 to 1, O(x) is big-O notation indicating the upper bound of the growth rate" etc. defining and explaining all the variables and notation first and only after that beginning to use them.
- kweingar 3y agoI've seen this sentiment about math notation among programmers, and I don't understand it. Lots of programmers would like mathematicians to define everything in their papers so that programmers don't have to learn math notation. At first glance this seems reasonable, but consider the reverse scenario. If I were a mathematician who didn't know much about programming, I wouldn't go into a GitHub project and ask the maintainers to add little comments to explain the syntax and functions that they're using. "Looks like you're using a function called 'fold'. I don't know what that does. Can you please write a quick explanation of what it does before you use it in your code? This is too complicated for the layman to understand." The maintainer might reply that you can look up what fold means, and that they don't have time to annotate all of their code just to spell out everything to people who don't program.
- insanitybit 3y agoAll we're asking for is a glossary. Such a glossary exists for literally every programming language.
- kweingar 3y agoYou weren’t asking for a glossary. You were asking that people stop using Greek letters. Aside from that, there are references that will tell you what these symbols mean. You just have to look them up. “What does capital omega mean in algorithms?” will get you what you need here. The comparison with programming languages doesn’t quite hold in this sense. There are glossaries for programming symbols and terms, but they are not collocated with the code. Just as we don’t expect someone to put a glossary in every GitHub repo, we also don’t expect people to put a glossary in every math paper. Like code on GitHub, the paper is written primarily for people who understand the language. If you want to learn what something means, you can look it up somewhere.
- insanitybit 3y ago> You were asking that people stop using Greek letters. In an ideal world it would be both. But the worst case scenario is definitely greek letters that are assumed to be known. > You just have to look them up. “What does capital omega mean in algorithms?” will get you what you need here. lol yeah? Do that with δ and you'll get numerous unrelated results + tons of indecipherable maths. Even with Omega you'll get a wikipedia page that's full of other mathemetical symbols. I've done this all, I've got index cards of category theory symbols so that I can read this sort of thing and it's an utter waste of time. The thing is that programmers aren't writing code for the audience of academics and I think that's very reasonable. Why are academics not writing for the audience of programmers? That feels far less reasonable.
- kweingar 3y ago> The thing is that programmers aren't writing code for the audience of academics and I think that's very reasonable. Why are academics not writing for the audience of programmers? That feels far less reasonable. I think this is the core of the issue. The audience here is researchers in the field of random algorithms. Why do you think that it should also be readable by a layman programmer without any study or background knowledge in random algorithms? 99.999% of programmers will never implement invertible Bloom lookup tables. The few that will have studied the math. Seems like a fine arrangement to me
- mathisfun123 3y ago> With the key difference being that math is an artificial and constructed language which can be improved. what does this actually mean? what do you think it actually means? conlangs like esperanto are indeed designed/constructed by some committee/body/BDFL/etc. as far as i am aware, there is no such body for mathematical notation/syntax/jargon. it is figuratively and literally a language with conventions, jargon, slang, etc. that evolves over time and varies by subgroup/community (try reading euler's papers and see how much you can parse even if you're notation-literate today). > Criticising it makes sense. Irrespective of whether it's a conlang or not, criticizing something you don't understand never makes sense. > The problem is that academia has a culture of making papers needlessly complicated. this is true and i wholly agree with you but that's structural and not individual. so criticizing these authors, that labor under these same policies/expectations, for the sins of the establishment/institution does not make sense. you want to effect (yes with the e) change along these aspects? go write emails to conference committees or journal committees or whatever. or write your own papers that buck the trend (and thereby put your own research career at risk). but don't blame someone that's on the receiving end.
- Asraelite 3y ago> what does this actually mean? You're right that they both developed over time, I was more referring to the fact that one is more open to change and less ingrained in people's minds because of its more artificial nature. If you tell people that the way they're speaking a language is bad and needs to be corrected, they take it as an insult to their culture and will likely refuse. If you say that math notation can be made simpler and more comprehensible, then it's a lot more likely that some authors will agree with you and use a revised notation in their papers, even if it means having to explain that notation to readers. Or even better, leaders in education will modify syllabi to teach the new notation. To your other two points: I am not trying to criticize these authors, nor am I criticizing their notation. I am just pointing out the underlying reason behind the lack of comprehensibility. I don't have a solution here.
- ndriscoll 3y agoThe authors did actually say what δ means in words here: "For storing n elements and ensuring correctness with probability at least 1−δ, existing constructions require <blah>. With a failure probability of at most δ, our structure requires <blah>". There's some fluency with the language required to understand what a free variable is, and that a sentence structure like "with probability at most δ, our thing does X" is introducing δ as a free variable. There's also some background "cultural" knowledge required to quickly parse out the fact that probabilities are between 0 and 1, so correctness probability 1-δ is the same as failure probability δ. Maybe they could've been intentional about avoiding that, but it's also normal (and even considered good style!) in natural language to phrase the same idea slightly differently from one sentence to another. It's also pretty clear what Ω means in context even if not explicitly spelled out. They say an existing thing needs Ω(...) space and fully random hashes, and their thing needs O(...) space and O(...)-wise independent hash functions. Clearly they're talking about bounds on things, and Ω and O have standard uses in that context.
- insanitybit 3y agoI noted elsewhere that the paper actually does a good job of introducing the terms eventually - some don't. I know the omega term, but I brought it up because I think it's part of the overall problem.