subject:"\[Python\-ideas\] Re\: Native support for units \[was\: custom literals\]"

On Wed, Apr 06, 2022 at 03:50:35PM -, Brian McCall wrote:

> Stephen J Turnbull and Paul Moore have asked why the "need" for 
> something other than a library (or perhaps a better library). There 
> are a number of examples that show simple unit calculations and it's 
> easy to argue based on those that nothing further is needed. I think 
> more complicated counter-examples could help push back against this, 

Thanks for the extensive example, but it is still a *simple* unit 
calculation. It is basically just a longer version of `n = b*c/d`, only 
with ten variables instead of three.

All of the library's formats seem reasonable to me in the example you 
give. Syntax is important, but in this case all you are doing is binding 
a literal quantity with its unit to a name, and for that purpose, the 
syntax is 
not that important. What does it *really* matter which of these you 
write?

h = 6.62607015e-34[m**2*kg/s]
h = unit('m**2*kg/s')(6.62607015e-34)
h = 6.62607015e-34 * units.m**2*units.kg/units.s
h = 6.62607015e-34 * m**2*kg/s
h = Quantity('6.62607015e-34 m2kg/s')
h = unit(6.62607015e-34, "m2kg/s")

Yes, you have to learn a slightly different notation for each, but every 
branch of science and engineering has their own notation and conventions 
which needs to be learned.

For constants, that's just arguing over the colour of the bikeshed.

The aim of your post here was to try to justify why units have to be 
built into the language, rather than supported via a library. You have 
done a reasonable job of showing that calculations with units are 
useful, but nobody denied that. Regardless of the individual strengths 
and weaknesses of the existing libraries, you have shown nothing to 
justify why unit support must be built into the language itself.

-- 
Steve
___
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/I6OSC3KJDQ5VC6W62GI2QF3TWVIRY27W/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

On Wed, Apr 06, 2022 at 11:48:44PM -0700, Ken Kundert wrote:

> Perhaps a better approach would simply be to build 
> a units aware scientific calculator application.

The Python REPL makes an awesome interactive calculator.

Sagemath has done what you suggest: it is a powerful symbolic maths 
calculator written in Python and Cython. And it has units:

https://doc.sagemath.org/html/en/reference/calculus/sage/symbolic/units.html


-- 
Steve
___
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/Y4VI6C26LNZPNXVNURGW6S35FNYJBWEF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

On Wed, Apr 06, 2022 at 08:36:35PM +0100, Paul Moore wrote:
> 
> compactness isn't typically regarded as a significant
> selling point for a proposal.

I would word that differently.

Compactness *alone* isn't typically regarded as a *compelling* selling 
point, and *excessive* compactness is regarded as a negative.

("Excessive" may be subjective. But we're not trying to emulate Perl or 
APL.)

> It's not as close to natural language as "30 ms", but again, that's a
> fairly minor disadvantage in these types of discussion (and opens up a
> lot of debate about subjective issues like what "looks natural").

And then you have a problem that units in natural language is ambiguous. 
5ft 6in is not an area.

The Unix program units tries to deal with the ambiguity by introducing a 
second division symbol, |, and Frink deals with it by just telling the 
user to use parentheses where needed.

> I don't know why .decompose() is needed, but again that's an
> implementation detail of astropy.

Correction: it is part of the astrophy interface. Other libraries have 
different interfaces.

-- 
Steve
___
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/UO6W3SK7K4HINAYOJBPF433VBSBBOJ45/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

On Wed, Apr 06, 2022 at 04:54:15PM -, Brian McCall wrote:

> Oops, my examples have some other problems:
> 
> > # λ  = 550e-9nm
> 
> should be 
> 
> > # λ  = 550nm

This is an excellent example of why unit tracking, or any other 
programming system, is not a panacea. No programming system in the world 
is going to save you if you type x = 135 when it should be x = 315.

-- 
Steve
___
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/XQQI6N7TY6AZ6KCOERMA4NEBI2UC56II/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

2022-04-07 Thread Stephen J. Turnbull

Chris Angelico writes:

 > > It's very difficult to get *any* syntax change in.  In particular,
 > > changing '_' from an identifier component to an operator for
 > > combining numeric literals would invalidate *tons* of code
 > > (including internationalization code that is the 0.454kg nearest
 > > my heart).  I can't imagine that being possible.
 > 
 > >>> 123_456
 > 123456
 > >>> 123_456_
 >   File "", line 1
 > 123_456_
 >^
 > SyntaxError: invalid decimal literal
 > 
 > Trailing underscore is currently invalid, so that would be fine.

I really meant "operator", not just syntax.  It was an extreme example.

___
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/WNR75C4FNFF5LUTMVFMFVLGOUSBOSYW7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

2022-04-07 Thread David Mertz, Ph.D.

On Thu, Apr 7, 2022 at 10:51 AM Stephen J. Turnbull <
stephenjturnb...@gmail.com> wrote:

> NOTE: The big problem I see with this is that I don't see any
> practical way to use syntax for non-numeric types like ndarray.
> The problem is that in, say, economics we use a lot of m x 2
> arrays where the two columns have different units (ie, a quantity
> unit and a $/quantity unit).  The sensible way to express this
> isn't some kind of appended syntax as with numbers, but rather a
> sequence of units corresponding to the sequence of columns.
>

Here's a few minutes of work by me:

>>> df = pd.DataFrame([['Apples', 11, 2], ['Pears', 12, 3]],
...   columns=[Units("Item", "Kind-of-Fruit"), Units("Per-Bushel",
"USD/bushel"), Units("Number")])
...
...
>>> df
 Item  Per-Bushel  Number
0  Apples  11   2
1   Pears  12   3
>>> df.columns[1].units
'USD/bushel'


I did this by defining:

>>> class Units(str):
... def __new__(self, s, units="Dimensionless"):
... return str.__new__(self, s)
... def __init__(self, s, units="Dimensionless"):
... float.__init__(s)
... self.units = units


If this were actually needed, I'm sure better interfaces could be created.
But this very simple thing is a possible way to retain units per-column.

-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
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/5GC5PZJJDHZRMIG7X46GDUCQOQSM5I5H/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

2022-04-07 Thread Chris Angelico

On Fri, 8 Apr 2022 at 00:48, Stephen J. Turnbull
 wrote:
> 1.  Syntax, aka language support (the original suggestion of
> user-defined literals fits here because either the way numbers are
> parsed or the way '_' is parsed would have to change).
>
> It's very difficult to get *any* syntax change in.  In particular,
> changing '_' from an identifier component to an operator for
> combining numeric literals would invalidate *tons* of code
> (including internationalization code that is the 0.454kg nearest
> my heart).  I can't imagine that being possible.

>>> 123_456
123456
>>> 123_456_
  File "", line 1
123_456_
   ^
SyntaxError: invalid decimal literal

Trailing underscore is currently invalid, so that would be fine.

ChrisA
___
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/5NWOFCEKMKMLXUNEJCF4GTPY6WPOMRDB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

2022-04-07 Thread Christopher Barker

After reading this long thread, a few notes:

[preface: I write this as someone whose entire career is based on doing
computation with Python, and with systems where physical units are critical
and complex, and who maintains a fair bit of my own custom unit-oriented
code -- this is not hypothesis]

1) It is absolutely absurd to even talk about this without consideration of
the scipy community -- there has been some mention, but it seems to have
been largely skipped over. I think this whole thread started (Or at least
it was mentioned early on) with a note that Python could be THE engineering
tool (which now that I say it, was a quote from a Professor of mine from 25
years ago -- applying to MATLAB :-) ) if it included good unit handling.
But it's not actually Python that has become so widely used in the
engineering/science/data analysis world -- it's the "Scipy Stack" / "numpy
ecosystem", whatever you want to call it.

Along those lines, there was some talk about astropy.units about how they
only work with numpy arrays, and that's a limitation -- but it's really not
a critical one. The fact is that anything that doesn't work with numpy
arrays is dead in the water for widespread use in the engineering/science
community. Whereas not working with the built in scalar types is a minor
limitation.

2) As for the SciPy community, I've lost track a bit of the current status,
but about ten years ago there was a nice talk at the SciPy conference about
handling physical units -- the conclusions at that point were:
 * There are a dozen or so libraries to do it
 * a few of those are pretty darn good
 * there is no obvious "best" one.
Given the continued existence of astropy.units, and pint, and SciMath
units, and wrappers around C libs, like udunits, and . I think we're
still in that state. What does this tell us? Well, the scipy community is
full of a lot of really smart people that are trying to get real work done,
and tend to be very cooperative: if there was one clear winner, it would
have risen to the top by now. Which tells me that unit handling is very,
very, hard, and that there may be no one solution that is suitable for all
(or even most) applications.

3) I am having a really hard time figuring out why folks think this needs
to be built into the language -- having a nice compact and clear literal
for  numbers-with-units is great, but really only matters for UIs,
interactive use, things like Jupyter Notebooks, and maybe quick one-off
scripts. And all those can be handled with some sort of pre-processor --
either in the application, or using the existing import hooks or codec
system.

4) I can see the appeal of adding some sort of syntax or something to the
language, and then letting third-party libraries actually implement it. But
I'm  wary of this -- it reminds me of adding annotations to Python without
specifying how they should be used -- and now we've discovered that it
really is important to have a standard type system, and in fact, are moving
towards breaking other uses of annotations. Let's not go down that path
again.

-CHB

-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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/JFJZ4UWEAMQXQCONFVESDZK3HA2JPNQQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

2022-04-07 Thread Stephen J. Turnbull

Brian McCall writes:

 > Stephen J Turnbull and Paul Moore have asked why the "need" for
 > something other than a library (or perhaps a better library). There
 > are a number of examples that show simple unit calculations and
 > it's easy to argue based on those that nothing further is needed.

Nobody is arguing that, though.  We ask *because* we believe you
perceive need (and we don't put it in quotes, for exactly the reason
you give -- we do not define "need" as "if I don't get it I will
literally die").  You don't need to prove your need to Python core.

You need to show two things.  (1) The particular solution proposed
solves problems that already available approaches don't (including
"too inconvenient to consistently use in practice" which might apply
to the library approach vs the user-defined literal approach).  (2)
There are enough people with this need to outweigh the slight costs to
all Python users of maintaining the facility, documenting it, and
learning it, and possibly preventing a more valuable use of the same
syntax.

 > In regulated environments, risk analysis and mitigation is very
 > much affected by whether a feature has native support

That you say this after citing Paul of all people gave me a chuckle,
as he's probably the most prominent advocate of a comprehensive
standard library on these lists.  If anybody will be sympathic to your
needs on these grounds, he will.  (I don't expect you to know that,
but it might be useful to know you have a potential ally.)

It's important to distinguish between several levels of "native
support" here.

0.  Adding units to all numeric objects.

