Hacker News new | past | comments | ask | show | jobs | submit login

I think being able to interpret common mathematical writing in your area of expertise is a valuable skill. I think this is what is meant by "understanding math".

I don't know much about anything but signal processing, but I am able to read and understand vector/matrix notation and differential equations. This enables me to read most papers published in signal processing. Just like being able to at least roughly read most C-derived programming languages, this is a valuable skill.

I have seen coworkers "not understanding" my work because it involved problem descriptions in mathematic notation. Frankly, it annoys the hell out of me.




I understand mathematical notation, but I do think it generally is best only used when necessary in day-to-day work. Whenever something is of sufficient complexity, trying to keep track of the 10+ variables in a mathematical notation is generally harder than just reading a description.

For a recent example, my thought process yesterday: "So let's see, it says to multiply all of the 'F' functions, from 'm' to 'n'.. 'F' is, what, the base array? OK, so that makes 'm' and 'n'.. hmm. Let's come back to that. OK, so we multiply the product of those 'F's times the product of all 'alpha's of 'm,n' over 'm'.. so alpha is, let's see, the.. message? And... uh.."

Long story short, I finally deciphered it just meant "Multiply the base array of values by the value of each message that comes in that shares a parameter," only it took about 5 minutes instead of 10 seconds.


Think vector notation. Multiply arrays with matrices to get vectors. Add some sum notations and integrals. All that stuff is tedious to express in code but trivial to express in mathematics.

Also, many more scientific concepts such as gradient descent are most easily expressed using the appropriate mathematic operators like the nabla operator for gradients.


You're right, I don't want to give the impression that it's never warranted. Just that it's important to give thought to if a simple description or even a graph might be more efficient in each case.

I try to stay mindful of the limits of short term brain storage.. if there's over 7 unique variables or interval indicators, it might be tough for someone unfamiliar with what's going on to pick it up without wasting extra time noodling on it. When you've got a sum over 'm', a sum over 'm,n', a product sum over 'n,x' and another over 'x', etc.. sometimes it's just easier to bite the bullet and give a visual aid so the reader's not trying to envision all these overlapping regions in his head while still trying to remember what each is supposed to represent in real life.


How about I write my comments in Turkish? It's your fault you don't understand them, after all.

The art of programming, and of comments, is the ability to communicate to another human, and incidentally to computers. (I believe that was a paraphrase of Knuth.) If the terminology gets in the way of their understanding, then use a different terminology.

(I can fight my way through a mathematics paper, myself. But why be obtuse in your communications?)


Mathematics offers a standardized, internationally accepted notation for its various problem domains. Turkish is not the standard language of software comments. So I don't think the analogy holds.


Neither is math. My guess is that you will find many more Chinese programmers who understand English comments than those that understand high-school mathematics symbols.


I would venture that any such programmers ought not work on a math-intensive domain like signal processing. Sure, not every programmer has to know high school math. You can, for example, do great work with HTML, CSS, and JavaScript without knowing high school math. But there are certain fields where math is unavoidable. Signal processing is one of them. And the internationally accepted notation for such math is part of what you're expected to know.

BWT, I assume you're not saying China uses different mathematical notation. I wouldn't know about that. If so, then that does undermine my argument.


That's because mathematicians need notational flexibility, because more formal (unambiguous) syntax would hurt their ability to digest huge chunks of data at once. At least that's what I read somewhere in defence of mathematical, cryptic and ambiguous notation.

It sounds suspiciously similar to what Lispers say about macros and s-exps, btw ;)


"If the terminology gets in the way of their understanding, then use a different terminology."

Literally the reason mathematics exists.


I think that's an uninformed metaphor because it assumes both math is totally foreign and should be able to be read by anyone. if you write code for a server that handles HTTP requests you wouldn't explain the guts of HTTP in your comments, you'd just assume if the reader wants to know more they'll figure it out themselves.

I think sometimes mathematical definitions, especially advanced ones that rely on simpler definitions, are too complicated/long to recant every time you use them, which you have to. If I want to prove something relating or relying on uniform continuity I don't want to state the definition every time both because its repetitive and because definitions often use the same notation, so I don't want my uniform continuity deltas and epsilons getting confused with my normal continuity epsilons and deltas. Try proving advanced things about field extensions and galois theory using induction like that and you may actually run out of symbols.

That being said it is hard to read real math writing/research which can be both dense and obtuse even if you're used to it. Maybe that's why you need a PhD to consider entering the field.


It merely assumes that his co-workers, who did not fluently speak mathematical notation, should somehow learn a foreign language to keep up. I find the idea of being obtuse toward a co-worker who does not speak the same language someone I would have reservations about working with, myself.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: