3 ms·

I disagree. Instead of writing one letter variable names, one could do the hard work of naming things properly, which software developers often do. Instead of g

I disagree. Instead of writing one letter variable names, one could do the hard work of naming things properly, which software developers often do. Instead of going with one letter or the name of that letter as variable name, which tells your fellow non-mathematicians exactly nothing about what it contains, one could put in the effort and make the code readable. Using these one letter variables forces the reader of the code to either be already familiar with the concept, which that letter refers to, or keep the whole calculation in their head, until the final result, to hope, that they then can make sense of it. It is implicitly requiring outside knowledge. It is shutting out many potential readers of the code. It might still be saved/helped though, if good prose comments are given, that help the reader understand the meaning of the one letter symbols. Whenever I have seen this one letter code salad, I have seen few if any comments, as if the author of the code expects me to magically know, what each symbol stands for. Lets say omega was a vector of weights. Why not name it "weights"? That is much better naming than "omega" or that character, that most cannot easily input and need to copy paste from somewhere.

geraneum 5y ago
Well yes, clarity and good practices can definitely help but to be fair, software developers might often do this: (_ < 5) Instead of this: (e: Int) => (e < 5) It’s just a trivial example so I understand if someone wants to have the same comfort. I am not a mathematician so I am not sure what is best here so I’d cut them some slack.
kaba0 5y ago
Mathematicians have been thinking about nomenclature for a long time - certain fields have very specific usage of symbols. I see no evil in using these well-known one-letter variables in these rare/small parts of functions.
- taeric 5y ago
  Sorta. Examples abound of notation that had changed or that is adapted for some fields. Complex numbers using j instead of i, for example.