I don't think level 0 is a very good idea.  I think it was Mac
Lane who pointed out that the solution to a problem expressed in
mathematics starts by giving a formal statement of the problem,
manipulates the form according to syntactic rules, and finally
interprets the final form as a semantic solution to the problem.
Similarly, as long as the expected units of the result, and the
units output by a Python program are the same, the numbers don't
need to have units.  I suspect that from the point of view of
astropy, attaching units to ndarray rather than atomic numeric
types is optimal for this reason, not a workaround.

1.  Syntax, aka language support (the original suggestion of
user-defined literals fits here because either the way numbers are
parsed or the way '_' is parsed would have to change).

It's very difficult to get *any* syntax change in.  In particular,
changing '_' from an identifier component to an operator for
combining numeric literals would invalidate *tons* of code
(including internationalization code that is the 0.454kg nearest
my heart).  I can't imagine that being possible.  There was a fair
amount of pushback to using it as the non-capturing marker in the
match statement.  Changing its interpretation only in a numeric
literal is probably possible, since as far as I know it's
currently an error to follow a sequence of digits with _ without
interposing an operator or whitespace.

NOTE: The big problem I see with this is that I don't see any
practical way to use syntax for non-numeric types like ndarray.
The problem is that in, say, economics we use a lot of m x 2
arrays where the two columns have different units (ie, a quantity
unit and a $/quantity unit).  The sensible way to express this
isn't some kind of appended syntax as with numbers, but rather a
sequence of units corresponding to the sequence of columns.

If I'm right about that, the only time the literal would be used
syntax is when using Python interactively as a calculator.  Any
time you read from a string or file, you have to interpose a
parsing step anyway, so it makes sense to handle the construction
of quantities there.

2.  Built-in, that is pre-loaded in the interpreter.  These are
implemented as library functionality in the builtins module.

I would definitely be against level 2.  It would pollute the
builtin namespace to the great detriment of all non-numeric
applications.

3.  Modules in the standard library.  Always available, but must be
explicitly imported to be used.

I think adding a module that provides units for the stdlib numeric
types is a very interesting idea.  I doubt I'd ever use it, and
I'm not sure that the requirements can be well-enough specified at
the moment to go to +1 on it.  (As the Zen says, "Although never
is often better than *right* now.)

For me, level 4 (available on PyPI) is good enough.  I can think of
cases where it would be useful for class demos to be able to
interrogate a computation for its use of units, but that's about it.
So I depend on descriptions of proponents' use cases to sort out the
question of level 1 vs. level 3.

 > > The Mars Climate Orbiter [...] navigation error arose because a
 > > NASA subcontr

[Python-ideas] Re: Native support for units [was: custom literals]

2022-04-07 Thread Paul Moore

On Thu, 7 Apr 2022 at 01:18, Brian McCall
 wrote:
>
>> Please can you explain this to me? I don't know what you mean by "get the 
>> final answer", nor do I know how astropy.units is relevant. Units seems to 
>> be a perfectly acceptable library without astropy, is that not the case?
>
> Am I mistaken, or is the units module no longer maintained? I could not find 
> any documentation for it. Which is also a con. I honestly thought that 
> "units" took on a new life as "astropy.units".

I honestly have no idea. I simply did `pip install units` and it
worked. If the units module is no longer maintained, then who would
write (and maintain) a module that worked with any core python syntax
to allow units to be added to quantities? (Note that any core feature
would simply allow something like 3_ft to be written to mean the
number 3, with some object associated with the name "ft" attached to
it - it would be up to a 3rd party module to actually implement the
units calculations). It doesn't look like the astropy people want to
maintain a generalised units library if they are solely working with
numpy arrays.

Also, you didn't explain what you meant by "get the final answer" -
I'm still not clear with what you want beyond doing the calculation as
you showed in your code.

> > As has been mentioned, if you don't like "units." then "from astropy import 
> > units as U" and use "U.ms" of "from astropy.units import ms" and use ms 
> > directly.
>
> As an fyi, lots of single-letter variables are commonly used to match 
> variables in physics and engineering equations. U and u are of particular 
> importance in my field.
>
> > Don't use "import *" then, just import the names you need.
>
> Still rules out a lot of commonly used variables. ¯\_(ツ)_/¯

If your community typically uses short and frequently clashing names,
relying on context and intuition to distinguish them, there's nothing
a library or language feature can do to help with that... As I said,
there have to be some compromises made.

Paul
___
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/PZ2RDAO4MGPL46BR6C36BKU4IQUP6WJO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

2022-04-06 Thread Ken Kundert

Previously you were adamant that it is important that the units be propagated
into the final result. In my experience this rarely works out as one expects
because the units come out in an overly complicated, confusing form or
unexpected form. For example, you gave the units for Planck's constant as
m²kg/s which to me was confusing and unexpected. It took me a while to confirm
that was equivalent to J-s, which is the more traditional way of specifying its
units.

To show the value of what you are proposing, you should give the units of the
final result. The fact that they are missing significantly weakens your
example. Given your previous comments about the importance of propagating the
units, it is a little weird that in your one example you don't bother to show
it.

It is unclear what these examples are meant to show. Is the point to compute
the final units of n? If so, why did you not show them. If not, why were the
units specified at all? Are they primarily there for documentation purposes?
If
so, can't you just put them in comments. If the units need to be in the code
because they are employed somehow, you should show that.

I am still not understanding your justification for why you want to add units
to
Python. This application seems like a one-time hand calculation rather than
a programming problem. Perhaps a better approach would simply be to build
a units aware scientific calculator application. That was you could design the
best way to include units without any constrains from the Python calculator.

-Ken
___
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/ZHGAQOPUEC2MFYQSAJK6UZXYQN54TP5M/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

2022-04-06 Thread Chris Angelico

On Thu, 7 Apr 2022 at 10:19, Brian McCall
 wrote:
>
> > Agreed, this is just using Python as a glorified calculator. I understand 
> > that this is just an example, but I *am* curious, is the bulk of what you 
> > do simply calculations like this, or do your more complicated examples tend 
> > to be more like actual programs?
>
> I have never shipped code that would depend on these features. Code like 
> this, including this exact formula, might sit in a script and be used to 
> calculate normalization factors and feed into a noise model. That script 
> might look at one complete concept that I want to test out in theoretical 
> sense. In other cases, I'll make one or more of those quantities out to be 
> variables that I pass in via command line or config file. This allows me to 
> explore a system design space.
>

You have a VERY restricted definition of "shipped", then. If that code
did some calculation and that calculation was used, then that's
production code.

ChrisA
___
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/KJ3KJFIWGWMF7XUIG7K672SRUXLBUAMY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

> Agreed, this is just using Python as a glorified calculator. I understand 
> that this is just an example, but I *am* curious, is the bulk of what you do 
> simply calculations like this, or do your more complicated examples tend to 
> be more like actual programs?

I have never shipped code that would depend on these features. Code like this, 
including this exact formula, might sit in a script and be used to calculate 
normalization factors and feed into a noise model. That script might look at 
one complete concept that I want to test out in theoretical sense. In other 
cases, I'll make one or more of those quantities out to be variables that I 
pass in via command line or config file. This allows me to explore a system 
design space.

I used to ship code when I worked in telecom ~15 years ago, and that was mostly 
C++. Units were not a concern. I shipped C++ and Python code 2-5 years ago at 
another company (startup) which did not require units, but I also did my 
feasibility assessments with stuff like this that did depend on units.

> Given that the error was in the magnitude of one of the values, "magnitudes 
> are easily verifiable" doesn't really seem that correct...

... ah, I mean the mantissa, not the magnitude

> Please can you explain this to me? I don't know what you mean by "get the 
> final answer", nor do I know how astropy.units is relevant. Units seems to be 
> a perfectly acceptable library without astropy, is that not the case?

Am I mistaken, or is the units module no longer maintained? I could not find 
any documentation for it. Which is also a con. I honestly thought that "units" 
took on a new life as "astropy.units".

> As has been mentioned, if you don't like "units." then "from astropy import 
> units as U" and use "U.ms" of "from astropy.units import ms" and use ms 
> directly.

As an fyi, lots of single-letter variables are commonly used to match variables 
in physics and engineering equations. U and u are of particular importance in 
my field.

> Don't use "import *" then, just import the names you need.

Still rules out a lot of commonly used variables. ¯\_(ツ)_/¯

> Maybe that suggests that there's room for a unified library that takes the 
> best ideas from all of the existing ones, and pulls them together into 
> something that subject experts like yourself *would* be happy with (within 
> the constraints of the existing language)

Just to point out, I don't make this suggestion just for my benefit. I can 
handle all of the syntax limitations that I pointed out. I am in a somewhat 
unique position of having a BS in computer engineering, but I have worked for 
10+ years now in the optics industry, along with physicists, electrical 
engineers, and mechanical engineers. I was taught in school all about OOP, data 
structures, all that stuff. But most of the people I know today who write code 
do not have any formal training in this area. There are varying ranges of 
comfort with things like logical indexing, dot-notation (which you and I take 
for granted) and functions as objects that can be returned by other functions. 
I have seen code that looks like spaghetti served in a bowl that was shattered 
and put back together with duct tape. And some of it is related to units. If I 
make suggestions like what you have made, the response I tend to get is "my 
code works". Which would be fine with me if I never had to use their code.

Others who feel strongly about units, or dual threat CS/ECE types who have to 
work with self-taught programmers with physics or chemistry backgrounds may 
have other stories.
___
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/5VA3ESO4GVMCP6SCH76M2IUNILAVBPXF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

Mike and Andre, thanks for the links!

I was indeed planning to take a crack at implementing some ideas. First, for my 
part, I need to get approval from the people who own my intellectual property 
;-)

I also figured it would take me a while to sift through the Python code, which 
I have never done before. But if there is a shortcut I'll gladly take it.
___
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/E7KPSZZLCTJZV2HRRQBQJW54PBCKFJJY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

2022-04-06 Thread André Roberge

On Wed, Apr 6, 2022 at 7:05 PM Mike Miller 
wrote:

>
> On 2022-04-06 12:36, Paul Moore wrote:
>
> > And if new syntax is a clear win even with such a library,
> > then designing a language feature that enables better syntax for that
> > library would still be possible (and there would be a clear use case
> > for it, making the arguments easier to make).
>
>
> If folks are really hung up on the syntax limits, there is shortcut to
> prototype
> new syntax using the codecs module to edit code on the fly.  It's a cheat,
> but
> probably less work than writing a transpiler/dsl.
>
> Don't remember who invented the technique, but the last project I tried
> was to
> support f-strings under Python of pre-3.6 vintage, called future-fstrings:
>
>  https://github.com/asottile-archive/future-fstrings
>
>
There is also my ideas module https://aroberge.github.io/ideas/docs/html/
which I created to facilitate this type of exploration.
In fact, I made a note just two days ago about doing this myself
https://github.com/aroberge/ideas/issues/16

