[bananasbandanas]

For maths, the problem just sometimes lives in a deeper level of abstraction where you need to understand the problem anyway to make any meaningful changes to the code. So I don't think you'd really gain anything by renaming the kalman gain calculation from

K = dot(dot(H, dot(P, H.T)) + R, inv(S))

to

kalman_gain = dot(dot(measurement_function, dot(covariance_matrix, measurement_function.T) + measurement_noise_covariance, inv(system_uncertainty))

because if you don't know what any of these things are by reading up on the theory, the names (or I believe any others) aren't going to help you figure out how a kalman filter works.

[setr]

Names won’t help you understand the fundamentals. It will help you follow the logic, given the fundamentals are understood.

For example I’m reading a PDF now where you have 6 variables involved - 2x2 matrix D which is decomposed to variables [g h], a set of points R, two points defining a parallelogram P and a vector v — where the definitions are a scattered (based on order introduction/definition to the pdf, since they’re used for other things as well).

I have to keep a LUT to follow any given formula because it’s just plain hard to keep track of anything.

And of course, the second I convert it to code, it all gets real names with arbitrary intermediaries and at least I can read it through in a single pass.

Names are there to remind you what the hell you’re talking about. Mathematics on the other hand always try to be as general as possible — your formulas don’t want to discuss anything specific; any object that fits the required properties will do, starting subject/context be damned.

[bananasbandanas]

I agree to some extent of course. If there really are meaningful concepts for intermediates or the whole formula, especially if you are applying it to a specific domain, you should name them.

(I also just looked up the equations and noticed the formula I gave was just completely wrong, so please don't implement a kalman filter like that.)