Chris_Newton 5y ago
I like the rule of thumb that an identifier in code should usually be longer and more specific as scope increases. The main exception is that if your problem domain has well-established terminology or notation for some concept, reflecting that as closely as possible in the code is often best. So, I personally have no problem with someone using short identifiers and concise notation if it’s either used very locally or idiomatic. For example, suppose we have a function whose job is to calculate two vectors of weights and do something unless they are equal but opposite. Personally, I would rather read something like v = someCalculation() w = someOtherCalculation() if (v ≠ -w) { doSomething() } where we use short names for the local variables and vector-aware unequality and negation operators, than read something like weights1 = someCalculation() weights2 = someOtherCalculation() if (not(vector.equals(weights1, vector.negate(weights2)))) { doSomething() } The longer but still arbitrary names for the vectors add no value here and the longhand function names for manipulating them are horrible compared to the short and immediately recognisable vector notation. In general, I think there could be advantages to using a broader but still selective symbol set for coding, as long as we also had good tool and font support to type and display all of the required symbols. I would be hesitant about including Greek letters in that symbol set, but that’s because several letters in the Greek alphabet look similar to other common letters or symbols, not because I think calling a value ω_0 is a bad idea if that’s how practitioners in the field would all write it mathematically.
BeetleB 5y ago
> Using these one letter variables forces the reader of the code to either be already familiar with the concept, which that letter refers to, or keep the whole calculation in their head, until the final result, to hope, that they then can make sense of it. It is implicitly requiring outside knowledge. It is shutting out many potential readers of the code. When you're writing code for physics, then yes - absolutely: It is intended for other physicists, and the prerequisite is precisely that you have outside knowledge. When they use a symbol like ℏ in a journal article, it is expected that the reader knows it is Planck's constant[1]. Why should they have a different expectation when writing code? To a physicist, -ℏ^2/(2 * m) is a lot more recognizable than -planck^2/(2 * mass). To be clear: The chances that a person who doesn't recognize these symbols will need to read and understand your code are virtually nil. Within a context, single character symbols are very useful. To take a different example, what if I insisted that people should write: 2 add 3 add 7 instead of: 2 + 3 + 7 Would anyone reasonably argue that the former is more readable? We all accept that it's OK that a reader is familiar with the '+' sign. While ℏ is not readable to most, it is likely readable to anyone who is expected to read the code. The thing that really is annoying when writing physics code is the need to explicitly write * for multiplication, and not being able to write fractions the way you would on paper. [1] divided by 2π
BlackFly 5y ago
Formulae simply aren't understood like prose, or more precisely, formulae aren't understood as isolated bits of logic. For plumbing code where the logic is important, descriptive variable names are useful in aiding comprehension of the code. For formulaic code, where verifying the equality of two written expressions (one in code and one in the derivation, possibly on a piece of paper) compactness--so called simplification of equations--is far more important. A formula cannot be understood or verified in isolation by itself: as you say, it can only be truly understood by someone familiar with the content. It is by definition, arcane. But the use of arcane variables aids the practitioner since it leads to more compact expressions which makes it easier to check against another source. You cannot eliminate this arcane aspect from formulae simply by spelling out the names of things. G_{ab} = 8 \pi T_{ab} does not benefit from being converted in code to, einstein_tensor[index1][index2] = 8 * PI * stress_energy_tensor[index1][index2] For a practitioner of physics, this is just unhelpful and takes more effort to comprehend. In the spirit of The Humble Programmer, we have unwisely spent the mental energy of the reader. If you actually expand out the Einstein tensor in terms of the Levi-Civita connection and spell it out instead of using the canonical symbol \Gamma and respectively g for the metric tensor then you will just make an incomprehensible wall of text--especially if you inline the summation. What is added by expanding the variable names? A practitioner has gained nothing and lost familiarity and compactness while a layperson has learned nothing about general relativity except the names of the objects. Don't apply best practices uncritically: they are always premised on context. That being said, formulae would benefit greatly from editors that allow the formula to be visualized next to the code. Sort of like compiling latex; if IntelliJ or some other IDE would actually render the code as a formula in some pane next to the code, that would be the greatest benefit to comprehension of a formula.
- zelphirkalt 5y ago
  In the example, you are not really naming your variable usefully. You are merely transcribing from a one letter variable to its abstract name. You can do that in a general function, where the general concept is expressed, where it would still help me to understand your code and search for concepts and terms online, in case I do not understand what is going on. However, in many contexts it wont be merely an "einstein_tensor", but something that has a meaning in the specific context. Ask yourself what you are doing with that einstein_tensor. What is it used for? Is there a real-world equivalent to the thing you are looking at in the code? Those are the names you should choose in a non-general context and that is why naming things is hard.

geraneum 5y ago

Well yes, clarity and good practices can definitely help but to be fair, software developers might often do this: (_ < 5) Instead of this: (e: Int) => (e < 5) It’s just a trivial example so I understand if someone wants to have the same comfort. I am not a mathematician so I am not sure what is best here so I’d cut them some slack.

kaba0 5y ago

Mathematicians have been thinking about nomenclature for a long time - certain fields have very specific usage of symbols. I see no evil in using these well-known one-letter variables in these rare/small parts of functions.

taeric 5y ago
Sorta. Examples abound of notation that had changed or that is adapted for some fields. Complex numbers using j instead of i, for example.

Chris_Newton 5y ago

I like the rule of thumb that an identifier in code should usually be longer and more specific as scope increases. The main exception is that if your problem domain has well-established terminology or notation for some concept, reflecting that as closely as possible in the code is often best. So, I personally have no problem with someone using short identifiers and concise notation if it’s either used very locally or idiomatic. For example, suppose we have a function whose job is to calculate two vectors of weights and do something unless they are equal but opposite. Personally, I would rather read something like v = someCalculation() w = someOtherCalculation() if (v ≠ -w) { doSomething() } where we use short names for the local variables and vector-aware unequality and negation operators, than read something like weights1 = someCalculation() weights2 = someOtherCalculation() if (not(vector.equals(weights1, vector.negate(weights2)))) { doSomething() } The longer but still arbitrary names for the vectors add no value here and the longhand function names for manipulating them are horrible compared to the short and immediately recognisable vector notation. In general, I think there could be advantages to using a broader but still selective symbol set for coding, as long as we also had good tool and font support to type and display all of the required symbols. I would be hesitant about including Greek letters in that symbol set, but that’s because several letters in the Greek alphabet look similar to other common letters or symbols, not because I think calling a value ω_0 is a bad idea if that’s how practitioners in the field would all write it mathematically.