André



> Should be enough there to show how it's done.
>
> Why not try this technique, combine with one of the libraries, and start
> writing
> some code?  If it works well enough and enough folks are interested, the
> proposal would all the evidence it needs, imho.
>
> -Mike
>
> ___
> 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/MKZW5UORORGDSP7EVEDM2HCYOET4RY4J/
> 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/E7PATYVPAYOGLS76JMDRC672YK3EZ5ZM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

2022-04-06 Thread Mike Miller




On 2022-04-06 12:36, Paul Moore wrote:


And if new syntax is a clear win even with such a library,
then designing a language feature that enables better syntax for that
library would still be possible (and there would be a clear use case
for it, making the arguments easier to make).



If folks are really hung up on the syntax limits, there is shortcut to prototype 
new syntax using the codecs module to edit code on the fly.  It's a cheat, but 
probably less work than writing a transpiler/dsl.


Don't remember who invented the technique, but the last project I tried was to 
support f-strings under Python of pre-3.6 vintage, called future-fstrings:


https://github.com/asottile-archive/future-fstrings

Should be enough there to show how it's done.

Why not try this technique, combine with one of the libraries, and start writing 
some code?  If it works well enough and enough folks are interested, the 
proposal would all the evidence it needs, imho.


-Mike

___
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/MKZW5UORORGDSP7EVEDM2HCYOET4RY4J/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

2022-04-06 Thread Paul Moore

On Wed, 6 Apr 2022 at 16:51, Brian McCall
 wrote:
> Before I get to this example, though, there is more to arguments for the 
> "need" than just counter-examples. I keep using quotes because nothing is 
> really a need for anything.

Yes, it's not about "need" in an absolute sense, but more about
whether the gains justify the costs. In this case, the costs are
non-trivial, because there's very little prior art (at least that I
know of) in other programming languages in this area. So there's a
learning curve, making Python a bit less approachable for the average
programmer, which offsets the benefits to people who gain from this
sort of functionality. And that's on top of the usual costs of any
syntax change/new language feature.

> Alright, now let's look at an example. Again, it's not my best, let's go with 
> it.

Thanks for this, it helps a lot to have something concrete.

> Symbol definitions:
> h - Planck's constant
> c - speed of light
> Ee - irradiance
> R - reflectance
> Q - quantum efficiency
> F - f-number
> λ - wavelength
> a - width of a pixel
> t - exposure time
> ȳ - output of luminosity function integral
>
> From here, if the triple tick marks do not render this example in monospace 
> for you, then I recommend copy/pasting into something that does.
>
> ```
> echo no units
>
> python -c "
> h  = 6.62607015e-34
> c  = 299792458
> Ee = 200
> R  = 0.25
> Q  = 0.63
> F  = 2.4
> λ  = 550e-9
> a  = 3.45e-6
> t  = 30e-3
> ȳ  = 683
> n  = (Ee * R * Q * λ * t * a**2) / (2 * h * c * ȳ * F**2)

Someone's already asked, so I know that the issue was with the value
given to one of the constants, rather than with the formula. And I
know all of this is intended to be read by specialists, not by the
likes of me, but I wonder whether some comments might have helped
here, as well?

t  = 30e-3 # exposure time (seconds)

There's a subtle difference between "scripting" and "programming", and
as a programmer, I'd almost certainly add comments like this. But if I
was writing a script, I wouldn't. However, I'd generally not trust the
output of a script as much as I would that of a program. (Jupyter
notebooks fall somewhere in between, for what it's worth...)

> # n  = (200 * 0.25 * 0.63 * 550e-9 * 30e-3 * (3.45e-6)**2) / (2 * h*c * 683 * 
> 2.4**2)
> print(n)
> "
>
> # Pros - compact, the code representing the equation is easily verifiable, 
> and the magnitudes are also easily verifiable

Given that the error was in the magnitude of one of the values,
"magnitudes are easily verifiable" doesn't really seem that correct...

> # Cons - no units

Agreed, this is just using Python as a glorified calculator. I
understand that this is just an example, but I *am* curious, is the
bulk of what you do simply calculations like this, or do your more
complicated examples tend to be more like actual programs?

>
> echo What literals would look like
> python -c "
> # h  = 6.62607015e-34m2kg / 1s
> # c  = 299792458m / 1s
> # Ee = 200lx
> # R  = 0.25
> # Q  = 0.63
> # F  = 2.4
> # λ  = 550e-9nm
> # a  = 0.00345mm
> # t  = 30ms
> # ȳ  = 683lm / 1W
> # n  = (Ee * R * Q * λ * t * a**2) / (2 * h * c * ȳ * F**2)
> # n  = (200lx * 0.25 * 0.63 * 500nm * 30ms * (3450nm)**2) / (2 * h*c * 
> 683lm/1W * 2.4**2)
> "
> # Pros - Still compact. Dead simple. Planck's constant looks a little weird, 
> but this is usually imported from a library anyway
> # Cons - requires a syntax change; inline computations like the last line are 
> not IMO quite as readable as the next example

What would the output of "print(n)" be here? Presumably you'd be
expecting some sort of calculation on the units, so you didn't just
get something like

3958.0636423739215lxnm3msWs2/m2kglm

Or is that sufficient for you (I note that it's the same as units
provides, below)? Excuse me if I got the scale of the constant wrong,
you changed the units between the no-units example and this one (t,
for example was seconds and is now ms).

> echo 'What bracket syntax might look like'
> python -c "
> # h  = 6.62607015e-34 [m**2*kg/s]
> # c  = 299792458  [m/s]
> # Ee = 200[lx]
> # R  = 0.25
> # Q  = 0.63
> # F  = 2.4
> # λ  = 550e-9 [nm]
> # a  = 0.00345[mm]
> # t  = 30 [ms]
> # ȳ  = 683[lm/W]
> # n  = (Ee * R * Q * λ * t * a**2) / (2 * h * c * ȳ * F**2)
> # n  = (200[lx] * 0.25 * 0.63 * 500[nm] * 30[ms] * (0.00345[mm])**2) / (2 * 
> h*c * 683[lm/W] * 2.4**2)
> "
>
> # Pros - Still compact, dead simple, and IMO the best way to look at this code
> # Cons - requires a syntax change and a new kind of namespace in addition to 
> global, nonlocal, and enclosure

This is basically just a different bikeshed colour for the previous
example, I think. Is that right?

> echo units
> python -c "
> from units import unit
> h  = unit('m**2*kg/s')(6.62607015e-34)
> c  = unit('m/s')  (299792458)
> Ee = unit('lx')   (200)
> R  =   0.25
> Q  =   0.63
> F  =   2.4
> λ  =

[Python-ideas] Re: Native support for units [was: custom literals]

Oops, my examples have some other problems:

> # λ  = 550e-9nm

should be 

> # λ  = 550nm

and 

> # λ  = 550e-9 [nm]

should be 

> # λ  = 550 [nm]
___
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/TGBS7MGW2KTXHEXLORXIRLHVNBRTVZQC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

> Thank you for all the examples, that should help a lot.  Out of curiosity, 
> those are the corrected versions of the code? Where was the mistake in the 
> original?

Happy to help! The original was unitless altogether, so that was the first 
problem. The particular error was λ. I typically work in Zemax, where the base 
unit of length is mm (or inch, if you change default settings). So my λ was 
550e-6 instead of 550e-9. Funny thing is, my ȳ was a function that expects λ to 
have units of nm, and I did correct that. An exception told me that 550e-6 was 
out of bounds. But I did not think to check other dimensional mismatches. We 
built the prototype, saw the signal on the sensor that we expected to, but it 
was ~1000 times (~10 stops - another unit!) dimmer than expected. So basically 
useless.
___
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/ED3THDXPIQSSZXLEMIHX5ZYTIZ77VFPZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

2022-04-06 Thread Ethan Furman


On 4/6/22 08:50, Brian McCall wrote:

> Alright, now let's look at an example. Again, it's not my best, let's go with 
it. This is just
> a calculation of the expected number of photons to reach a pixel through a 
camera of a given
> f-number (F). I mentioned this has bitten me before. All that means is that 
based on a set of
> simulations, we though something was possible, spent a few weeks building a 
prototype, got
> results that made no sense, and then realized that there was a unit error in 
the original
> feasibility analysis. That one was on me, and since I am a capable 
programmer, I ought to have
> been using a units package.

Thank you for all the examples, that should help a lot.  Out of curiosity, those are the corrected versions of the code? 
 Where was the mistake in the original?


--
~Ethan~
___
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/2HLNUKMBV6SZHCKKI2YRID7EP76KETYC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

Wow, this thread has grown quite a bit in the last two days. And there's some 
really good points raised alongside the light trolling here and there. While 
the discussion around implementation is important and very interesting, I think 
the question around motivation is critical. Since I see some new discussion 
around that topic, I'll start there.

Stephen J Turnbull and Paul Moore have asked why the "need" for something other 
than a library (or perhaps a better library). There are a number of examples 
that show simple unit calculations and it's easy to argue based on those that 
nothing further is needed. I think more complicated counter-examples could help 
push back against this, but complicated counter-examples might be protected IP, 
or they just might take a lot of work to talk all the way through. Still, I'd 
love to see a whole thread dedicated to this, because I really am curious to 
see examples that aren't my own. But I'll start with one example here. It might 
not be the most compelling, but I'll throw it out there because it's not 
protected and it has bitten me once.

Before I get to this example, though, there is more to arguments for the "need" 
than just counter-examples. I keep using quotes because nothing is really a 
need for anything. There isn't a need for built-in support for lists, sets, or 
even Python, but I sure am glad we have it. Let me say desirability instead. 
Desirability doesn't just come from things that programmers and CS majors care 
about, like readability, concise syntax, and self-explanatory code. 
Desirability for this feature also comes from an operations standpoint. I have 
made personnel decisions based on whether a candidate has ever used 
dot-notation in their code before, or if they have only ever used Fotran/Matlab 
style coding. In regulated environments, risk analysis and mitigation is very 
much affected by whether a feature has native support or if it comes from a 
third party library (see 
https://en.wikipedia.org/wiki/Software_of_unknown_pedigree). That same risk 
analysis is also heavily impacted by looking at what the worst case scenario 
might be. And if you want an example of that, look no further than the 
pre-amble of https://pypi.org/project/units/ (which I believe led to 
astropy.units).

> The Mars Climate Orbiter was intended to enter orbit at an altitude of 
> 140-150 km (460,000-500,000 ft.) above Mars. However, a navigation error 
> caused the spacecraft to reach as low as 57 km (190,000 ft.). The spacecraft 
> was destroyed by atmospheric stresses and friction at this low altitude. The 
> navigation error arose because a NASA subcontractor (Lockheed Martin) used 
> Imperial units (pound-seconds) instead of the metric system.

I think that a thread of examples along these lines would also go a long way 
informing both high level and nuanced decisions about what the role of units 
should be in programming languages and libraries.

One last pontification before I get to my example relating to units. We already 
have examples of features that have both a native implementation and library 
extensions. int and float are primitives in Python. They are more than enough 
for most users, but limiting for quite a few other users. So modules like 
fractions and decimal provide extended support, and libraries like numpy 
provide even more data types for task-specific needs.

Alright, now let's look at an example. Again, it's not my best, let's go with 
it. This is just a calculation of the expected number of photons to reach a 
pixel through a camera of a given f-number (F). I mentioned this has bitten me 
before. All that means is that based on a set of simulations, we though 
something was possible, spent a few weeks building a prototype, got results 
that made no sense, and then realized that there was a unit error in the 
original feasibility analysis. That one was on me, and since I am a capable 
programmer, I ought to have been using a units package.

Symbol definitions:
h - Planck's constant
c - speed of light
Ee - irradiance
R - reflectance
Q - quantum efficiency
F - f-number
λ - wavelength
a - width of a pixel
t - exposure time
ȳ - output of luminosity function integral

From here, if the triple tick marks do not render this example in monospace for 
you, then I recommend copy/pasting into something that does.

```
echo no units

