On Mon, 2022-04-04 at 09:14 -0700, Ken Kundert wrote: > As why it is naive, see my previous post where I talk about the > limitations of dimensional analysis. > > As a point of reference, I have been developing software for > electrical engineers for over 40 years. That software uses physical > quantities (voltage current, resistance, capacitance, etc.) heavily. > Over those 40 years I have written and rewritten units packages maybe > a half-dozen times. In that time I have never seriously considered
Are there any Python or e.g. C/C++ libraries that may be useful to wrap
for Python that are open source? There is interest in making units
available to NumPy through a DType directly on the NumPy array.
I.e. not quite the same way as `astropy.units` or `pint`, but rather
ingraining deeper into NumPy (but written outside).
And it would be great to have a full featured units library as a basis
for this.
> writing a dimensional analysis based units package. In general,
> dimensional analysis is something you do once, not every time the
> program runs.
>
I would say it actually is often something you are happy to do every
time the program runs. If you think about NumPy (like) usage, there
are at least two use-cases:
1. You have a mid-to large sized amount of data. Figuring out units
probably just doesn't matter performance wise.
2. You don't care about performance anyway, but rather about
flexibility in your analysis workflow.
Now, libraries may often need to strip units for more performance.
That is, for example while running machine-learning algorithm or an
integration, etc.
But, I think it is fair to say that often reversing the approach may
well be good: Use units by default, but strip them for performance.
I can understand the idea of a (soft) "literal operator", i.e. so that
it is possible to write:
from units import cm, s
length = 1.8_cm
speed = length / 3_s
And it would use `cm.__from_literal__("1.8", kind="floating")`.
Of course that could be incompatible with other unit providing
libraries (unless they agree on some ABC). I assume this is what C++
does?
I am unsure that "tagging" in itself is helpful. What will:
1.3_m / 2_s
give you? A `TaggedFloat(1.3, "m")` object may work. But can such a
naïve units even propagate clearly enough that it can be reasonably
implemented in a generic way?
(Unless there is a blessed standard library units implementation at
least.)
Cheers,
Sebastian
> As for links to the previous discussion, search for “SI scale
> factors”. The discussion occurred 5 years ago.
>
> -Ken
>
>
> On Mon, Apr 04, 2022 at 03:06:26PM -0000, Brian McCall wrote:
> > > Much of this discussion is based on a misconception. Units and
> > > SI scale factors
> > > are very useful in software that describes or interacts with the
> > > real world, but
> > > primarily on input and output. They are not normally used for
> > > internal
> > > calculations. The idea that one carries units on variables
> > > interior to
> > > a program, and that those units are checked for all interior
> > > calculations, is
> > > naive. Doing such thing adds unnecessary and often undesired
> > > complexity.
> > > Rather, it is generally only desirable to allow users to include
> > > scale factors
> > > and units on values they specify and values they read. This
> > > implies that it is
> > > only necessary to provide a package for reading and writing
> > > physical quantities,
> > > and indeed such a package exists: QuantiPhy. QuantiPhy came out
> > > of the ideas
> > > that were raised the last time this topic was discussed on this
> > > mailing list
> > > a few years ago.
> >
> > Why is it naive to carry the units through calculation? Seems to me
> > that a one-byte lookup and a 64-bit add/subtract would be enough to
> > enable any plausible combination of standard units during
> > computation. The conversion from raw powers of 7 base SI units to
> > units of choice could be done at a higher level code at the
> > input/output stage.
> >
> > QuantiPhy is definitely not what I am thinking of. You don't happen
> > to have a subject line for the previous discussion that I can look
> > up, do you?
> > _______________________________________________
> > 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/PL3UHVROZFO3FIH2OZZJQF3R3YDWMM4S/
> > Code of Conduct: http://python.org/psf/codeofconduct/
> _______________________________________________
> 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/NYVZMEG4UKUAO6XNR6NRZKSBJEEO4MBH/
> Code of Conduct: http://python.org/psf/codeofconduct/
signature.asc
Description: This is a digitally signed message part
_______________________________________________ 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/7HTHS7W5BWRUS3BKTCDSFWCDWOY4QGOL/ Code of Conduct: http://python.org/psf/codeofconduct/
