I use what I thought was dimensional analysis very often after learning about it 10+ years ago during my Physics studies. It's a very powerful technique to both check that your equations are correct (i.e. do the same equations but just with the concrete dimensions and you should end up matching with the dimensions of your result) and checking you have correctly carried the magnitudes (kilo, giga, etc.).
I've never seen dimensional analysis without using concrete dimensions, so this blog post was really eye opening. It seems a little magic to me, so I'm interested to learn more about a quick and helpful technique I thought I mastered.
Yeah, in this case it's a bit misplaced. The first thing your high school calculus course would have you do would be called “u-substitution”, and if you did directly u = x √(a), du = √(a) dx you would get the same immediately, or if you did something stranger like u = a x², dx = ½ du/√(a u) you would get
(1/√a) ∫ exp(-u) u^-½ du
which furnishes a handy proof that (-½)! = √π, once you know the Gaussian integral.
I'm glad we had a similar reaction because I went in with the mindset of concrete dimensions. It helped me a lot in Chemistry classes with all those mols.
Another good example of this is the relationship between the period of a pendulum (T), its length (L), and the acceleration due to gravity (g). Since L is measured in m(eters), T is in s(econds), and g is m/s^2, there is only one way to combine these quantities that will give the right units : T ~ sqrt(L/g). And that's the right answer, up to a constant.
I think there's an interesting parallel to this usefulness in code which the author just briefly mentioned. Static typing can help bridge thoughts about what makes sense to do ("I have a callable with signature (x: int, s: str) -> str, and this function I need to use is (s: str) -> str; huh, my x here is fixed, does it make sense to make a partially applied function? yes, that'll work") as well as, of course, verifying all assumptions make sense at some level (types matching is a necessary, though not sufficient, condition).
Then there's more power unlocked by giving dimensions/units to your types/instances. For instance, overloading the division operator in a class representing length so that when dividing length by time, you get speed. Or, one could overload addition/subtraction in classes representing a currency so that trying to add ¥100 to $100 raises an exception.
In general I think there's a lot of interesting applications for the information that comes along with numbers that we usually just discard. Things in the real world aren't dimensionless that often, and yet our code almost always treats them as if they were.
> Then there's more power unlocked by giving dimensions/units to your types/instances. For instance, overloading the division operator in a class representing length so that when dividing length by time, you get speed. Or, one could overload addition/subtraction in classes representing a currency so that trying to add ¥100 to $100 raises an exception.
I sometimes even go one step further and use specific types for dimensionless factors in financial calculations, such as specific types for the rates of different kinds of taxes. This way I get a compiler error, when I am trying to use the wrong type of tax rate in a calculation.
I had a similar experience in university. I used to take advantage of our mathcad licence. If you specified units for the variables, you could identify mistakes in your equations and functions very quickly. For example, if you wanted meters, but you got m^(2/3), it was usually obvious where in the equation something went wrong.
Another bonus was I could focus on the equations and then output the final answer in either metric or franken-imperial, as the homework assignment required (I did my undergrad in the US.)
> If you specified units for the variables, you could identify mistakes in your equations and functions very quickly. For example, if you wanted meters, but you got m^(2/3), it was usually obvious where in the equation something went wrong.
You can take it even one step further and write tests to check the resulting units for you.
You could take it a step further and specify the domain and range of your functions. The division operator for example take any real number except 0 – Zero is a special undefined case specifically for division.
Although string types seems intractible, you could easily specify things like [a-zA-Z0-9], or character sets/UTF ranges for limiting inputs to certain languages. All list types (strings, arrays) could specify length as a limit.
Programmers would naturally want flexibility with domain enforcement, so could just write a (turing complete) function to which returns the domain of the function in question!
Some languages feature support for this. F# has it built-in and refers to it as units of measure. Julia has it available as a package named Unitful.jl.
One of my teachers when studying Physics spent some classes teaching us about dimensional analysis, and since then it has been one of my favourite tools. I remember solving an electromagnetism multiple choice test using dimensional analysis, it felt almost like cheating.
A few years ago, I wrote a paper with other collaborators[1] on how to use dimensional analysis as a way to improve feature selection, that can in turn improve machine learning performance for physical/chemical systems, especially those with small datasets. Full manuscript is available through researchgate[2]
This is interesting! Where can I find more information about people using ML models for the physical world that is not drug discovery or anything about proteins?
if you look into sciml stuff in the Julia community there's a bunch. some example use cases are trajectory optimization, and accelerating climate simulation. often these ML models are referred to as "surrogate models". let me know if you have more questions, I can probably point you in the right direction.
Dimensional analysis is one of the most underrated techniques out there. All too often we are taught how to solve equations, but it is equally important to think about how to reason with equations and how to examine the properties of solutions without having to even solve the equations themselves. Sometimes it becomes another quick check you can use to spot careless mistakes, but sometimes you can also use it for much deeper insight, like Kolmogorov's theory of turbulence. I wish more people were aware of it.
The book this blog post is based on -- Sanjoy Mahajan's "Street-fighting Mathematics" -- is a fantastic read. It is a bit like watching cirque du soleil; I don't come away having internalised much because I have no practice thinking that way, but I come away hugely entertained!
That wonderful book is basically upper college level dimensional analysis.
It unfortunately skips the basic level that you learn a little about in high school.
This makes sense because the book was originally a PhD thesis about solving research level problems with dimensional analysis, so the easy problems were already solved, but makes it a bit of steep start for the casual reader who doesn't already understand the basic idea.
I understand the basic idea of dimensional analysis well enough in the context of college level physics. But that is only one part of the book; it is a catalog of impressive tricks (approximation, analogy, visual proofs) that Mahajan has accumulated over a long duration.
The review on ams.org (by a structural engineer, not a mathematician) mirrors my difficulty (and fascination) with the book.
Ha! Seeing the headline, I was going to say that this is basically the intro to Street Fighting Mathematics. Reading it, I thought I was just having deja vu with how similar the treatment was. Fun book.
I always think of dimensional reduction when I see these headlines, which is sadly very unrelated.
> I always think of dimensional reduction when I see these headlines, which is sadly very unrelated.
Actually, the two are related. The Buckingham pi theorem of dimensional analysis guarantees the reduction of the number of variables ("dimension" in a different sense) in many instances.
I've never seen dimensional analysis without using concrete dimensions, so this blog post was really eye opening. It seems a little magic to me, so I'm interested to learn more about a quick and helpful technique I thought I mastered.
(1/√a) ∫ exp(-u) u^-½ du
which furnishes a handy proof that (-½)! = √π, once you know the Gaussian integral.
You can't just multiply the thickness of the material (scalar meters) to get Watts vs. temperature difference.
You need to DIVIDE by it to get conductance (W/(m^2⋅K)) and THEN figure out the area the transfer is occurring over.
I think there's an interesting parallel to this usefulness in code which the author just briefly mentioned. Static typing can help bridge thoughts about what makes sense to do ("I have a callable with signature (x: int, s: str) -> str, and this function I need to use is (s: str) -> str; huh, my x here is fixed, does it make sense to make a partially applied function? yes, that'll work") as well as, of course, verifying all assumptions make sense at some level (types matching is a necessary, though not sufficient, condition).
Then there's more power unlocked by giving dimensions/units to your types/instances. For instance, overloading the division operator in a class representing length so that when dividing length by time, you get speed. Or, one could overload addition/subtraction in classes representing a currency so that trying to add ¥100 to $100 raises an exception.
In general I think there's a lot of interesting applications for the information that comes along with numbers that we usually just discard. Things in the real world aren't dimensionless that often, and yet our code almost always treats them as if they were.
I sometimes even go one step further and use specific types for dimensionless factors in financial calculations, such as specific types for the rates of different kinds of taxes. This way I get a compiler error, when I am trying to use the wrong type of tax rate in a calculation.
Another bonus was I could focus on the equations and then output the final answer in either metric or franken-imperial, as the homework assignment required (I did my undergrad in the US.)
You can take it even one step further and write tests to check the resulting units for you.
Although string types seems intractible, you could easily specify things like [a-zA-Z0-9], or character sets/UTF ranges for limiting inputs to certain languages. All list types (strings, arrays) could specify length as a limit.
Programmers would naturally want flexibility with domain enforcement, so could just write a (turing complete) function to which returns the domain of the function in question!
Dimensions are the equivalent of typing in programming. It can help you write valid programs without having to run them in order to verify it.
[1] https://pubs.acs.org/doi/abs/10.1021/acs.chemmater.8b02837
[2] https://www.researchgate.net/profile/Janakiraman-Balachandra...
https://ocw.mit.edu/courses/18-098-street-fighting-mathemati...
The reading list has a link to both the printed version and a free pdf of the book.
It unfortunately skips the basic level that you learn a little about in high school.
This makes sense because the book was originally a PhD thesis about solving research level problems with dimensional analysis, so the easy problems were already solved, but makes it a bit of steep start for the casual reader who doesn't already understand the basic idea.
The review on ams.org (by a structural engineer, not a mathematician) mirrors my difficulty (and fascination) with the book.
https://www.ams.org/notices/201107/rtx110700960p.pdf
I always think of dimensional reduction when I see these headlines, which is sadly very unrelated.
Actually, the two are related. The Buckingham pi theorem of dimensional analysis guarantees the reduction of the number of variables ("dimension" in a different sense) in many instances.
https://en.wikipedia.org/wiki/Buckingham_%CF%80_theorem
This fact is frequently used in experiments in some areas of physics to reduce the number of tests.