python -c "
h  = 6.62607015e-34
c  = 299792458
Ee = 200
R  = 0.25
Q  = 0.63
F  = 2.4
λ  = 550e-9
a  = 3.45e-6
t  = 30e-3
ȳ  = 683
n  = (Ee * R * Q * λ * t * a**2) / (2 * h * c * ȳ * F**2)
# n  = (200 * 0.25 * 0.63 * 550e-9 * 30e-3 * (3.45e-6)**2) / (2 * h*c * 683 * 
2.4**2)
print(n)
"

# Pros - compact, the code representing the equation is easily verifiable, and 
the magnitudes are also easily verifiable
# Cons - no units

echo What literals would look like
python -c "
# h  = 6.62607015e-34m2kg / 1s
# c  = 299792458m / 1s
# Ee = 200lx
# R  = 0.25
# Q  = 0.63
# F  = 2.4
# λ  = 550e-9nm
# a  = 0.00345mm
# t  = 30ms

[Python-ideas] Re: Native support for units [was: custom literals]

2022-04-06 Thread Steven D'Aprano

On Wed, Apr 06, 2022 at 08:34:35PM +1200, Greg Ewing wrote:
> On 6/04/22 10:41 am, Chris Angelico wrote:
> >I don't think anyone would ever say that a
> >parsec (several light years) should be considered equivalent to a
> >second of latitude (a handful of meters) just because they both have
> >an angular size of one second!
> 
> Although if you're Han Solo then it's a unit of time. :-)

If you've watched the "Solo" movie, then you discover that no, it is 
actually a unit of distance. He successfully took an impossibly 
dangerous short-cut that reduced the distance needed to fly.

But now we're really off topic :-)


-- 
Steve
___
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/2DJ6Z36FGMBXC5NBIHD77LU2TYHOCB2I/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

2022-04-06 Thread Greg Ewing


On 6/04/22 10:41 am, Chris Angelico wrote:

I don't think anyone would ever say that a
parsec (several light years) should be considered equivalent to a
second of latitude (a handful of meters) just because they both have
an angular size of one second!


Although if you're Han Solo then it's a unit of time. :-)

--
Greg
___
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/ISL3AB2A3PNO4DUY3XYYZO5HIVL757TJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

2022-04-05 Thread Chris Angelico

On Wed, 6 Apr 2022 at 13:33, Christopher Barker  wrote:
> (or may favorite: API Gravity [2] as a density)
>

Wow, I have to remember this. I've worked with a lot of APIs in my
time, and some of them definitely are more dense than others.

ChrisA
___
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/XQD64HVXPBVSZ7ZX32BHWREHPRXTXZPU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

2022-04-05 Thread Christopher Barker

> Length is measured in a variety of units, but the degree ain't one of 'em.

Mostly I was just being silly.

But the relevant part is that people do a lot of useful work using values
that are not in "proper" units, and don't follow the rules as they should.
>From things as simple as using kg as weight or lbs as mass, to really
oddball stuff like using degrees of latitude as a distance[1].

(or may favorite: API Gravity [2] as a density)

Which doesn't mean that proper units are very useful, but a lot of
flexibility is needed for many practical uses.

-CHB

[1] when you are looking at a nautical chart, which are most often in the
Mercator Projection, the scale changes with latitude. So it's very handy to
use the latitude scale on the map to measure distances -- 1 minute latitude
is one nautical mile -- granted,  you usually do the conversion directly in
your head, or setting it on a dividers,  but you ARE measuring distance in
latitude minutes.

[2] https://en.wikipedia.org/wiki/API_gravity


-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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/675IZUQEWATOU5YP2PXU647YHHVH3ACC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

2022-04-05 Thread Chris Angelico

On Wed, 6 Apr 2022 at 08:35, Greg Ewing  wrote:
>
> On 6/04/22 3:47 am, Christopher Barker wrote:
> > And they are -- degrees latitude and degrees longitude are very
> > different units :-)
>
> I'm thinking more of a local Cartesian coordinate system rather
> than lat-long.
>
> Think about this: You're driving north in a car that's 3m long.
> You turn east. Do you now have to measure the length of your
> car in different units?
>
> And what about the circumference of a circle? It's going in
> uncountably many directions at different points. Do we need
> a similarly uncountable number of units to measure it?
>
> Or do we just say "all distances are in metres" and be done
> with it?
>

I would say that degrees latitude and degrees longitude are both the
same type of unit: a unit if *angle*. They do not correspond to the
same number of meters, but they're not units of distance. There are
multiple ways in which you can measure distance by angle, ranging all
the way up to the "second of parallax", which is effectively
calculating the height of an isosceles triangle based on the interior
angle and a base of 1AU. I don't think anyone would ever say that a
parsec (several light years) should be considered equivalent to a
second of latitude (a handful of meters) just because they both have
an angular size of one second!

Length is measured in a variety of units, but the degree ain't one of 'em.

ChrisA
___
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/INHQY5JNQJZ7WBYTOM7GASRZRUK3JV4J/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]


On 6/04/22 3:47 am, Christopher Barker wrote:
And they are -- degrees latitude and degrees longitude are very 
different units :-)


I'm thinking more of a local Cartesian coordinate system rather
than lat-long.

Think about this: You're driving north in a car that's 3m long.
You turn east. Do you now have to measure the length of your
car in different units?

And what about the circumference of a circle? It's going in
uncountably many directions at different points. Do we need
a similarly uncountable number of units to measure it?

Or do we just say "all distances are in metres" and be done
with it?

--
Greg
___
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/HIS2LE7JBCTJDHC3WCDOXI6BJJRLZDS7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]


On 6/04/22 3:30 am, Stephen J. Turnbull wrote:

suppose I
wanted to know how many cm there are in an in:

 cm_per_in = 1 * in / 1 * cm

Of course that's a silly mistake, but the (sole, IMO) advantage of the
original proposal is that you can't make that silly mistake.


Well, you can make the same silly mistake any time you mix
multiplication and division in an expression, so we should
really be lobbying to fix the borked precedence of * and /
in general. :-)

--
Greg

___
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/LE3I25TXXXE7PFXU2IFT63D4GHOFEJ3W/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

2022-04-05 Thread Christopher Barker

On Tue, Apr 5, 2022 at 11:57 AM Steven D'Aprano  wrote:

> > And they are -- degrees latitude and degrees longitude are very different
> > units :-)
>
> Greg said *distances*, not coordinates or angles.

People DO sometimes use lat/lon as distances— particularly latitude, where
1 minute is a nautical mile.

But anyway, a humorous one-off.

But it makes the point that there is no one way to handle units that works
for everyone.

An astonishing  amount of “real work” is done with “squishy” units.

-CHB
-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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/NYS347I67NGPUNMW6DPCQMHY3ZMNZRJ4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

On Wed, Apr 06, 2022 at 12:28:49AM +1200, Greg Ewing wrote:
> On 5/04/22 6:05 am, Ethan Furman wrote:
> >It seems to me that these "unitless' units actually have units, even if 
> >they *appear* to cancel each other out.
> 
> I think it's more that units alone don't capture everything
> that's important about the physical situation.

+1

This, a thousand times this!

Neither dimensional analysis nor units capture all the semantics of 
calculations of real quantities. Both are powerful tools, but they do 
not capture everything interesting in the universe.

For example, I'm going to try to draw some ASCII art of a rectangle with 
a diagonal line:

+---+
|  /|
| / |
|/  |
+---+

We can capture the shape of the rectangle by giving the aspect ratio, 
let's say 1:2 using the convention width:height, which is another way of 
writing the fraction 1/2 = 0.5. Or we can give the gradient of the 
diagonal (rise over run), which is height/width, or 2. Or the angle made 
by the diagonal to the base, which would be arctan(2) in radians. Or the 
angle made by the diagonal to the vertical. In degrees.

All these things describe the same rectangle, but they are numerically 
distinct, and tracking units "cm/cm" isn't going to tell you whether the 
number you have is an aspect ratio, gradient, angle or something else.

-- 
Steve
___
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/SB5E6VOD65C7HTKBQONKR3FQY52GLORB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

On Wed, Apr 06, 2022 at 12:30:47AM +0900, Stephen J. Turnbull wrote:
> Greg Ewing writes:
> 
>  > With my "no new syntax" suggestion there would be no question here --
>  > the only way to write it would be
>  > 
>  >  height = 5 * ft + 4.5 * in
> 
> I'm very sympathetic to the "no new syntax" suggestion, but suppose I
> wanted to know how many cm there are in an in:
> 
> cm_per_in = 1 * in / 1 * cm

inch.definition()

inch.convert(cm)


> Of course that's a silly mistake, but the (sole, IMO) advantage of the
> original proposal is that you can't make that silly mistake.

Don't worry, I'm sure it will allow its own distinct silly mistakes :-)

-- 
Steve
___
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/PWL5IBNZXFPB77DKQIWULEMZFDYMGMJ3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

On Tue, Apr 05, 2022 at 08:47:52AM -0700, Christopher Barker wrote:
> On Tue, Apr 5, 2022 at 5:13 AM Greg Ewing 
> wrote:
> 
> > single 4-dimensional continuum, this makes about as much
> > sense as insisting that north-south and east-west distances
> > are measured in different units.
> >
> 
> And they are -- degrees latitude and degrees longitude are very different
> units :-)

Greg said *distances*, not coordinates or angles.


-- 
Steve
___
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/QOKZXIRCBPV6ZVURYTLMQWYOQA7IH27Q/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

2022-04-05 Thread Stephen J. Turnbull

I'll start with some opinionated stuff, but possibly helpful attempts
to understand the requirements follows from about the middle of the post.