BeetleB 5y ago

> Using these one letter variables forces the reader of the code to either be already familiar with the concept, which that letter refers to, or keep the whole calculation in their head, until the final result, to hope, that they then can make sense of it. It is implicitly requiring outside knowledge. It is shutting out many potential readers of the code. When you're writing code for physics, then yes - absolutely: It is intended for other physicists, and the prerequisite is precisely that you have outside knowledge. When they use a symbol like ℏ in a journal article, it is expected that the reader knows it is Planck's constant[1]. Why should they have a different expectation when writing code? To a physicist, -ℏ^2/(2 * m) is a lot more recognizable than -planck^2/(2 * mass). To be clear: The chances that a person who doesn't recognize these symbols will need to read and understand your code are virtually nil. Within a context, single character symbols are very useful. To take a different example, what if I insisted that people should write: 2 add 3 add 7 instead of: 2 + 3 + 7 Would anyone reasonably argue that the former is more readable? We all accept that it's OK that a reader is familiar with the '+' sign. While ℏ is not readable to most, it is likely readable to anyone who is expected to read the code. The thing that really is annoying when writing physics code is the need to explicitly write * for multiplication, and not being able to write fractions the way you would on paper. [1] divided by 2π

BlackFly 5y ago

Formulae simply aren't understood like prose, or more precisely, formulae aren't understood as isolated bits of logic. For plumbing code where the logic is important, descriptive variable names are useful in aiding comprehension of the code. For formulaic code, where verifying the equality of two written expressions (one in code and one in the derivation, possibly on a piece of paper) compactness--so called simplification of equations--is far more important. A formula cannot be understood or verified in isolation by itself: as you say, it can only be truly understood by someone familiar with the content. It is by definition, arcane. But the use of arcane variables aids the practitioner since it leads to more compact expressions which makes it easier to check against another source. You cannot eliminate this arcane aspect from formulae simply by spelling out the names of things. G_{ab} = 8 \pi T_{ab} does not benefit from being converted in code to, einstein_tensor[index1][index2] = 8 * PI * stress_energy_tensor[index1][index2] For a practitioner of physics, this is just unhelpful and takes more effort to comprehend. In the spirit of The Humble Programmer, we have unwisely spent the mental energy of the reader. If you actually expand out the Einstein tensor in terms of the Levi-Civita connection and spell it out instead of using the canonical symbol \Gamma and respectively g for the metric tensor then you will just make an incomprehensible wall of text--especially if you inline the summation. What is added by expanding the variable names? A practitioner has gained nothing and lost familiarity and compactness while a layperson has learned nothing about general relativity except the names of the objects. Don't apply best practices uncritically: they are always premised on context. That being said, formulae would benefit greatly from editors that allow the formula to be visualized next to the code. Sort of like compiling latex; if IntelliJ or some other IDE would actually render the code as a formula in some pane next to the code, that would be the greatest benefit to comprehension of a formula.

zelphirkalt 5y ago
In the example, you are not really naming your variable usefully. You are merely transcribing from a one letter variable to its abstract name. You can do that in a general function, where the general concept is expressed, where it would still help me to understand your code and search for concepts and terms online, in case I do not understand what is going on. However, in many contexts it wont be merely an "einstein_tensor", but something that has a meaning in the specific context. Ask yourself what you are doing with that einstein_tensor. What is it used for? Is there a real-world equivalent to the thing you are looking at in the code? Those are the names you should choose in a non-general context and that is why naming things is hard.