Article is mostly fine, but there's a point I vehemently disagree with: you should not, absolutely not translate math notation to code.
Math is equational and declarative. When you write:
S = \sum_{i=1}^{100} (2i + 1)
you are declaring that we shall call S the sum of the elements of a certain set. You are not prescribing how this sum ought to be calculated: S is a pure value that doesn't depend on what practical operations you do -- be them on paper or on a CPU -- to actually find out what S is.
For example, using equational reasoning, we may write:
S = \sum_{i=1}^{100} 1 + 2 \sum_{i=1}^{100} i = 100 + (100 * 101) = 101^2 - 1
Or, without computing anything at all, we may prove by induction that:
(1) \sum_{i=1}^{n} (2i + 1) = (n + 1)^2 - 1
The base case is obvious, and to prove the inductive step it is sufficient to observe that indeed:
Tying math to code is more like tying your own hands behind your back.
All of this is basically an excuse to point out that the code for the product is wrong, the initial value should be 1 and not 0 (or, in general, your monoid identity).
Exactly, that was my take-away. You don't need to think of the Sum function as a for-loop every time you use Sum, but it certainly helps explain it to a programmer who doesn't have a sense of what Sum is, but knows what a for-loop is.
Can someone recommend a good resource for a game developer who wants to understand mathematical notation so he can dissect game development papers faster? Currently it takes me multiple days to understand a single formula.
It feels a bit like how I found it impossible to memorise all the countries of the world as an adolescent, but then when I discovered Seterra as an adult I was able to memorise them all in less than a week. I need an equivalent perspective shift, but for math.
Beyond a relatively small set of standard symbols and functions, notation is dependent on the field or subfield you're studying, so a "guide to mathematical notation" is not really possible. However:
> it takes me multiple days to understand a single formula
This is not weird. Papers are not hard because notation is hard but because the ideas behind them are difficult to understand. It usually takes me several hours of uninterrupted work to read a paper; I'm not a researcher and have never been in academia, but everyone I know says the same thing, so I'm comfortable reassuring you that you're definitely not the odd one out.
A few pointers to go faster:
- Write down your observations (on the paper itself, if you can print it). Ask yourself questions and see if you got things right. Try to replicate their computation steps. Actively engage the topic.
- Keep a dictionary of symbols. What do the authors mean with this ridiculous scribble? Ah, that thing.
- Mathematical notation suffers from catastrophic overloading. For example, if A and B are numbers, then AB is multiplication in their set. If they are matrices, it's matrix multiplication. If A is a matrix and B is a vector, it's the image of B through A. If one is a vector and the other is a number it's multiplication by a scalar, and so on. Try to undo this process and figure out what the virtual method call resolves to :)
- Try to assign "types" to variables. Notation is "dynamically typed", in the sense that a variable could (syntactically) be anything. If you have trouble understanding a formula, try to understand what kind of object each variable represents. Is this squiggle a set or an element? If an element, from what set does it come from? What are the arguments of this function? What is its image? Is this "i" a real variable or a mute variable? To what quantifier is this variable bound?
- Sometimes notation is abused. E.g. we may write:
10n^2 + n = O(n^2)
This is, strictly speaking, nonsense: O(n^2) is a set, and we're saying it's equal to some undefined stuff. What even is "n"? Obviously, it "compiles" to:
f(n) = 10n^2 + n
f(n) \in O(n^2)
It's normal to abuse notation, but it may cause confusion if one is unfamiliar with the topic. Try to undo this process if you find it's preventing you from understanding a formula.
Sorry I don't have a recommendation but this seems hard, symbols in math can mean different things depending on the context (the field you are looking in) and at least while I was in undergrad they seemed to change between professors all the time while meaning the same thing.
Hopefully I am wrong and there is a way to learn with a game as with Seterra.
For many equations (e.g. PDEs), there is no direct translation of math to code anyways. This is the point of contact with numerics, integration methods etc. the translation layer between what math expresses and a computer can evaluate.
I think its highly context sensitive whether a declarative approach, like "translate the maths into code", is bad.
Not to pick fights, but your example seems sort of orthogonal to that aspect. What seems more relevant is how you are choosing to structure your code, and how mutable your state is.
That would not be a problem in Practal. That just falls into the non-executable subset. And all that means is that you have not set up equations that are executable and that handle this case. Actually, you could set things up so that this evaluates up to a certain error bound based on a proof of monotone convergence. All without redefining \sum, but by proving additional equations for \sum.
Note that I am not saying that math is code. Practal is based on logic, and logic transcends code. What I am saying is that code is math. At least, that's obviously true for purely functional code. So there is no reason to write the subset of code which is purely functional not in math notation.
Unless the compiler or runtime is smart enough to recognize the limit of that series [1], the naive implementation is an infinite loop which will never terminate.
> Article is mostly fine, but there's a point I vehemently disagree with: you should not, absolutely not translate math notation to code.
Translating math to code in itself is an art (or rather, a technical discipline called Numerical Methods). That's (at least one) full course at any real engineering school.
The article is good, but I would expect anyone calling himself a software engineer to have already studied and mastered the material covered.
Yes, of course there are. Now, imagine you're a language model, and given the prompt "I'm going to write code to explain what a finite summation is", try to predict the probability that what follows is "and I'm going to do it in Idris".
"Compiling" down the product to a fold brings you to the same issue. Though of course it's a lot easier to reason about math in functional programming than in imperative programming, you still lose some of the equational properties that later allow you to derive closed formulas.
Math is equational and declarative. When you write:
you are declaring that we shall call S the sum of the elements of a certain set. You are not prescribing how this sum ought to be calculated: S is a pure value that doesn't depend on what practical operations you do -- be them on paper or on a CPU -- to actually find out what S is.For example, using equational reasoning, we may write:
Or, without computing anything at all, we may prove by induction that: The base case is obvious, and to prove the inductive step it is sufficient to observe that indeed: From which it follows: Tying math to code is more like tying your own hands behind your back.All of this is basically an excuse to point out that the code for the product is wrong, the initial value should be 1 and not 0 (or, in general, your monoid identity).