Ricky Teachey writes:

 > [Brian McCall] had it right in his first post that spurred this
 > discussion. I'll quote bits of it:
 > 
 > > ...I have spent a fair amount of my own time, and I have seen so
 > > many others' time wasted because command line or input fields do
 > > not include units, or the inputs field units are accidentally
 > > handled with different units, or units are not used at all.

This has zip-o to do with having quantity (number-with-unit) objects
as part of the language.  It's all about parsing natural language, or
providing the user with sufficient hints about the expected input.
Ie, it's UI/UX.

 > > I get the sentiment that Python, or programming languages in
 > > general, are not meant to deal with units.

I have no idea where this came from.  The plethora of units libraries
both on PyPI and in various folks' personal toolkits gives it the lie.

 > > Anyone who has taken science or engineering classes in college
 > > knows what happens when you turn in homework with missing units
 > > in your answers - zero credit. Anyone who has worked out
 > > complicated calculations by hand, or with the help of packages
 > > like "units"

Oops, we just let the cat out of the bag.  How hard it is to use the
units library?  What is hard about it?  Sure, it's an annoying amount
of setup, but do it once for your field and copy-paste it (or import
from your toolkit) and the only differences between using units and
having user-defined literals is typing * instead of _, and the
possible embarrassment of typing "cm_per_in = 1 * in / 1 * cm" and
getting units meters**2 (but you immediately know you did something
wrong).

 > > ...The lack of native language support for SI units is a problem for an
 > > entire segment of programmers.

This is the X Y problem.  We'll all concede that units support is nice
to have, and if you want to consider the lack of units support to be
existential, fine by us.  But you're going to have to do a tun of work
to show that it needs to be *native* support (ie, in the language),
that it requires new syntax.

 > > They need to take another step forward to say that EVERY number
 > > has a unit, including "unitless".

I disagree, but it's not open and shut -- I at least am open to
evidence of this claim.  Suppose we do need that.  Even so, it's not
clear to me that this shouldn't be handled the way we handle typing,
that is, by treating a quantity of 1 kg as being a different type from
1 m, and inferring types.  (Example below.)

 > The old engineering disciplines- mine (civil engineering), structural,
 > electrical, etc- are the next frontier in the "software eats the world"
 > revolution, and they desperately need a language with native units
 > support

Again, nobody has provided any foundation for the claim that they
*need* *native* support, except that C++ jumped off that bridge so
Python should too.

What follows are questions that need to be answered to implement the
feature well.  They shouldn't be taken as "YAGNI".

 >  Python SHOULD be that language we do this with. It is awesome in every
 > other way. But if it isn't DEAD SIMPLE to use units in python, it won't
 > happen.

What does "dead simple" mean?  Do you expect people to be using Python
as a calculator so that the majority of their typing involves literal
quantities (ie, numbers with explicit units)?  Or is the more common
use case writing

def foo(v: Volume, d: Density) -> Mass:
return v * d

and have an I/O functionality that can convert strings or csv files to
Volume and Density objects, and Mass objects have a nice __str___.
Then in the rare case where you need to specify a quantity (eg,
demoing at the interpreter prompt) you have to write

foo(2.34 * m * m * m, 0.06 * kg / (m * m * m))

Is that too "difficult"?  If it is, how about

m3 = m * m * m
foo(2.34 * m3, 0.06 * kg / m3)

By the way, this is possible right now, mypy will check it for you.
(Of course somebody must define the classes Volume, Density, and Mass,
and write the I/O and __str__ functions.  But only the I/O is at all
hard.)

 > a big big part is that using units is too hard.

I have no idea what you mean by "using units".  Abstractly, yes, but
what programs are you going to write?  Are they going to be littered
with literal quantities, as Brian's proposal for custom literals
suggests?  Or is it just important that when you operate on some
quantities, their units are checked for compatibility, and results can
be easily checked for appropriate units if the programmer wants to?
Do people often confuse moments, energy, and torque in their
computations so that we need to distinguish them in our unit
libraries, or does that kind of thing happen so rarely that cancelling
SI units and prefixes wherever possible would give good enough
results?  (Note that the "units as types" ap

[Python-ideas] Re: Native support for units [was: custom literals]

2022-04-05 Thread Christopher Barker

On Tue, Apr 5, 2022 at 5:13 AM Greg Ewing 
wrote:

> single 4-dimensional continuum, this makes about as much
> sense as insisting that north-south and east-west distances
> are measured in different units.
>

And they are -- degrees latitude and degrees longitude are very different
units :-)

-CHB

-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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/CD4F6HV7ADXBCPYVH3QGMC7HEFETZZMR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

2022-04-05 Thread Paul Moore

On Tue, 5 Apr 2022 at 14:25, Ricky Teachey  wrote:

> units are at THE CORE of that need.
>
> i think python should be the language we reach for. i have made python work 
> for me as a civil engineer and been extremely successful with it for all the 
> usual reasons: ease of learning and community backing that learning, the open 
> source resources (libraries and applications), the momentum of the language, 
> its ability to be a swiss army knife (need to transition to web? automate the 
> boring thing? sure, easy).

I've been reading this discussion with gradually increasing levels of
bemusement. I genuinely had no idea that handling units was so
complex. But one thing I did note was that there are various libraries
(at least one, I think I saw more than one mentioned) that do units
handling. Why are those libraries insufficient? You said that "The
motivation is much more than just being able to not have the *
symbol", but no-one seems to have explained why a library isn't
enough. After all, scientists manage with numpy being a library and
not a core feature. Data scientists manage with tensorflow being a
library. What's not sufficient for unit support to be a library? (And
remember, the numeric users successfully got the @ operator added to
the language by arguing from the basis of it being a sufficient
enhancement to improve the experience of using numpy, after years of
having requests for general "matrix operations" rejected - language
changes are *more likely* based on a thriving community of library
users, so starting with a library is a positive way of arguing for
core changes).

Paul
___
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/RSB6AAPNDTWLP7RKVJYTTYY6FPTP5SVV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

2022-04-05 Thread Stephen J. Turnbull

Greg Ewing writes:

 > With my "no new syntax" suggestion there would be no question here --
 > the only way to write it would be
 > 
 >  height = 5 * ft + 4.5 * in

I'm very sympathetic to the "no new syntax" suggestion, but suppose I
wanted to know how many cm there are in an in:

cm_per_in = 1 * in / 1 * cm

Of course that's a silly mistake, but the (sole, IMO) advantage of the
original proposal is that you can't make that silly mistake.

___
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/UJPWU4KQCH3HCIVSFC7LUD7PSLC2PFWS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

2022-04-05 Thread Ricky Teachey

On Tue, Apr 5, 2022 at 7:43 AM Steven D'Aprano  wrote:

> On Mon, Apr 04, 2022 at 01:53:49PM +1000, Chris Angelico wrote:
>
> > And that's exactly why I think that the *concept* of units could be
> > added to the language, with some syntax and low-level semantics, but
> > the actual units themselves belong in libraries.
>
> +1 on that.
>
> I'm not even sure about the need for syntax beyond what we already have.
> Yes, it would be nice to write:
>
> speed = 15 ft 3 in / 3 sec
>
> but is it really so painful to use existing syntax?
>
> speed = (15*ft + 3*in) / (3*sec)
>
> I don't think so.
>
>
> --
> Steve
>

The motivation is much more than just being able to not have the * symbol
(though all things being equal it would be nice).

I think I've mostly disagreed with Brian McCall on just about every DETAIL
he has expressed regarding what "language level unit system support" ought
to look like, but he had it right in his first post that spurred this
discussion. I'll quote bits of it:

On Sun, Apr 3, 2022 at 2:56 PM Brian McCall 
wrote:

> ...I have spent a fair amount of my own time, and I have seen so many
> others' time wasted because command line or input fields do not include
> units, or the inputs field units are accidentally handled with different
> units, or units are not used at all.
>
> I get the sentiment that Python, or programming languages in general, are
> not meant to deal with units. From the perspective of a computer scientist,
> I can understand why this would be seen as a level of abstraction too high
> for programming languages and core libraries to aspire to. But from the
> perspective of a scientist or engineer, units are a CORE part of language.
> Anyone who has taken science or engineering classes in college knows what
> happens when you turn in homework with missing units in your answers - zero
> credit. Anyone who has worked out complicated calculations by hand, or with
> the help of packages like "units" knows the sinking feeling and the red
> flags raised when your answer comes out in the wrong units.
>
> There has also been a shift in the expectations of scientists and
> engineers regarding their programming capabilities. A generation ago, a
> good many of them would not be expected to use their computers for anything
> more than writing documents, crunching numbers in a spreadsheet, or using a
> fully integrated task-specific application for which their employer paid
> dearly. These assumptions were codified in workflows and job descriptions.
> Today, if your workflow, especially in R&D, has a gap that Microsoft Office
> or task-specific software doesn't solve for you, then you are pretty much
> expected to write your own code. Job postings for engineering roles (other
> than software engineering) regularly include programming in their required
> skills. Software design, on the other hand, is rarely a required or hired
> skill. And even though these scientists and engineers are required to know
> how to program, they are almost never *paid* to write code. Spending any
> more time than needed writing code, even if it is to fill a critical gap in
> a workflow, is seen as a negative. So software design best practices are
> non-existent. All of this leads to very poor practices around and improper
> handling of an absolutely essential part of scientific and engineering
> language - units.
>
> ...The lack of native language support for SI units is a problem for an
> entire segment of programmers. Programming languages took a big step
> forward in deciding that EVERYTHING is a pointer/reference, and EVERYTHING
> is an object. They need to take another step forward to say that EVERY
> number has a unit, including "unitless". Not having this language feature
> is becoming (or already is) a problem. The question is, is it Python's
> problem?


And I said:

The old engineering disciplines- mine (civil engineering), structural,
> electrical, etc- are the next frontier in the "software eats the world"
> revolution, and they desperately need a language with native units
> support
>
>  Python SHOULD be that language we do this with. It is awesome in every
> other way. But if it isn't DEAD SIMPLE to use units in python, it won't
> happen.
>

Steven: I am telling you that there is a HUGE NEED and DESIRE for what we
are talking about above. the need to automate design processes in the "i
need you to get me a set of calculations and drawings for this complicated
project to me, TODAY, mr engineer?" electrical, structural, chemical,
industrial/manufacturing, mechanical, and general civil (environmental,
water/wastewater, geotechnical, chemical, transportation) fields is
monstrous. it said above it is "the next frontier". but it won't be unless
these men and women get the tools they need. someone is going to fill the
need.

units are at THE CORE of that need.

i think python should be the language we reach for. i have made python work
for me as a civil engineer and been extremely successfu

[Python-ideas] Re: Native support for units [was: custom literals]


On 5/04/22 6:36 am, Chris Angelico wrote:

5 L/100km in SI units is 5e-3 m³ / 1e5m. That's 5e-8 m². Or if you
prefer, 50mm².

Fuel economy is a unit of area.


This misses the rather important point that it's not just
litres of empty space, it's litres *of fuel*. You really
need to consider "litres of fuel" to be an indivisible
unit that doesn't cancel with a distance.

Alternatively, measure the fuel by mass rather than volume.
Then your fuel consumption is in kg/100km, which is in
far less danger of being cancelled down.

Or you could measure the fuel in moles... but then since
moles are dimensionless, you get reciprocal distance...

Who would have thought units could be such fun?

--
Greg
___
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/DZ3AOKKJRGDT35WNHTHLZHOTIU6AM65I/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]


On 5/04/22 6:05 am, Ethan Furman wrote:
It seems to me that these "unitless' units actually have units, even if 
they *appear* to cancel each other out.


I think it's more that units alone don't capture everything
that's important about the physical situation.

Another example: the capacitance of a capacitor is the area of the 
plates divided by the distance between them and multiplied by a

constant. Unit-wise, an area divided by a length is just a length,
so the constant has units of farads per metre. But the metres don't
correspond to a length you can measure anywhere.

--
Greg
___
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/EZUJEOSZIDQ4AS7A7K6HI6674MCRZVWF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]


On 5/04/22 6:05 am, Chris Angelico wrote:

In any case: the
speed of light might be 1, but it's still 1 distance divided by 1
time.


If you truly embrace the idea of space and time forming a
single 4-dimensional continuum, this makes about as much
sense as insisting that north-south and east-west distances
are measured in different units.

--
Greg
___
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/WFYGRY4KL5CJU5XFLMVQCZNX33AGCNIF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

On Tue, Apr 05, 2022 at 04:05:36AM +1000, Chris Angelico wrote:

> Not sure what you mean by "geometrized", but that would be the same
> concept as referring to "natural units", wouldn't it? In any case: the
> speed of light might be 1, but it's still 1 distance divided by 1
> time.

No.

https://en.wikipedia.org/wiki/Geometrized_unit_system

Time has dimensions of length; so does mass; velocity is dimensionless; 
acceleration has dimension of inverse length; both pressure and density 
have dimensions of inverse area.


-- 
Steve
___
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/ADUQEPZKIJ3L5BKBUYCUGG5O5V35QNMU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

On Mon, Apr 04, 2022 at 07:42:37AM +0200, Luca Baldini wrote:

> I beg to disagree here, here---mass is measured in eV / c^2, and 
> momentum in eV / c. (Although, as Brian says, we're all guilty of taking 
> shortcuts in conversations.)

I beg to differ. *Real* physicists measure everything in terms of powers 
of length:

https://en.wikipedia.org/wiki/Geometrized_unit_system

*half a wink*



-- 
Steve
___
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/6QMZTVUL33LTWWE2HMUGCO2RLV25M4KT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

On Mon, Apr 04, 2022 at 04:47:12AM -, Brian McCall wrote:

> Libraries already exist, and they are not sufficient.

What are they missing?


-- 
Steve
___
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/LT6FS7X2H7ZDXFOMQVBDZG4N5CO5JRVA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

On Mon, Apr 04, 2022 at 01:53:49PM +1000, Chris Angelico wrote:

> And that's exactly why I think that the *concept* of units could be
> added to the language, with some syntax and low-level semantics, but
> the actual units themselves belong in libraries.

+1 on that.

I'm not even sure about the need for syntax beyond what we already have. 
Yes, it would be nice to write:

speed = 15 ft 3 in / 3 sec

but is it really so painful to use existing syntax?

speed = (15*ft + 3*in) / (3*sec)

I don't think so.


-- 
Steve
___
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/5U4CU5QXU5HI4UIWUCZXCXIOD45NH4KC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]


On 5/04/22 5:17 am, Steven D'Aprano wrote:

However, I suspect that having an array of unit objects rather than
low-level machine ints or floats will reduce the performance of numpy a
lot.


If numpy were to incorporate units, I would expect there to be
just one unit tag for the whole array.

--
Greg
___
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/G33JPTBRX3CKJLCVIAIE2U55OFQUUEYJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]


On 5/04/22 12:27 am, David Mertz, Ph.D. wrote:

On Mon, Apr 4, 2022, 2:17 AM Brian McCall
 > For instance, I don't think there would be much uproar if "teaspoons" 
were left out of any kind of implementation.


Apparently someone other than you does the cooking in you household!


Wouldn't recommend this, the National Union of Chefs, Cooks, Cuisiniers
and Other Professional Culinary Persons would be out on strike until 
teaspoons were included.


--
Greg
___
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/OW66NGT6ICEFUH7PVLGUYDMBGYMEJH2Q/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]


On 4/04/22 7:59 pm, Chris Angelico wrote:

How often do you ACTUALLY need them to be local to a module? When is
this ever a concern?


As long as there are competing *implementations* of units there will
be potential for conflicts, even if the actual units being represented
are the same.

--
Greg
___
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/6DZNCRWO5YBLDEZ4QMD3MZ47VONIUBZF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

On Tue, 5 Apr 2022 at 11:44, Steven D'Aprano  wrote:
>
> On Tue, Apr 05, 2022 at 04:36:24AM +1000, Chris Angelico wrote:
>
> > Some unit cancellations really do result in pure scalars. The ratio of
> > a circle's circumference to its diameter isn't a unit of m/m any more
> > than the ratio of a circle's area to that of a circumscribed square is
> > a unit of m²/m². They're both just numbers.
>
> Of course it is a ratio. You said it yourself: it is a ratio of
> circumference to diameter.
>
> That ratio is only numerically equal to π if the units you measure the
> cicumference and diameter are the same. Otherwise it has units
> "inches/cm" (or whatever units you used) and a completely different
> numerical value.
>
> > On the other hand, a
> > radian is a very real unit of distance/distance (based on its
> > definition of arc length), and it's a unit of angle.
>
> The SI system defines both radians and steradians as dimensionless
> derived units, previously known as "supplementary units".
>

You're missing the point: these are ALL dimensionless values, yet they
are incompatible. Regardless of the units used to measure the
circumference and diameter, they will *by definition* cancel out and
leave you with pi (case in point: using a pie as the unit
https://www.youtube.com/watch?v=ZNiRzZ66YN0 ). But a radian and a
steradian are not the same type of thing. Nor is an index of
refraction.They're all dimensionless. They're NOT all fungible.

The unit type "inches/cm" is meaningless, but the unit type
"length/length" is very meaningful. And that's where the problem comes
in.

Please, stop being all caught up on one small error that I propagated,
and look at the actual point? You're really good at this sort of
thing.

ChrisA
___
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/EGZY7HIHZB7AHNYT7XQEFHDGA4A2RWWK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

2022-04-04 Thread Greg Ewing


On 4/04/22 3:45 pm, David Mertz, Ph.D. wrote:

An electron volt is a unit of energy. Or of mass. Or of momentum.


Well, in relativity they're all really the same thing, or
at least interconvertible.

But there are more glaring examples of this. What do you get
when you multiply a number of newtons by a number of metres?
It could be either joules of energy or newton-metres of
torque, depending on what you're doing. You definitely
don't want to add those together!

I'm not sure how you teach a unit system to deal with things
like that. Somehow when you do the multiplication you have
to specify whether you're calculating energy or torque.

--
Greg

___
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/HJ3ODB625ZOWVY2NIDOQ2ZEGUA36Z3BI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

On Mon, Apr 4, 2022 at 7:45 PM Ethan Furman  wrote:

> On 4/4/22 13:31, David Mertz, Ph.D. wrote:
>
>  > You should probably change the thread subject to "All-and-only 7 SI
> units" if that's what you mean.
>
> While I'm sure SI would be very useful, I suspect that any system will
> have to be useful for a much broader audience to
> be accepted; given the vast amount of units, I suspect individual
> libraries will be needed for each area/discipline.
>

That's pretty much exactly my point.  Every time anyone points out
complications or difficulties, Brian falls back to "we only care about the
7 SI units, all other uses are illegitimate."  Since that is his position,
he should state that in the thread.

I think a LIBRARY (not syntax) that handles the real complication of units
is an excellent thing. A couple do exists, but I'm sure they could be
further improved.
___
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/ZNTUKEJBWDFWOLI47Q5BXD3FV7HVL3VR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

On Mon, Apr 04, 2022 at 11:05:54AM -0700, Ethan Furman wrote:
> On 4/4/22 08:54, Ken Kundert wrote:

> It seems to me that these "unitless' units actually have units, even if 
> they *appear* to cancel each other out.

The term is *dimensionless* units.

1 dozen and 1 mole of objects both are dimensionless numbers, but if I 
asked for a dozen eggs and you gave me 1 mol (6.02 x 10^23) instead, I 
wouldn't have room to store them in the fridge.


-- 
Steve
___
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/WDJNBA7O2DE7CARWR72NSMMHWS35OTTE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

On Mon, Apr 04, 2022 at 04:44:58PM -0700, Ethan Furman wrote:

> Beyond that, do we make Python smart enough to, for example, convert 
> `km*km` to `km^2`, or do we let libraries provide their own functions?  I'm 
> inclined to let libraries provide their own, as they could also implement 
> unit conversions as desired.

There already are libraries for units in Python:

https://pypi.org/project/units/

https://pypi.org/project/quantities/

https://pypi.org/project/Unum/

https://pypi.org/project/Pint/


It would be kind of nice if there was a little less wild conjecture 
about units and more consideration of the state of the art :-)

(This is not aimed specifically at you Ethan, just a general observation 
of the discussion in this thread.)


-- 
Steve
___
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/PBLOQTDPPEUCN5JDLAFH3IMFJ3WH2WXH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

2022-04-04 Thread Greg Ewing


On 4/04/22 2:42 pm, Ricky Teachey wrote:

height = 5ft + 4.5in

Surely we ought to be able to add these values. But what should the 
resulting tag be?


One answer might be that the tag only tracks what kind of quantity it
is -- length, mass, time, etc. Internally the number would be
represented in a standard unit for each quantity.

Whether to display it as feet or inches or a combination of both would
then be a matter of formatting. A default could be chosen based on the
magnitude of the number, and if you wanted something else you would have
to specify it, just as with any other formatting decision.


Should we be able to write it like this?

height = 5ft 4.5in


With my "no new syntax" suggestion there would be no question here --
the only way to write it would be

height = 5 * ft + 4.5 * in

--
Greg


___
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/EE6HH7WARD4YIZWGJC4EJN6PMMK3QPWU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

On Tue, Apr 05, 2022 at 04:36:24AM +1000, Chris Angelico wrote:

> Some unit cancellations really do result in pure scalars. The ratio of
> a circle's circumference to its diameter isn't a unit of m/m any more
> than the ratio of a circle's area to that of a circumscribed square is
> a unit of m²/m². They're both just numbers.

