On Mon, Apr 4, 2022 at 11:55 AM Ken Kundert <python@shalmirane.com> wrote:
I think there is one more point worth making here.  There is a suggestion that
dimensional analysis can underpin a units system.  Actually, the idea that all
units can be broken down into a small set of fundamental units is very limiting
and results in many vexing issues.

For example, consider currencies.  There are currently hundreds of national
currencies and thousands of cryptocurrencies.  They all have the same basic
fundamental unit of “value”, but value is only loosely defined.  Furthermore,
there is no fixed ratio between the currency and its value.  It varies over
time, over location, and from person to person.

Consider units of a particular commodity.  The example of a ream of paper was
recently mentioned. A ream is 500 sheets of paper.  However two reams may not be
comparable.  They may refer to a different size of paper or a different quality
of paper.  So all prices for reams of paper would have the same fundamental
units of “value per each”, but both “value” and “each” are not necessarily
comparable.  In effect, the fundamental unit system is not complete.  You also
need to include information about what you are measuring.  For example, “each”
could represent a single item of anything.  The unit is not complete until you
include a description of what that anything is, and in effect, there is an
unlimited number of things it could be.

Now consider the issue of “unitless units”.  In electrical circuit we often talk
about gain, which it the ratio between the signal level at the output of
a circuit relative to the signal level at the input.  But you need to be
specific about how you measure signal level.  Typically, it would be a voltage,
current, or power level.  Consider a circuit where both the input and output are
measured in volts.  Then the gain would have units of "V/V", which is unitless
in dimensional analysis.  But units of "V/V" (voltage gain) is much different
from units of "A/A" (current gain) or "W/W" (power gain), even though they have
the same dimensions.  Mixing them up results in errors and confusion.  An
additional complication is that sometimes logarithmic units are used.  For
example, decibels in voltage, or dBV, is 20*log(Vout/Vin).  Again,
a dimensionless quantity, but nonetheless "dBV" much different from "V/V".

The same issue occurs with the arguments to trigonometric functions like sin(),
cos() and tan().  Generally, we assume the arguments are given in radians, which
is a dimensionless number.  But it could also be given in degrees, another
dimensionless number.  Radians and degrees are indistinguishable from the
perspective on dimensional analysis, but mixing them up results in errors.

Just lending support to all of these comments. These are universal problems and far far from specific to electrical engineering. In civil we talk about strains and moments; strains are unitless, but they still carry a unit (e.g., in/in) and those units are important. We also talk about moments, which are the same dimensions as for energy (FORCE X LENGTH) but a wholly different thing with different unit expression (e.g., kip X ft). And there is also torque, which is the same units as a moment, but a different concept and you probably shouldn't be adding them together even though they are exactly the same units (someone might want to argue with me about that, I'm unsure).

There is also the 2nd moment of area per length, which is the same dimensions as volume but we express it in different units than volume (in4/in), and there is section modulus per length, which is the same dimensions as area but different units (in3/in), and area per length, which is the same as length, but different units (in2/in or in2/ft). There is also the concept of loads: pressure loads (lbs/sq ft or psi), linear loads (lbs/ft, kips/in, etc), and these probably come out to have the same dimensions are other concepts in other disciplines that should not to be added to them.

Since the concept of what a unit means is very very complex, what Chris A is saying about punting these responsibilities out to others is very powerful idea. I'm uncertain whether the idea of just calling functions as the consequence of applying unit tag to a number is the right solution (but I'm not against it).

I wonder if having a totally separated namespace for the "unit slot" makes some kind of sense. Maybe you say something like:

from pint.SI import as units meter as m, kilogram as kg
from pint.US_Customary import as units feet as ft, pounds_force as lbf

<<NOTE THE "as units" part above!!!>>

...and with the above "as units" imports you can say:

m = "mosquito"
lbf = "low battery freakout"
kg = "kill goliath"
ft = "foolish tolkien"
x = 2m
y = 5kg
a = 4.0ft
b = 4.1lbf

...etc. etc., and you have a unit namespace separate from the regular namespace. The m and lbf and ft and kg in these spaces never conflict.



---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler