I teach working scientists about numeric computing on a daily basis. There
are a few special field where Ken's ideas are the norm, at least in
informal notation. The large majority of working scientists would find a
syntax change like he proposes an annoyance and nuisance.
Alienating and confusing everyone who isn't a circuit designer is a bad
goal. It's not going to happen in python.
If you really want this syntax, you need to use a different language, or
maybe write a preprocessor that turns a slightly different language back
into Python.
On Aug 29, 2016 4:09 AM, "Ken Kundert" <python-id...@shalmirane.com> wrote:
> > > These do not seem like good reasons for not doing this.
> >
> > Not worded the way you have them, no, because you've aimed for an
> > extremely emotional argument instead of answering concrete questions
> > like "where's the code that this would improve". Find some real-world
> > code that would truly benefit from this. Show us how it's better.
>
> Sorry, I am trying very hard not to let my emotions show through, and
> instead
> provide answers, examples, and comments that are well reasoned and well
> supported. I do find it frustrating that I appear to be the only one
> involved in
> the conversation that has a strong background in numerical computation,
> meaning
> that I have to carry one side of the argument without any support. It is
> especially frustrating when that background is used as a reason to
> discount my
> position. Let me try to make the case in an unemotional way.
>
> It is hard to justify the need for SI scale factors being built into the
> language with an example because it is relatively simple to do the
> conversion.
> For example ...
>
> With built-in support for SI scale factors:
>
> h_line = 1.4204GHz
> print('hline = {:r}Hz'.format(h_line))
> ...
>
> In Python today:
>
> from engfmt import Quantity
> h_line = Quantity('1.4204GHz')
> print('hline = {:q}'.format(h_line))
> h_line = float(h_line)
> ...
>
> Not really much harder to use the library. This is very similar to the
> situation
> with octal numbers ...
>
> With built-in support for octal numbers:
>
> S_IFREG = 0o100000 # regular file
>
> With out built-in support for octal numbers:
>
> S_IFREG = int('100000', base=8) # regular file
>
> So just giving a simple example is not enough to see the importance of
> native
> support. The problem with using a library is that you always have to
> convert
> from SI scale factors as the number is input and then converting back as
> the
> number is output. So you can spend a fair amount of effort converting too
> and
> from representations that support SI scale factors. Not a big deal if
> there is
> only a few, but can be burdensome if there is a large number. But the real
> benefit to building it in a native capability is that it puts pressure on
> the
> rest of the ecosystem to also adopt the new way of representing real
> numbers.
> For example, now the interchange packages and formats (Pickle, YaML, etc.)
> need
> to come up with a way of passing the information without losing its
> essential
> character. This in turn puts pressure on other languages to follow suit.
> It
> would also put pressure on documenting and formatting packages, such as
> Sphinx,
> Jinja, and matplotlib, to adapt. Now it becomes easier to generate clean
> documentation. Also the interactive environments, such as ipython, need to
> adapt. The more this occurs, the better life gets for scientists and
> engineers.
>
>
> > Something that I don't think you've acknowledged is that the SI
> > scaling markers are *prefixes to units*, not *suffixes to numbers*.
> > That is to say, you don't have "132G" of a thing called a "pascal",
> > you have "132" of a thing called a "gigapascal". Outside of a
> > unit-based system, SI prefixes don't really have meaning. I don't
> > remember ever, in a scientific context, seeing a coefficient of
> > friction listed as "30 milli-something"; it's always "0.03". So if
> > unitless values are simply numbers, and Python's ints and floats are
> > unitless, they won't see much benefit from prefixes-on-nothing.
>
> Yeah, this is why I suggested that we support the ability for users to
> specify
> units with the numbers, but it is not a hard and fast rule. Once you add
> support
> for SI scale factors, people find them so convenient that they tend to use
> them
> whether they are units or not. For example, it is common for circuit
> designers
> to specify the gain of an amplifier using SI scale factors even though
> gain is
> often unitless. For example, gain=50k. Also, electrical engineers will
> often
> drop the units when they are obvious, especially if they are long. For
> example,
> it is common to see a resistance specified as 100k. When values are given
> in
> a table and all the values in a column have the same units, it is common
> to give
> numbers with scale factors by without units to save space.
>
> -Ken
> _______________________________________________
> 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/