Of course it is a ratio. You said it yourself: it is a ratio of 
circumference to diameter.

That ratio is only numerically equal to π if the units you measure the 
cicumference and diameter are the same. Otherwise it has units 
"inches/cm" (or whatever units you used) and a completely different 
numerical value.

> On the other hand, a
> radian is a very real unit of distance/distance (based on its
> definition of arc length), and it's a unit of angle.

The SI system defines both radians and steradians as dimensionless 
derived units, previously known as "supplementary units".

-- 
Steve
___
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/PY2SIYNPBLQDRWFLFX6ZL2ZJT77FXMEK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

2022-04-04 Thread Greg Ewing


On 4/04/22 10:47 am, dn wrote:

You wouldn't believe it - have interrupted typing here to receive a
package. However, the clothing delivered is NOT the size ordered...


Let me guess, you ordered it in cm but they delivered it in inches?-)

--
Greg
___
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/ECXWLWZWPY243BGRAZI63TB4RZ3MH6UI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

2022-04-04 Thread Ethan Furman

On 4/4/22 13:31, David Mertz, Ph.D. wrote:

> You should probably change the thread subject to "All-and-only 7 SI units" if 
that's what you mean.

While I'm sure SI would be very useful, I suspect that any system will have to be useful for a much broader audience to 
be accepted; given the vast amount of units, I suspect individual libraries will be needed for each area/discipline.

So what hooks does Python need to provide to make such a thing feasible, easy to use, and, eventually if not 
immediately, performant?

One idea: have a `unit` attribute, and that attribute keeps track of the units 
so far in the operations:

[quick PoC]

class TaggedInt(int):
#
def __new__(cls, *args, unit=None, **kwds):
ti = int.__new__(cls, *args, **kwds)
if unit is None:
unit = ()
elif not isinstance(unit, tuple):
unit = (unit, )
ti.unit = unit
return ti
#
def __mul__(self, other):
other_unit = getattr(other, 'unit', None)
if other_unit is None:
unit = self.unit
else:
unit = self.condense(self.unit, '*', other_unit)
ti = TaggedInt(int.__mul__(self, other), unit=unit)
return ti
#
def __rmul__(self, other):
other_unit = getattr(other, 'unit', None)
if other_unit is None:
unit = self.unit
else:
unit = self.condense(other_unit, '*', self.unit)
ti = TaggedInt(int.__mul__(self, other), unit=unit)
return ti
#
def __repr__(self):
return '%s %s' % (int.__repr__(self), ''.join(str(u) for u in 
self.unit))
#
def condense(*args):
result = []
for arg in args:
if isinstance(arg, tuple) and len(arg) == 1:
result.append(arg[0])
else:
result.append(arg)
return tuple(result)

in use:

>>> to_home = TaggedInt(5, unit='km')
>>> to_home
5 km

>>> # home and back
>>> 2 * to_home
10 km

>>> # big square
>>> to_home * to_home
25 km*km

>>> _.unit
('km', '*', 'km')

Beyond that, do we make Python smart enough to, for example, convert `km*km` to `km^2`, or do we let libraries provide 
their own functions?  I'm inclined to let libraries provide their own, as they could also implement unit conversions as 
desired.

--
~Ethan~
___
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/QCODSL65G6MRAGOA36KY4RPIPOZRARIF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

You should probably change the thread subject to "All-and-only 7 SI units"
if that's what you mean.

On Mon, Apr 4, 2022 at 1:46 PM Brian McCall 
wrote:

> > I drove 20 minutes up the road to by a bushel (US, not British) of U.S.
> No. 1. apples, to make apple cider.  On my return trip, I stopped at the
> hardware store to buy a 2 lb box of 1-3/4" ring shank 12 penny nails.  I
> used my 7/8 hole kitchen planer blade to grate the apples, then squeezed
> them for an hour and a 15 minutes at 30 psi to extract the juice.  For good
> measure I added 2 tablespoons of vanilla and a pinch of salt.  Then I drove
> the nails into grade C 2x4 joists (whose sizes are 1.5 x 3.5 inches, with a
> 1/16th inch permissible tolerance in sizing).
>
> I'm going to start by ignoring any quantities above that are not involved
> in any sort of calculation. Those are outside the scope of the problem and
> proposal. And I don't care what anyone thinks of that.
>
> The only calculation I see here is 1.5 in x 3.5 in = 0.00339 mm2. The fact
> that joists are called 2x4 even though their nominal dimension is 1.5 in x
> 3.5 in is also outside the scope of the problem and proposal. Come on man,
> you think you're the only one who knows examples like this? How about 1/3"
> image sensors? How about display diagonals? I know about these things, and
> I know that they do not need to be accounted for in a standard,
> language-supported representation of units.
>
> Units have infinite precision, so grades and tolerances are also
> irrelevant.
>
> The units you mentioned are:
> minutes
> bushel (imperial)
> bushel (US)
> psi
> tablespoon
> pinch (it's a stretch, but okay)
> foot
> inch
>
> 7/8 hole - this is a specification, not a unit
> 2x4 joist - specification, not a unit
> grade C - specification, not a unit
> 12 penny - Wikipedia calls it a unit, but calculations in measurements
> taken in units of pennies are neither associative nor distributive, and
> transformations on measurements taken in units of pennies are neither
> additive nor multiplicative.
>
> Anyway, you mentioned you knew of at least 1000 units. I count 7. You have
> another 993?
> ___
> 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/DHRG6STCIHJ2XOF6SE7O27UG7MX66DS5/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
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/LQPY7AJZ5P6LVPN27NCBL4SUICOHVPNS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

>
> Units have infinite precision, so grades and tolerances are also
> irrelevant.
>

Not if you believe in Planck lengths (or quantum states) :-).

-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
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/2CSWETFQQBXRVBBPGBFTKTOPKPHG2TE3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

On Tue, 5 Apr 2022 at 05:47, Steven D'Aprano  wrote:
>
> On Mon, Apr 04, 2022 at 03:39:26PM +1000, Chris Angelico wrote:
>
> > I would say that 2.54in/1cm should be equal to 1.
>
> 2.54 inches is not 1 cm. This is how you get a billion dollar spacecraft
> crashing into Mars instead of landing softly :-)
>

This is why you don't get billion dollar spacecraft built in hybrid
unit systems to the specifications of quickly-written emails :)

ChrisA
___
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/HRMQF4HSYHDD5T67RBUF6RRUSKAGL3ZC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

On Tue, 5 Apr 2022 at 05:44, Steven D'Aprano  wrote:
> > Should 2.54 in / 1 cm evaluate to 2.54 in/cm or should
> > it evaluate to 1? I'd much rather it evaluate to 1
>
> There are only two reasonable ways to parse that, depending on
> precedence of units and operators:
>
> * (2.54 inches) / (1 cm) = 6.4516 (dimensionless)
>
> * (2.54 inches / 1) * cm = 6.4516 cm**2 (or 1 square inch)

This second format is nonsense, and demonstrates why these need to be
tagged numbers, NOT simple multiplications.

> If there is a third way, I can't think of it. In any case, I don't see
> how you can get 1.
>
> Maybe you mean 1 inch per 2.54 cm? This is why we need unit management
> :-)
>

The question is really whether it's dimensionless or retains some
record of the fact that it's length/length. The aspect ratio of a
rectangle is really a length/length measure, even though it's
technically dimensionless. An index of refraction is also
dimensionless, but you can't talk about them as being equivalent.

ChrisA
___
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/ONTUDZBP7VNQACVYZCQ3AU3ZZXA3GVMN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

On Mon, Apr 04, 2022 at 03:39:26PM +1000, Chris Angelico wrote:

> I would say that 2.54in/1cm should be equal to 1.

2.54 inches is not 1 cm. This is how you get a billion dollar spacecraft 
crashing into Mars instead of landing softly :-)

-- 
Steve
___
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/ZZ3T6VIMLR5UZYUWK37ZRTVRGXPEHLWV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

On Mon, Apr 04, 2022 at 04:22:25AM -, Brian McCall wrote:

[Chris]
> > Part of the problem here is that Python has to be many many things.
> > Which set of units is appropriate? For instance, in a lot of contexts,
> > it's fine to simply attach K to the end of something to mean "a
> > thousand", while still keeping it unitless; but in other contexts,
> > 273K clearly is a unit of temperature. 

Python is a programming language. I think we can require a certain 
minimum level of strictness, and reject ambiguity.

Please read the Frink FAQ, especially the part about DWIM:

https://frinklang.org/faq.html

K means Kelvin, end of story. We don't need to support informal use or 
slang out of the box.

But if units are scoped, like variables are, then people who really, 
really want K to mean 8192 bits can shadow the unit database with their 
own.

> Should 2.54 in / 1 cm evaluate to 2.54 in/cm or should 
> it evaluate to 1? I'd much rather it evaluate to 1

There are only two reasonable ways to parse that, depending on 
precedence of units and operators:

* (2.54 inches) / (1 cm) = 6.4516 (dimensionless)

* (2.54 inches / 1) * cm = 6.4516 cm**2 (or 1 square inch)

If there is a third way, I can't think of it. In any case, I don't see 
how you can get 1.

Maybe you mean 1 inch per 2.54 cm? This is why we need unit management 
:-)

-- 
Steve
___
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/XV3QHOCQT47E3GYE4IMT2OK54MDTBGQS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

On Mon, Apr 04, 2022 at 06:16:49AM -, Brian McCall wrote:

> So a comprehensive implementation of units would not require more than 
> 160 units, and in reality, a "sufficient" implementation would need 
> only 7.

The idea that a system which only supported the seven SI base 
quantities, and so couldn't even convert from imperial to metric, would 
be "sufficient" boggles my mind. Sufficient for what?

> An exceptionally good implementation could probably be done 
> with right around 100.

You must be easily pleased if you consider 100 units "exceptionally 
good". In 1986 the HP-28C calculator supported 120 units, plus 
user-defined units. If you don't at least reach the standard available 
in 1986, I'm not even sure if you reach "good", let alone exceptional.

(And yes, the HP-28C included teaspoon and tablespoon, but not hogshead, 
Roman mile or furlong.)

I would consider the Unix program "units", and Frink (which inherits its 
unit database from units), to be comprehensive. 160 units is about 7% of 
comprehensive.

-- 
Steve
___
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/54ZIL4BK2OGXRTM5A2MTFEXUMGS5WG7I/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

On Mon, Apr 04, 2022 at 05:45:52PM -, Brian McCall wrote:

> Anyway, you mentioned you knew of at least 1000 units. I count 7. You have 
> another 993?

Will 2451 do?


[steve@ando ~]$ units
2438 units, 71 prefixes, 32 nonlinear units


-- 
Steve
___
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/QQP2OVKCAFJK2O6EUJMFW3KSMZFZTWC7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

