Re: [Python-ideas] SI scale factors in Python

[Ivan Levkivskyi]

On 26 August 2016 at 18:35, Steven D'Aprano  wrote:
> I think that units are orthogonal to types: I can have a float of unit
> "gram" and a Fraction of unit "gram", and they shouldn't necessarily be
> treated as the same type.

I think you are mixing here what I sometimes call classes (i.e. runtime
implementation)
and types (i.e., static "interface" declaration). In this terms I think
units are types.
But probably it is a more philosophical question and could be a matter of
taste.

On 27 August 2016 at 15:04, Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:

> def power(potential, current):
> return WattType(float(Volt)*float(Ampere))

One don't need to call float on NewTypes derived from it, they will be cast
"automatically", so that:

def power(I, V):
return WattType(I*V)

should be sufficient. Concerning the speed vs. flexibility issue, one could
use stub files:

# content of units.py

def WattType(x): return x
#etc.

# contents of units.pyi

class WattType:
def __init__(self, x: float) -> None:
...
def __mul__(self, other: float) -> WattType:
# over 9000 of complicated overloads and stuff

In such way units will be very fast at runtime but will be thoroughly
checked by static type checkers.

As I understand there are two separate parts of the proposal:

1) suffixes like micro, kilo, etc. -- but Guido does not like this idea yet
2) physical units -- this part I think could be 99% percent solved by PEP
484 and PEP 526
(it is not 100% because this will require dependent types).

--
Ivan

On 27 August 2016 at 22:22, Chris Angelico  wrote:

> On Sun, Aug 28, 2016 at 4:25 AM, Steven D'Aprano 
> wrote:
> >
> > Sympy (apparently) doesn't warn you if your units are incompatible, it
> > just treats them as separate terms in an expression:
> >
> > py> 2*m + 3*K
> > 3*K + 2*m
> >
> > which probably makes sense from the point of view of a computer algebra
> > system (adding two metres and three degrees Kelvin is no weirder than
> > adding x and y). But from a unit conversion point of view, I think
> > sympy is the wrong solution.
>
> As a generic tool, I would say this is correct. It keeps things simple
> and straight-forward. Worst case, you see a strange result at the end,
> rather than getting an instant exception; in fact, it's very similar
> to NaN, in that some operations might cancel out the "error" status.
>
> ChrisA
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] SI scale factors in Python

[Steven D'Aprano]

On Fri, Aug 26, 2016 at 03:23:24PM -0700, Ken Kundert wrote:
> Steven,
> This keeps coming up, so let me address it again.
> 
> First, I concede that you are correct that my proposal does not provide 
> dimensional analysis, so any dimensional errors that exist in this new code 
> will 
> not be caught by Python itself, as is currently the case.
> 
> However, you should concede that by bringing the units front and center in 
> the 
> language, they are more likely to be caught by the user themselves.

I do not concede any such thing at all.

At best this might apply under some circumstances with extremely simple 
formulae when working directly with literals, in other words when using 
Python like a souped-up calculator. (Which is a perfectly reasonable way 
to use Python -- I do that myself. But it's not the only way to use 
Python.) But counting against that is that there will be other cases 
where what should be a error will sneak past because it happens to look 
like a valid scale factor or unit:

x += 1Y  # oops, I fat-fingered the Y when I meant 16


> It is 
> my position that dimensional analysis is so difficult and burdensome that 
> there 
> is no way it should be in the base Python language. If available, it should 
> be 
> as an add on.

This is a strange and contradictory position to take. If dimensional 
analysis is so "difficult and burdensome", how do you expect the user to 
do it in their head by just looking at the source code?

It is your argument above that users will be able to catch dimensional 
errors just by looking at the units in the source code, but here, just 
one sentence later, you claim that dimensional analysis is so difficult 
and burdensome that users cannot deal with it even with the assistence 
of the interpreter. I cannot reconcile those two beliefs. If you think 
that dimensional analysis is both important and "difficult and 
burdensome", then surely we should want to automate as much of it as 
possible?

Of course the easy cases are easy:

torque = 45_N * 18_m

is obviously correct, but the hard cases are not. As far as I can tell, 
your suggested syntax doesn't easily support compound units, let alone 
more realistic cases of formulae from sciences other than electrical 
engineering:

# Van der Waals equation
pressure = (5_mol * 6.022140857e23/1_mol * 1.38064852e−23_J/1_K 
* 340_K / (2.5_m**3 - 5_mol * 0.1281_m**3/1_mol)
- (5_mol)**2*(19.7483_L*1_L*1_bar/(1_mol)**2)
/(2.5_m**3)**2)
)


I'm not even sure if I've got that right after checking it three times. 
I believe it is completely unrealistic to expect the reader to spot 
dimensional errors by eye in anything but the most trivial cases.

Here is how I would do the same calculation in sympy. For starters, 
rather than using a bunch of "magic constants" directly in the formula, 
I would set them up as named variables. That's just good programming 
practice whether there are units involved or not.


# Grab the units we need.
from sympy.physics.units import mol, J, K, m, Pa, bar, liter as L
# And some constants.
from sympy.physics.units import avogadro_constant as N_a, boltzmann as k
R = N_a*k
# Define our variables.
n = 5*mol
T = 340*K
V = 2.5*m**3
# Van der Waals constants for carbon tetrachloride.
a = 19.7483*L**2*bar/mol**2
b = 0.1281*m**3/mol
# Apply Van der Waals equation to calculate the pressure
p = n*R*T/(V - n*b) - n**2*a/V**2
# Print the result in Pascal.
print p/Pa


Sympy (apparently) doesn't warn you if your units are incompatible, it 
just treats them as separate terms in an expression:

py> 2*m + 3*K
3*K + 2*m

which probably makes sense from the point of view of a computer algebra 
system (adding two metres and three degrees Kelvin is no weirder than 
adding x and y). But from a unit conversion point of view, I think 
sympy is the wrong solution. Nevertheless, it still manages to give the 
right result, and in a form that is easy to understand, easy to read, 
and easy to confirm is correct.

(If p/Pa is not a pure number, then I know the units are wrong. That's 
not ideal, but it's better than having to track the units myself. There 
are better solutions than sympy, I just picked this because I happened 
to have it already installed.)


> This proposal is more about adding capabilities to be base 
> language that happen to make dimensional analysis easier and more attractive 
> than about providing dimensional analysis itself.

I think it is an admirable aim to want to make unit tracking easier in 
Python. That doesn't imply that this is the right way to go about it.

Perhaps you should separate your suggested syntax from your ultimate 
aim. Instead of insisting that your syntax is the One Right Way to get 
units into Python, how about thinking about what other possible syntax 
might work? Here's a possibility, thrown out just to be shot down:

# Van der Waals constants for carbon tetrachloride.
a = 19.7483 as 

Re: [Python-ideas] SI scale factors in Python

[David Mertz]

It really feels like the OP simply wants Python to become a language for
circuit design, with no consideration of general pulse usability, not of
other domains. Little in the proposal translates well outside his
particular domain, and the differences between domains simply make the
proposed additions opportunities for new errors.

On Aug 27, 2016 7:52 AM, "Xavier Combelle" 
wrote:

