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 writing a dimensional analysis based units 
package.  In general, dimensional analysis is something you do once, not every 
time the program runs.

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/

Reply via email to