On Tue, 5 Apr 2022 at 04:19, Ethan Furman  wrote:
>
> On 4/3/22 22:39, Chris Angelico wrote:
>  > On Mon, 4 Apr 2022 at 14:22, Brian McCall wrote:
>
>  >> Related to these questions, there is the question of what to do about 
> mixed systems?
>  > Should 2.54 in / 1 cm evaluate to 2.54 in/cm or should it evaluate to 1?
>  >
>  > I would say that 2.54in/1cm should be equal to 1. Units should
>  > completely cancel out.
>
> It seems like the point of this exercise is to *not* have units cancel out -- 
> at least, not unnecessarily.
>
> 2.54in / 1 cm should be 2.54in/cm, otherwise multiplying by 5 kelvin will be 
> one of those hard-to-find bugs.

Hmm, fair point, I guess. It gets tricky, though. For an example,
let's look at fuel efficiency.

Outside of the US, vehicle fuel economy is measured in liters per
hundred kilometers. What unit category should this be considered to
be?

5 L/100km in SI units is 5e-3 m³ / 1e5m. That's 5e-8 m². Or if you
prefer, 50mm².

Fuel economy is a unit of area.

https://what-if.xkcd.com/11/

This DOES, as Munroe points out, have a geometric interpretation. I
think it's reasonable to say that fuel economy cancels down to a unit
of area, and it's *also* reasonable to say that it doesn't, and that
it simply remains as volume-per-distance.

Some unit cancellations really do result in pure scalars. The ratio of
a circle's circumference to its diameter isn't a unit of m/m any more
than the ratio of a circle's area to that of a circumscribed square is
a unit of m²/m². They're both just numbers. On the other hand, a
radian is a very real unit of distance/distance (based on its
definition of arc length), and it's a unit of angle.

I suspect that the rules of cancellation would be best handed off to
libraries, and there will be different choices for different
applications.

Maybe at some time in the future, there'll be a proposal to lock it
down and define it more by the language. It wouldn't be the first time
- type hints are now the only officially supported form of
annotations, but the precise meanings of those hints is still partly
up to the library.

> Of course, it's actually 2.54cm/in.
>

(I actually didn't even spot that part)

ChrisA
___
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/T6GF6J53KOSO74USIQTFIE23H4G7LR4S/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

2022-04-04 Thread Ricky Teachey

On Mon, Apr 4, 2022 at 2:24 PM Steven D'Aprano  wrote:

> On Sun, Apr 03, 2022 at 10:42:16PM -0400, Ricky Teachey wrote:
>
> > I was cheerleading this effort earlier and I still think it would be a
> > massive contribution to needs of the engineering world to solve this
> > problem at the language level. But boy howdy is it a tough but of a
> problem
> > to crack.
>
> More than 35 years of prior art says hello.
>
> My HP-28C calculator supported unit conversion in the mid 1980s, and a
> few years later HP were offering calculators that supported arithmetic
> on units.
>
> If you want to see some prior art, check out the chapters on Units here:
>
>
> https://web.archive.org/web/20150608024051/http://www.hp41.net/forum/fileshp41net/hp28sref.pdf
>
> http://h10032.www1.hp.com/ctg/Manual/c00442266.pdf
>
> If you are on a Linux or Unix system, you can check out the "units"
> program:
>
> [steve@ando ~]$ units "3 ounces * 200 furlongs per fortnight" "kg m/s"
> * 0.0028288774
> / 353.49711
>
>
> Then there is also Frink:
>
> https://frinklang.org/
>
>
> --
> Steve


These are cool finds. There is also Mathcad, which beautifully solved the
units problem well over 2 (3?) decades ago. Of course a Mathcad seat ain't
cheap. And there's Maple, and matlab.

All of these probably have things to teach us. Here is a screenshot of the
Mathcad units system definition interface; it doesn't solve all the
problems, but it solves many.

[image: image.png]

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/ILSL7E26TK7GSKBQHII5ZLEBVQCIT7IN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

2022-04-04 Thread Brian McCall

> 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 calculat

[Python-ideas] Re: Native support for units [was: custom literals]

On Sun, Apr 03, 2022 at 10:42:16PM -0400, Ricky Teachey wrote:

> I was cheerleading this effort earlier and I still think it would be a
> massive contribution to needs of the engineering world to solve this
> problem at the language level. But boy howdy is it a tough but of a problem
> to crack.

More than 35 years of prior art says hello.

My HP-28C calculator supported unit conversion in the mid 1980s, and a 
few years later HP were offering calculators that supported arithmetic 
on units.

If you want to see some prior art, check out the chapters on Units here:

https://web.archive.org/web/20150608024051/http://www.hp41.net/forum/fileshp41net/hp28sref.pdf

http://h10032.www1.hp.com/ctg/Manual/c00442266.pdf

If you are on a Linux or Unix system, you can check out the "units" 
program:

[steve@ando ~]$ units "3 ounces * 200 furlongs per fortnight" "kg m/s"
* 0.0028288774
/ 353.49711


Then there is also Frink:

https://frinklang.org/


-- 
Steve
___
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/OXH2QSXI6OTA7ZOJO4H4QX5NGDJZGIWP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

2022-04-04 Thread Ethan Furman


On 4/3/22 22:39, Chris Angelico wrote:
> On Mon, 4 Apr 2022 at 14:22, Brian McCall wrote:

>> Related to these questions, there is the question of what to do about mixed 
systems?
> Should 2.54 in / 1 cm evaluate to 2.54 in/cm or should it evaluate to 1?
>
> I would say that 2.54in/1cm should be equal to 1. Units should
> completely cancel out.

It seems like the point of this exercise is to *not* have units cancel out -- 
at least, not unnecessarily.

2.54in / 1 cm should be 2.54in/cm, otherwise multiplying by 5 kelvin will be 
one of those hard-to-find bugs.

Of course, it's actually 2.54cm/in.

--
~Ethan~
___
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/GBMXCK6EMNPXGEYMH3IZVRSAAH7GINVB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

2022-04-04 Thread Ethan Furman


On 4/4/22 08:54, Ken Kundert wrote:

> 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".

[several other examples elided]

It seems to me that these "unitless' units actually have units, even if they 
*appear* to cancel each other out.

--
~Ethan~
___
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/XLRERZPX4WP7S4D4WZ7DB3XSKICQJLDX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

On Tue, 5 Apr 2022 at 03:58, Marco Sulla  wrote:
>
> On Mon, 4 Apr 2022 at 07:47, Chris Angelico  wrote:
> >
> > Not a particle physicist, so I don't know what the usage actually is,
> > but wouldn't mass actually be eV/c²? If that's frequently written as
> > simply "eV", then that's another example of common non-SI usage that
> > really should be supportable, but only within its context.
>
> Brian probably referred to a geometrized unit system, where the speed
> of light c is set to one. This is very common in particle physics, it
> simplifies the formulas. Also other quantities are usually set to 1,
> as the charge of the electron etc.

Not sure what you mean by "geometrized", but that would be the same
concept as referring to "natural units", wouldn't it? In any case: the
speed of light might be 1, but it's still 1 distance divided by 1
time.

> That said, it's clear that a unit system is much more complicated
> than, for example, a timezone support. A task that many languages
> delegate to third party libraries, because it's a huge task, it's
> specialized and... it's boring.

Timezone support is a pretty big nightmare too :)

ChrisA
___
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/IAASVMVUYIH7PRW3KQRGMU6KXIZYV5WF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

2022-04-04 Thread Brian McCall

> I drove 20 minutes up the road to by a bushel (US, not British) of U.S. No. 
> 1. apples, to make apple cider.  On my return trip, I stopped at the hardware 
> store to buy a 2 lb box of 1-3/4" ring shank 12 penny nails.  I used my 7/8 
> hole kitchen planer blade to grate the apples, then squeezed them for an hour 
> and a 15 minutes at 30 psi to extract the juice.  For good measure I added 2 
> tablespoons of vanilla and a pinch of salt.  Then I drove the nails into 
> grade C 2x4 joists (whose sizes are 1.5 x 3.5 inches, with a 1/16th inch 
> permissible tolerance in sizing).

I'm going to start by ignoring any quantities above that are not involved in 
any sort of calculation. Those are outside the scope of the problem and 
proposal. And I don't care what anyone thinks of that.

The only calculation I see here is 1.5 in x 3.5 in = 0.00339 mm2. The fact that 
joists are called 2x4 even though their nominal dimension is 1.5 in x 3.5 in is 
also outside the scope of the problem and proposal. Come on man, you think 
you're the only one who knows examples like this? How about 1/3" image sensors? 
How about display diagonals? I know about these things, and I know that they do 
not need to be accounted for in a standard, language-supported representation 
of units.

Units have infinite precision, so grades and tolerances are also irrelevant.

The units you mentioned are:
minutes
bushel (imperial)
bushel (US)
psi
tablespoon
pinch (it's a stretch, but okay)
foot
inch

7/8 hole - this is a specification, not a unit
2x4 joist - specification, not a unit
grade C - specification, not a unit
12 penny - Wikipedia calls it a unit, but calculations in measurements taken in 
units of pennies are neither associative nor distributive, and transformations 
on measurements taken in units of pennies are neither additive nor 
multiplicative.

Anyway, you mentioned you knew of at least 1000 units. I count 7. You have 
another 993?
___
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/DHRG6STCIHJ2XOF6SE7O27UG7MX66DS5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

2022-04-04 Thread Ricky Teachey

On Mon, Apr 4, 2022 at 11:55 AM Ken Kundert  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

<>

...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

[Python-ideas] Re: Native support for units [was: custom literals]

On Mon, Apr 04, 2022 at 07:46:12AM -, Brian McCall wrote:

> Now do it for NumPy arrays

In response to Greg:

[quoting Greg]
I'm not convinced there's a need for new syntax here.

63*lbs

77*km/hr

With appropriate definitions of lbs, km and hr these
can be made to construct numbers with attached units.
[end quote]

Numpy arrays support array*scalar, which multiplies each 
element of the array by the scalar.

>>> import numpy as np
>>> arr = np.array([2, 3, 4, 5])
>>> arr*1.5
array([3. , 4.5, 6. , 7.5])

So we're part way there.

However, I suspect that having an array of unit objects rather than 
low-level machine ints or floats will reduce the performance of numpy a 
lot. This is probably unavoidable: there is no way you can do numeric 
computations and track units as cheaply as doing numeric computations 
*without* tracking units.

But performance should be the least of our concerns at this point.

-- 
Steve
___
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/2ICQ7UIA27MK35W35DPVCCJ4LJEZMCK6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Native support for units [was: custom literals]

2022-04-04 Thread Sebastian Berg

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 -, 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/NYVZMEG4UKUAO6XNR6

[Python-ideas] Re: Native support for units [was: custom literals]