We can formally add and subtract simplices. Homology is (very roughly) counting holes using the modulus (%) operator with respect to this addition and subtraction.
There's an old joke that goes something like this.
A math professor was giving a lecture and then remarked that something was trivial. Somebody raises an objection and asks why. The professor stops and thinks hard for the rest of the lecture, then finally remarks: "Yes, I'm right, it is obvious."
No, I don't think there is much of a demand, at least not enough to sustain an entire business. You would need to be pulling in serious money from publishers, and on top of that, you're trying to change a system that largely already works. I've published myself, and e-mailing drafts was fine. The only times I've ever seen collaborative documents being used by average people were a) real-time coding interviews, and b) filling out forms. People would not be willing to pay money in either case, no matter how good it is.
If you're selling worse quality products at a higher price than Wal-mart, then yes, it is silly to start a store right next door. You will probably lose money, like most startups based on bad ideas.
Starting an entire company based on collaborative writing is a junk idea. It's a niche service without much room for improvement, and it's currently being provided for free by one of the largest software companies in the world.
There is no way that this will ever achieve anything close to $500k/year. For this to happen, at $8/month it needs to attract 5000+ subscribing, paying users. This is not going to happen when anyone can just use Google docs for free. Especially when Google is more well-known, better maintained, and integrates into existing Google accounts. There is just no good reason to sign up for a new service.
Most people have never heard of draft or etherpad. I'm willing to be that they are not actually generating any substantial revenue either, which is the benchmark for whether it's a good idea to start a business or not.
> So what? Why is lowering wages a bad thing? If the wages are lower across the industry, it means consumers get lower prices. You're totally ignoring the consumer side of the equation.
This is incredibly naive. There are many good reasons for deregulation, but propagating arguments like this just gives libertarianism a bad name.
This is completely wrong. Nobody expects an academic career anymore, and all the PhD students I know are doing it because they really like their subject. It's like aspiring to be an artist.
No. Feynman never took issue with integration notation or how integration is defined or taught. The story you're referring to is how he learned of a technique for computing integrals that was not covered in schools. The technique is called "differentiation under the integral", and is arguably even more involved.
Many mathematical concepts cannot be translated into programming, since computation is by definition discrete. For example, even a simple concept like irrational numbers cannot be completely captured by code.
Below the formula in the page, you see everything defined and logically derived, and a brief overview of what it's supposed to do. You are correct in that Wikipedia may not be the best place to learn from scratch if you are a novice, but its purpose is more to be a concise reference than a thorough introduction.
If you need more guidance, there are thousands of textbooks at all levels of understanding, and if you opened a single one of them, you would immediately see that the "P" is standard notation for (conditional) probability.
Not really. This is more of an example of a "failed experiment" than showing off. Research is hard. You never know if what you're doing will be useful, or just plain wrong.
Lebesgue measure is actually simpler than Borel measure, since it includes all null sets for convenience.
Yes, you could not talk about Lebesgue measure at all.
However, the importance of theory is that you gain a deeper understanding of the abstract objects that the code is supposed to represent in the first place. This in turn, can have practical applications.
For example, you could implement a Fibonacci function using recursion as usual. But if you study the math a bit more deeply, then you can discover Binet's formula and get it in constant time.
This is abstracted and very understandable. The picture is the definition of a function, which in turn invokes the definition of other functions. The P's are abstractions for conditional probability, the sums are loops etc. If this were code, it would be no more than a few lines and very understandable.
Unlike code however, for all this there is very thorough documentation for mathematics in millions of pages by thousands of people in many different languages at all levels. The
documentation is textbooks, and they're pretty good.
A lot of the difficulty in mathematics is trying to come up with the correct, precise definitions for "fundamentally simple" ideas (the French are historically well known for this). There is literally no way to get the precision afforded by mathematics without requiring substantial jargon, it would be like trying to write an entire operating system without functions. Mere intuition doesn't cut it here, we want logically airtight proofs, and for this you need exact definitions and terminology.
For example, everyone intuitively knows what holes are.
Well, how do you rigorously define a hole? It took centuries
to come up with the correct definition, which is given in terms of homotopy groups, and the definition of homotopy groups will look incomprehensible to the non-mathematician.
Seemingly "easy" statements like "bounded three dimensional objects without holes are spheres" (i.e. the Poincare conjecture) turn out to be very, very hard (worth a million dollars and a Fields medal!)
My experience in academic computer science has been the complete opposite.
In industry, what I've seen is that often engineers are scrambling to please managers or customers, with work divided among multiple people, so the code is usually poorly written and undocumented.
In academics, publications are of primary importance, so everything is documented. The longer timescale means there's more time to refine code that's designed for a single, focused problem. The limited scope of the programs used means code quality isn't an issue most of the time.
Also, in theoretical computer science at least, the focus is entirely on rigorous proofs and finding optimal algorithms.
While in industry, it's more "get practical things done quickly so we can sell it".
Mathematicians do not compute numbers.