>
>
> On 27/08/2016 10:44, Ken Kundert wrote:
> > SPICE, written by Larry Nagel,  introduced the concept in 1972. It is a
> circuit
> > simulator, and the language involved was a netlist language: basically a
> list of
> > components, the nodes there were connected to, and their values. It
> looked like
> > this:
> >
> > R1 1 0 1K
> > C1 1 0 1nF
> > I1 1 0 1mA
> >
> > SPICE was an incredibly influential program used by virtually all circuit
> > designers for decades. Interesting, it was very likely the first open
> source
> > software project. It was developed at Berkeley as a free and open source
> > project, well before those terms were in common use, and it was highly
> > influential on the BSD UNIX developers, also at Berkeley, which in turn
> were
> > influential on Stallman at MIT.
> >
> > Verilog, a hardware modeling language adopted the concept in a small
> scale (just
> > for time) in the 1980's.  Then in the early 90's Verilog-A was created,
> > a version of Verilog designed to allow people to model analog circuits.
> It
> > allowed use of SI scale factors for all real numbers.  A few years later
> > Verilog-AMS was released. It combined Verilog and Verilog-A.  It also
> allows SI
> > scale factors on all real numbers.  I developed Verilog-A as well as
> Spectre,
> > a replacement for SPICE, and so I am intimately familiar with language
> issues,
> > the implementation issues, and the user issues of use of SI scale
> factors in
> > particular, and computational programming in general.
> >
> > So SPICE was a netlist language, Verilog was a modeling language. I was
> not
> > aware of any general purpose programming languages that offer supports
> for SI
> > scale factors or units. RPL, Frink, and Fortress are new to me. I took a
> quick
> > look at Frink and it does not look like a general purpose programming
> language
> > either, more like a calculator language. That is, of course, what RPL is.
> > Neither really look up to taking on a serious computational task.
> Fortress looks
> > like a general purpose programming language, but little detail seems to
> remain
> > about this language, and I found nothing on units or scale factors.
> >
> > -Ken
> >
> Both example (SPICE and Verilog) are electronic design languages.
> So their task is easy, they allow only electronic units. It is very
> likely that your experience
> in these languages can't be used to translate a general purpose language.
> I know that F# use  unit of measure (see for example:
> https://fsharpforfunandprofit.com/posts/units-of-measure/ or
> http://stevenpemberton.net/blog/2015/03/11/FSharp-Units-Of-Measure/ )
> this experience can hardly transpose to python has it is an heavily
> statically type checked language.
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] SI scale factors alone, without units or dimensional analysis

[Stephen J. Turnbull]

Ken Kundert writes:

 > The rule is you cannot give unit without a scale factor, and the
 > unity scale factor is _, so if you wanted to say 1 mol you would
 > use 1_mol. 1mol means one milli ol.  These look a little strange,
 > but that is because the use they unit scale factor, which is the
 > one that is currently not in heavy use.

One reason I like Python is that it has relatively few of these
irregularities and ambiguities (in comparison to other languages and
non-programming contexts with similar usage).  For me, that counts
against this proposal.

BTW, where is "_" used as the unit scale prefix?

 > I suggest that we do not support the h (=100), da (=10), d (=0.1),
 > or c (=0.01) scale factors.

I don't think it's reasonable to exclude those.  Around me, cm, dB,
and ha (centimeters, decibels, and hectares) are in common use.  What
happened to "support with a capital S"?

I don't speak for anybody but myself, but I think this proposal has
gotten less interesting/acceptable with each post.  I'm going wait and
see if the "units are types" approach goes anywhere.  I think it's
probably the only one that has wings, but that's because it requires
no change to the language.

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] SI scale factors in Python

[M.-A. Lemburg]

I've been following this discussion on and off for a while, but
still fail to see how SI units, factors or the like are a use
case which is general enough to warrant changing the language.

There are packages available on PyPI for dealing with this
in a similar way we deal with decimal literals in Python:

C extension:

https://pypi.python.org/pypi/cfunits/
http://pythonhosted.org/cfunits/cfunits.Units.html
(interfaces to the udunits-2 lib:
http://www.unidata.ucar.edu/software/udunits/udunits-2.2.20/doc/udunits/udunits2.html)

Pure python:

https://pypi.python.org/pypi/units/

IMHO, a literal notation like "2 m" is more likely related to
a missing operator which should be flagged as SyntaxError
than the declaration of an integer with associated unit.
By keeping such analysis to string to object conversion
tools/functions you make the intent explicit, which
allows for better error reporting.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Aug 27 2016)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
  http://www.malemburg.com/

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] SI scale factors alone, without units or dimensional analysis

[Arek Bulski]

