> 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.
Considered. Within a single currency system, units are well defined in a
relative since (i.e. - cents per dollar). But in an absolute sense, units of
currency do not have infinite precision, which makes them outside of the scope
of this problem and proposal. Give financial folks support for dollars and
cents or, other units in other currency systems if need be, but they're SOL for
as far as native language conversions between currencies. They'll otherwise
have to stick with unitless, implied numbers rather than explicit units. In
other words, their world does not change.
> 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 ofanything. The unit is
> not complete until you include a description of what that anything is, and
> ineffect, there is an unlimited number of things it could be.
Considered and in my opinion should be rejected from inclusion in any sort of
PEP that leads to native support of standard units, because these are not
standard units. And supporting standard units in native language is not going
to break anything that currently works.
> 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".
I cannot think of a low level implementation of units that would support
dimensional analysis that would catch problems with adding a quantity expressed
in "V/V" to a quantity expressed in "A/A". But like ChrisA pointed out, there
is "float" and there is "Decimal". If there is a need for units that go beyond
low level implementation of SI units, then why should this be a blocker for
native language support for units?
At a low level, there are 7 dimensions that need to be accounted for in order
to support anything that a higher level of code wants to do. There is even a
low level way to tell Python how to interpret unitless dimensions using
explicit casting, which covers a big chunk of what modules like QuantiPhy say
they do, and more. What a low level, native representation of units cannot do
is figure out what the preferred type of a unitless value like A/A, or even a
unit value like N*m after the result of a calculation. The best it can do is
provide defaults, and leave it up to the programmer to explicitly cast where
needed. But that is true even today with binary operations combining floats and
ints. There is a default way that these operations are done, and if that
operation does not meet your need, then you must explicitly cast.
> 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.
Considered, and this is tricky. I do not have an answer at the moment.
> This is not to knock the idea of dimensional analysis. It is just not
> something that would be done in most programs that process physical
> quantities. Rather it is something that is largely done as a one-time check
> on your analysis. It is a “second opinion” on whether your hand calculation
> are correct, or at least plausible. So dimensional analysis packages such as
> pint have their place, but dimensional analysis is not something that belongs
> in the base language or even the standard library.
So you're saying that because you can't implement all possible aspects of
dimensional analysis at a native level, it is not worth implementing any?
> However I do believe that a case can be made to allow numbers to be easily
> tagged with units in the base language, and then allowing those units to be
> accessed as an attribute of the number. Packages such as pint and QuantiPhy
> could then use that attribute to provide processing of units that is
> appropriate for the particular application.
This is QuantiPhy in action:
```
import quantiphy
A = quantiphy.Quantity('2m')
B = quantiphy.Quantity('5m')
A + B
# 0.007
type(A)
# <class 'quantiphy.Quantity'>
type(A + B)
# <class 'float'>
```
How is that useful? It does not even come close to solving problems that I have
encountered in the real world.
pint has struggled with NumPy, and as far getting colleagues that I have worked
with to use it, they stop dead in their tracks as soon as they see
dot-notation. And I can understand the reaction of "well, if they don't like
dot-notation, and therefore 90% of what makes Python Python, then why help
them?" Because I'm a people pleaser, because helping them helps me, and because
why not?
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/L4PLZCORVFEQX3W6H6RA4RHQOPZRLXTD/
Code of Conduct: http://python.org/psf/codeofconduct/
