Just like there can be stronger and weaker type systems, there can be stronger and weaker unit systems. Stronger unit systems catch a larger class of errors. I commonly catch errors nobody else sees because I use a stronger unit system than they do, which is amended with generics ("kg of what?"). Just like you said: a unitless quantity is weak; ppm doesn't help you catch errors very well. It could be mg/kg or µL/L, and it matters when you start canceling ratios. But you can take it further: mg<constituent>/kg<soil>. When you start throwing in soil density and molecular mass, it's very easy to come up with examples that "pass" the standard dimensional analysis but "fail" your advanced unit checker. You can look like a wizard by detecting errors in equations completely outside of your field of expertise.
Once you realize that there can be as many unit-systems as type-systems and the only criterion for a good vs. bad unit system is how well it catches errors, the purists who try to enforce their physics textbook's view of units will look really silly to you. The only problem is that you start arguing with them about whether specific gravity is really unitless or not (it's more helpful to say it's not), and they immediately decide you must be a moron because that's not what their textbook says. Oh well. You're getting the right answer, and they're not.
Another useful tidbit is if your formula has a log or an exp, the arg needs to be dimensionless.
I have cognitive dissonance about that. I understand that if you look at the Taylor series of Exp(x), you're clearly adding terms containing 1, x, x^2, x^3, etc., and that it doesn't make sense to add a meter to a square meter to a cubic meter and so forth. So therefore Exp(1m) doesn't/shouldn't make sense.
But on the other hand, I can come up with examples that seem to make sense, but seem "dimensionful". Is a bit dimensionless? Because it certainly makes sense to consider 2^(32 bits) and 2^(4 bytes). Yet bits are deeply related to entropy and might even be considered a unit of energy. Are we sure they're dimensionless? What is a "square bit" anyway?
I can also define "specific meters" to be the length of an object divided by the length of a 1-meter-long stick. This value is now dimensionless, so it should be OK to exponentiate it, correct? Am I cheating? How?
Or I should be allowed to take Log(7 mg/kg) because mg/kg is dimensionless. But this should equal Log(7 mg) - Log(1 kg), which I'm not allowed to do. What gives?
Again I come back to: is this actually helping me catch errors in my calculation? I'm honestly not sure here.
If you want to talk about e^(x) then you're totally free to do that but, you're right: if x is not dimensionless then the expression has no physical meaning (as little meaning as one meter added to one second, as an example of another clearly nonsensical physical function).
In Physics, your starting point always makes sense dimensionally (F=m*a, E=m*g*h) and the game is to combine expressions that make dimensional (and physical) sense to glean insight into how different physical constraints of the system are related.
If you have any Physics problem where you end up with e^(x) or sin(x) and x is not dimensionless then it's a dead giveaway that you performed an algebraic misstep at some point when playing the game.
So, in short, you can propose a lot of functions that make no sense from a physical standpoint, but you won't arrive at those if you're working from first principles which are, by nature, dimensionally consistent.
As for Log of a unit, if it is useful in some strange circumstance, would require a different unit to keep track of (like logkg), similarly to i (the imaginary unit) being the result of sqrt(-1).
I'm not sure I can think of a case where you can do otherwise.
Entropy is J/K and seems to follow the same dimensionality constraints as everything else, though I'm not well versed in information theory so I don't know how they think about it.
The log example only works because log only takes a dimensionless parameter. The only way to get that is to cancel the two kinds of meters and shove the dimensionless 0.007 into it. Ie it is a type error to take the log of 7mg or anything with a unit.
One interesting thing I came across is in the cpp book by Stroustrup he actually builds a custom type system capable of preventing issues like this and uses physics examples.
Can you please share some examples other than adding specifiers about material e.g. 3 mg of plutonium, 5 L of argon, etc?
I can think of at least one other criterion for checking unit systems - ease of computation. See, for example, MKS vs Gaussian units.
I don't have concrete examples other than adding in "of X material" when appropriate (e.g. mass and volume, but not energy), but don't underestimate how useful that really is. One calculation I encounter a lot that is wrong a troublingly large amount of the time, despite passing a traditional dimensional analysis, is this one:
Calculate the mass of SO2 produced from burning 1,000 moles of gas with a molecular weight of 24 g/mol containing 2% H2S by weight (and no other sources of sulfur).
It's not hugely complicated: there are really only two units to keep track of here (g and mol) but they can be "of" three different materials (whole gas, SO2, and H2S), so it's very easy to cancel terms when you really shouldn't if you analyze it traditionally. With the materials attached to each unit, you're also forced to include a term that is otherwise invisible (the stoichiometric ratio of SO2 to H2S, which is usually omitted because it's 1), which helps guide your intuition on how the calculation relates to the chemistry of what's happening and helps you come up with the correct calculation when more complicated chemical reactions are involved.
The reason your quantities (LMT etc) are dimensionless is because you need to bake a decent cake or mix a cocktail and get a grip 8)
I am being flippant but I don't think that mixing kilos and meters in any unlikely ratio is likely to end well. They tend to become quite forceful if not mixed carefully.
You have to pick your time(zone) when deploying them. I generally find that GMT/UTC >=+6 is when a sense of humour failure generally kicks in. At +8 it relents a bit when en_AU kicks in and is reinforced at +11 by en_NZ.
I don't! Also, doing this would go against my belief that I already mentioned on HN several times - that the difference between process chemistry and cooking is that the former actually cares about the quality of outcome ;).
https://www.bode-science-center.com/center/hand-hygiene/hand...
But that makes little sense - we're measuring the number of simultaneous calls. It gets reflected in buffers, circuits, sockets, channels allocated, etc.
It would be better to consider 'call starts / second' as the rate at which calls are initiated, and the average 'call.seconds / call start', which when multiplies gives the more sensible unit 'call'.
Or simpler: just measure the average length in seconds. So we have so many 'calls / second' initiated, and the average length is so many 'seconds', which when multiplied again gives a unit of 'call'.
Like saying a foundation footing has 27-ft^3/ft of concrete.
I'd say the same applies in this case. It'd be more "calls/sec" times "active phone * sec/calls". Though I guess for "call" in your case or "active phone" the industry has chosen 'Erlang' a bit recursively.
I wonder if there's been any study into when it's ok to cancel two of the same unit and when it's better to leave it as a ratio of two quantities with the same unit but describing different dimensions. Is there a way to make this notion precise?
Dimensionless numbers are the opposite of a smell - they are the most pristine, fresh quantities you can get in physics.
You usually want to express everything you possibly can in a dimensionless way. It tends to make the math a lot simpler and to punch to the heart of the problem.
Wouldn't it make more sense to describe those distances as vectors instead of overloading their dimensions?
It wasn’t at all obvious that removing the 1/2 and using c as your velocity would be meaningful.