4 ms·

But... come on. Sigma is basically a for-loop if you're translating Math symbolism into code. The edge case of summing infinite sequences has no practical appl

But... come on. Sigma is basically a for-loop if you're translating Math symbolism into code. The edge case of summing infinite sequences has no practical application in CS.

pron 10y ago
> The edge case of summing infinite sequences has no practical application in CS. The number 2 is \Sigma_{n=0}^{\infty}1/2^n. So you're "using" sigma every time you use the number 2, which may be practical in some programs. The fact that you can't write a program that sums an infinite sequence using an infinite number of computational steps doesn't mean uncomputable objects have no practical application. In fact, the formalism Lamport talked about in his lecture makes common use of them, and you do, too, every time you use floating point arithmetics. When you use floating point numbers, it's very convenient to think of them not as the very complicated objects that they are, but as a real number (an uncomputable object) with some error term; in fact, that's how floating point is thought of in the design of many numerical algorithms. In other words, objects that are directly representable on a computer, are often conveniently thought of as approximations of uncomputable objects. If you can't write what the non-computable object is in a language designed to assist in reasoning about how algorithms work -- which is the subject of Lamport's talk -- you're making life much harder for yourself. Another problem of thinking of summation as a for-loop is that it makes you think of the definition as an algorithm, which it isn't. For example 4 * 5 = \Sigma_{i=1}^{5}4, but both of them are just different representations of the number 20. In a program it may make a big difference if you're writing 20, 4 * 5, or `for(i in 0..4) sum+=4`. In mathematical notation, all three are the same. It's not like one uses a cheap multiplication operation and the other an expensive for-loop.

But... come on. Sigma is basically a for-loop if you're translating Math symbolism into code. The edge case of summing infinite sequences has no practical application in CS.

pron 10y ago

> The edge case of summing infinite sequences has no practical application in CS. The number 2 is \Sigma_{n=0}^{\infty}1/2^n. So you're "using" sigma every time you use the number 2, which may be practical in some programs. The fact that you can't write a program that sums an infinite sequence using an infinite number of computational steps doesn't mean uncomputable objects have no practical application. In fact, the formalism Lamport talked about in his lecture makes common use of them, and you do, too, every time you use floating point arithmetics. When you use floating point numbers, it's very convenient to think of them not as the very complicated objects that they are, but as a real number (an uncomputable object) with some error term; in fact, that's how floating point is thought of in the design of many numerical algorithms. In other words, objects that are directly representable on a computer, are often conveniently thought of as approximations of uncomputable objects. If you can't write what the non-computable object is in a language designed to assist in reasoning about how algorithms work -- which is the subject of Lamport's talk -- you're making life much harder for yourself. Another problem of thinking of summation as a for-loop is that it makes you think of the definition as an algorithm, which it isn't. For example 4 * 5 = \Sigma_{i=1}^{5}4, but both of them are just different representations of the number 20. In a program it may make a big difference if you're writing 20, 4 * 5, or `for(i in 0..4) sum+=4`. In mathematical notation, all three are the same. It's not like one uses a cheap multiplication operation and the other an expensive for-loop.