SI units are a standard that was kind of imposed top down on the computer
science community. But we learned to use KB MB so why no keep the defacto
standard we already have? Kibibytes and mibibytes were never really
adopted.

1K == 1000
1KB == 1024
1M == 1000**2
1MB == 1024**2

Suffixes, simple.

int_value = 8M
float_value = 8.0M or float("8M")
fraction_value = Fraction(1M, 8) or Fraction("1M/8")
decimal_value = Decimal("1.2345M")

Suffixes are by definition at the end of a literal. So

1E1E == 1E1 * 1E
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] SI scale factors in Python

[Ken Kundert]

SPICE, written by Larry Nagel,  introduced the concept in 1972. It is a circuit
simulator, and the language involved was a netlist language: basically a list of
components, the nodes there were connected to, and their values. It looked like
this:

R1 1 0 1K
C1 1 0 1nF
I1 1 0 1mA

SPICE was an incredibly influential program used by virtually all circuit
designers for decades. Interesting, it was very likely the first open source
software project. It was developed at Berkeley as a free and open source
project, well before those terms were in common use, and it was highly
influential on the BSD UNIX developers, also at Berkeley, which in turn were
influential on Stallman at MIT.

Verilog, a hardware modeling language adopted the concept in a small scale (just
for time) in the 1980's.  Then in the early 90's Verilog-A was created,
a version of Verilog designed to allow people to model analog circuits.  It
allowed use of SI scale factors for all real numbers.  A few years later
Verilog-AMS was released. It combined Verilog and Verilog-A.  It also allows SI
scale factors on all real numbers.  I developed Verilog-A as well as Spectre,
a replacement for SPICE, and so I am intimately familiar with language issues,
the implementation issues, and the user issues of use of SI scale factors in
particular, and computational programming in general.

So SPICE was a netlist language, Verilog was a modeling language. I was not
aware of any general purpose programming languages that offer supports for SI
scale factors or units. RPL, Frink, and Fortress are new to me. I took a quick
look at Frink and it does not look like a general purpose programming language
either, more like a calculator language. That is, of course, what RPL is.
Neither really look up to taking on a serious computational task. Fortress looks
like a general purpose programming language, but little detail seems to remain
about this language, and I found nothing on units or scale factors.

-Ken

On Sat, Aug 27, 2016 at 01:48:29PM +1000, Steven D'Aprano wrote:
> On Fri, Aug 26, 2016 at 03:23:24PM -0700, Ken Kundert wrote:
> 
> > Second, I concede that there is some chance that users may be lulled into 
> > a false sense of complacency and that some dimensional errors would get 
> > missed 
> > by these otherwise normally very diligent users. But I would point out that 
> > I have been intensively using and supporting languages that provide this 
> > feature 
> > for 40 years and have never seen it.
> 
> In your first post, you said that there were no languages at all 
> that supported units as a language feature, and suggested that Python 
> should lead the way here:
> 
>   I find it a little shocking that no programming languages offer this
>   feature yet
> 
> Now you say you've been using these "languages" plural for forty years.
> Would you like to rephrase your claim? I am unable to reconcile the 
> discrepency.
> 
> (There are three languages that I know of that support units as a first 
> class language feature, RPL, Frink and Fortress. None of them are 40 
> years old.)
> 
> 
> 
> -- 
> Steve
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] SI scale factors alone, without units or dimensional analysis

[David Mertz]

>> Proposal number two: don't make any changes to the syntax, but treat
these as *literally* numeric scale factors.
>> k = kilo = 10**3
>> M = mega = 10**6
>> G = giga = 10**9
>>
>> int_value = 8*M float_value = 8.0*M
>> fraction_value = Fraction(1, 8)*M
>> decimal_value = Decimal("1.2345")*M

This is the only variant I've seen that I would consider "not awful." Of
course, this involves no change in the language, but just a module on PyPI.

Of the awful options, a suffix underscore and multiplier (1.1_G) is the
least awful. It's a little bit reminiscent of the optional internal
underscores being added to literals.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/