It makes the language needlessly complicated, has no benefit I've discerned (vs using libraries), and is a magnet for a large class of bugs.

Well the comment about bugs in speculation that does not fit with the extensive experience in the electrical engineering community. But other than that, these arguments could be used against supporting binary, octal, and hexadecimal notation. Are you saying building those into the language was a mistake? On Sun, Aug 28, 2016 at 07:32:35PM -0700, David Mertz wrote:

-1 on Python ever having any syntactic support for SI scale factors.

Btw, the argument below feels dishonest in another respect. Within a domain there is a general size scale of quantities of interest. I worked in a molecular dynamics lab for a number of years, and we would deal with simulated timesteps of a few femtoseconds. A total simulation might run into microseconds (or with our custom supercomputer, a millisecond).

There were lots of issues I don't begin to understand of exactly how many femtoseconds might be possible to squeeze in a timesteps while retaining good behavior. But the numbers of interest were in the range 0.5-5, and anyone in the field knows that.

In contrast, cosmologists deal with intervals of petaseconds. Yeah, I know it's not as simple as that, but just to get at the symmetry.

No one would write 2.5e-15 every time they were doing something with an MD timestep. The scaling, if anywhere at all, would be defined once as a general factor at the boundaries. The number of interest is simply, e.g. 2.5, not some large negative exponent on that.

In fact, at a certain point I proposed that we should deal with rounding issues by calling the minimum domain specific time unit an attosecond, and only use integers in using this unit. That wasn't what was adopted, but it wasn't absurd. If we had done that, we simply deal with, say 1500 "inherent units" in the program. The fact it related to a physical quantity is at most something for documentation (this principle isn't different because we used floats in this case).

Yes, without an convenient way of specifying real numbers, the computation communities have to resort to things like this. And they can work for a while, but over type the scale of things often change, and good choice of scale can turn bad after a few years. For example, when I first started in electrical engineering, the typical size of capacitors was in the micro Farad range, and software would just assume that if you gave a capacitance it was in uF. But then, with the advancement of technology the capacitors got smaller. They went from uF to nF to pF and now a growing fraction of capacitors are specified in the fF range. The fact that SPICE allowed values to be specified with SI scale factors, meant that it continued to be easy to use over the years, whereas the programs that hard coded the scale of its numbers because increasing difficult to use and then eventually became simply absurd. Even your example is a good argument for specifying numbers is SI scale factors. If I am using one of your molecular simulators, I don't want to specify the simulation time range as being from 1 to 1_000_000_000_000 fs. That is ridiculous. There are 12 orders of magnitude between the minimum resolvable time and the maximum. There are only two practical ways of representing values over such a wide range: using SI scale factors and using exponential notation. And we can tell which is preferred. You said femptoseconds, you did not say 1e-15 seconds. Even you prefer SI scale factors. -Ken

On Aug 28, 2016 8:44 PM, "Ken Kundert" wrote:

...

Wow, things have suddenly turned very negative. I understand that this is very normal for these types of forums where it is easy to lose sight of the big picture. So let me try to refocus this discussion again.

MOTIVATION

The way the scientific and engineering communities predominately write real numbers is by using SI scale factors. These numbers almost always represent physical quantities, so it is common to write the number with scale factor and units. So for example, the distance to Andromeda is 780kpc, the pressure at the bottom of the Mariana Trench is 108MPa, the total power produced by a typical hurricane is 600TW, the number of base pairs in human DNA is 3.2Gb, and the Bohr radius is 53pm. These numbers are the language of science and engineering, but in recent years they have also entered the realm of popular culture. For example, an article by Ars Technica that calculates that the value of the music that can fit on a classic iPod as over $8G (that is the total penalty that can be accessed if they were all stolen copyright works).

http://arstechnica.com/tech-policy/2012/06/from-gigabytes- to-petadollars-copyright-math-begets-copyright-currency/

In all of these examples the numbers are either very large or very small, and they employ the use of SI scale factors to make them easy to write and communicate. This way of writing numbers is so well established that it was formally standardized as part of the International System of Units (the Système international d'unités) in 1960.

The problem is that most general purpose programming languages do not support this way of writing numbers. Instead they force people to convert the numbers to and from exponential notation, which is rather inconvenient and hard to read, write, say, or hear (it is much easier to say or hear 53 picometers than 5.3e-11 meters).

When working with a general purpose programming language, the above numbers become:

780kpc -> 7.8e+05 108MPa -> 1.08e+08 600TW -> 6e+14 3.2Gb -> 3.2e+09 53pm -> 5.3e-11 $8G -> 8e+09

Notice that the numbers become longer, harder to read, harder to type, harder to say, and harder to hear.

NEXT STEP

So the question is, should Python accommodate this widely used method of writing real numbers? Python already has many ways of writing numbers. For example, Python allows integers to be written in binary, octal, decimal and hex. Any number you can write in one form you can write in another, so the only real reason for providing all these ways is the convenience of the users. Don't Python's users in the scientific and engineering communities deserve the same treatment? These are, after all, core communities for Python.

Now, Python is a very flexible language, and it is certainly possible to add simple libraries to make it easy to read and write numbers with SI scale factors. I have written such a library (engfmt). But with such libraries this common form of writing numbers remains a second class citizen. The language itself does not understand SI scale factors, instead any time you want to input or output numbers in their natural form you must manually convert them yourself.

Changing Python so that it understands SI scale factors on real numbers as first class citizens innately requires a change to the base language; it cannot be done solely through libraries. The question before you is, should we do it?

The same question confronted the developers of Python when it was decided to add binary, octal and hexadecimal number support to Python. You could have done it with libraries, but you didn't because binary, octal and hexadecimal numbers were too common and important to be left as second class citizens. Well, use of binary, octal and hexadecimal numbers is tiny compared to the use of real numbers with SI scale factors.

Before we expend any more effort on this topic, let's put aside the question of how it should be done, or how it will be used after its done, and just focus on whether we do it at all. Should Python support real numbers specified with SI scale factors as first class citizens?

What do you think?

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

On Mon, Aug 29, 2016 at 12:33:16PM +1000, Chris Angelico wrote:

On Mon, Aug 29, 2016 at 11:44 AM, Ken Kundert wrote:

...

When working with a general purpose programming language, the above numbers become:

780kpc -> 7.8e+05 108MPa -> 1.08e+08 600TW -> 6e+14 3.2Gb -> 3.2e+09 53pm -> 5.3e-11 $8G -> 8e+09

Notice that the numbers become longer, harder to read, harder to type, harder to say, and harder to hear.

And easier to compare. The SI prefixes are almost consistent in using uppercase for larger units and lowercase for smaller, but not quite; and there's no particular pattern in which letter is larger. For someone who isn't extremely familiar with them, that makes them completely unordered - which is larger, peta or exa? Which is smaller, nano or pico? Plus, there's a limit to how far you can go with these kinds of numbers, currently yotta at e+24. Exponential notation scales to infinity (to 1e308 in IEEE 64-bit binary floats, but plenty further in decimal.Decimal - I believe its limit is about 1e+(1e6), and REXX on OS/2 had a limit of 1e+(1e10) for its arithmetic), remaining equally readable at all scales.

So we can't get rid of exponential notation, no matter what happens. Mathematics cannot usefully handle a system in which we have to represent large exponents with ridiculous compound scale factors:

sys.float_info.max = 179.76931348623157*Y*Y*Y*Y*Y*Y*Y*Y*Y*Y*Y*Y*E

(It's even worse if the Exa collision means you stop at Peta. 179.76931348623157*P*P*P*P*P*P*P*P*P*P*P*P*P*P*P*P*P*P*P*P*M, anyone?)

Which means that these tags are a duplicate way of representing a specific set of exponents.

Yes, of course. No one is suggesting abandoning exponential notation. I am not suggesting we force people to use SI scale factors, only that we allow them to. What I am suggesting is that we stop saying to them things like 'you must use exponential notation because we have decided that its better. See, you can easily compare the size of numbers by looking at the exponents.' What is wrong with have two ways of doing things? We have many ways of specifying the value of the integer 16: 0b10000, 0o20, 16, 0x10, 16L, ....

...

Before we expend any more effort on this topic, let's put aside the question of how it should be done, or how it will be used after its done, and just focus on whether we do it at all. Should Python support real numbers specified with SI scale factors as first class citizens?

Except that those are exactly the important questions to be answered. How *could* it be done? With the units stripped off, your examples become:

780k == 7.8e+05 == 780*k 108M == 1.08e+08 == 108*M 600T == 6e+14 == 600*T 3.2G == 3.2e+09 == 3.2*G 53p == 5.3e-11 == 53*p 8G == 8e+09 == 8*G

Without any support whatsoever, you can already use the third column notation, simply by creating this module:

# si.py k, M, G, T, P, E, Z, Y = 1e3, 1e6, 1e9, 1e12, 1e15, 1e18, 1e21, 1e24 m, μ, n, p, f, a, z, y = 1e-3, 1e-6, 1e-9, 1e-12, 1e-15, 1e-18, 1e-21, 1e-24 u = μ K = k

And using it as "from si import *" at the top of your code. Do we see a lot of code in the wild doing this? "[H]ow it will be used after it's done" is exactly the question that this would answer.

Because by focusing on the implementation details, we miss the big picture. We have already done that, and we ended up going down countless ratholes.

...

Don't Python's users in the scientific and engineering communities deserve the same treatment? These are, after all, core communities for Python.

Yes. That's why we have things like the @ matrix multiplication operator (because the numeric computational community asked for it), and %-formatting for bytes strings (because the networking, mainly HTTP serving, community asked for it). Python *does* have a history of supporting things that are needed by specific sub-communities of Python coders. But there first needs to be a demonstrable need. How much are people currently struggling due to the need to transform "gigapascal" into "e+9"? Can you show convoluted real-world code that would be made dramatically cleaner by language support?

Can you show code that would have been convoluted if Python had used a library rather than built-in support for hexadecimal numbers? So, in summary, you are suggesting that we tell the scientific and engineering communities that we refuse to provide native support for their preferred way of writing numbers because: 1. our way is better, 2. their way is bad because some uneducated person might see the numbers and not understand them, 3. we already have way of representing numbers that we came up with in the '60s and we simply cannot do another, 4. well we could do it, but we have decided that if you would only adapt to this new way of doing things that we just came up with, then we would not have to do any work, and that is better for us. Oh and this this new way of writing numbers, it only works in the program itself. Your out of luck when it comes to IO. These do not seem like good reasons for not doing this. -Ken

On Mon, Aug 29, 2016 at 1:40 PM, Brendan Barnwell wrote:

On 2016-08-28 20:29, Ken Kundert wrote:

...

What is wrong with have two ways of doing things? We have many ways of specifying the value of the integer 16: 0b10000, 0o20, 16, 0x10, 16L, ....

Zen of Python: "There should be one-- and preferably only one --obvious way to do it."

If Python didn't have binary or octal notation and someone came here proposing it, I would not support it, for the same reasons I don't support your proposal. If someone proposed eliminating binary or octal notation for Python 4 (or even maybe Python 3.8), I would probably support it for the same reason. Those notations are not useful enough to justify their existence. Hexadecimal is more justifiable as it is far more widely used, but I would be more open to removing hexadecimal than I would be to adding octal.

I agree with you on octal - there are very few places where it's the one obvious way to do things, and you can always use int("755",8) if you have data that's represented best octally. But hex is incredibly helpful when you do any sort of bit manipulations, and decimal quickly becomes unwieldy and error-prone. Here's some code from Lib/stat.py: S_IFDIR = 0o040000 # directory S_IFCHR = 0o020000 # character device S_IFBLK = 0o060000 # block device S_IFREG = 0o100000 # regular file S_IFIFO = 0o010000 # fifo (named pipe) S_IFLNK = 0o120000 # symbolic link S_IFSOCK = 0o140000 # socket file These are shown in octal, because Unix file modes are often written in octal. If Python didn't support octal, the obvious alternative would be hex: S_IFDIR = 0x4000 # directory S_IFCHR = 0x2000 # character device S_IFBLK = 0x6000 # block device S_IFREG = 0x8000 # regular file S_IFIFO = 0x1000 # fifo (named pipe) S_IFLNK = 0xA000 # symbolic link S_IFSOCK = 0xC000 # socket file About comparable for these; not as good for the actual permission bits, since there are three blocks of three bits. Python could manage without octal literals, as long as hex literals are available. (I don't support their *removal*, because that's completely unnecessary backward incompatibility; but if Python today didn't have octal support, I wouldn't support its addition.) But the decimal equivalents? No thank you. S_IFDIR = 16384 # directory S_IFCHR = 8192 # character device S_IFBLK = 24756 # block device S_IFREG = 32768 # regular file S_IFIFO = 4096 # fifo (named pipe) S_IFLNK = 40960 # symbolic link S_IFSOCK = 49152 # socket file One of these is wrong. Which one? You know for certain that each of these values has at most two bits set. Can you read these? If you're familiar with the powers of two, you should have no trouble eyeballing the single-bit examples, but what about the others? We need hex constants for anything that involves bitwise manipulations. Having binary constants is nice, but (like with octal) not strictly necessary; but we need at least one out of bin/oct/hex. (Also, 16L doesn't actually mean the integer 16 - it means the *long* integer 16, which is as different from 16 as 16.0 is.) ChrisA

On 29.08.2016 05:40, Brendan Barnwell wrote:

On 2016-08-28 20:29, Ken Kundert wrote:

...

What is wrong with have two ways of doing things? We have many ways of specifying the value of the integer 16: 0b10000, 0o20, 16, 0x10, 16L, ....

Zen of Python: "There should be one-- and preferably only one --obvious way to do it."

If Python didn't have binary or octal notation and someone came here proposing it, I would not support it, for the same reasons I don't support your proposal. If someone proposed eliminating binary or octal notation for Python 4 (or even maybe Python 3.8), I would probably support it for the same reason. Those notations are not useful enough to justify their existence. Hexadecimal is more justifiable as it is far more widely used, but I would be more open to removing hexadecimal than I would be to adding octal.

Also, "L" as a long-integer suffix is already gone in Python 3.

And now we have '_' in numbers. So much for "preferably one way". Sven

On Mon, Aug 29, 2016 at 1:29 PM, Ken Kundert wrote:

Because by focusing on the implementation details, we miss the big picture. We have already done that, and we ended up going down countless ratholes.

They're important ratholes though. Without digging into those questions, all you have is an emotive argument of "but we NEEEEEEED to support SI prefixes as integer suffixes!".

...

...

Don't Python's users in the scientific and engineering communities deserve the same treatment? These are, after all, core communities for Python.

Yes. That's why we have things like the @ matrix multiplication operator (because the numeric computational community asked for it), and %-formatting for bytes strings (because the networking, mainly HTTP serving, community asked for it). Python *does* have a history of supporting things that are needed by specific sub-communities of Python coders. But there first needs to be a demonstrable need. How much are people currently struggling due to the need to transform "gigapascal" into "e+9"? Can you show convoluted real-world code that would be made dramatically cleaner by language support?

Can you show code that would have been convoluted if Python had used a library rather than built-in support for hexadecimal numbers?

See my other email, with examples of bit flags. It's not too bad if you only ever work with a single bit at a time, but bit masks combine beautifully in binary, fairly cleanly in hex, and really badly in decimal. Hex is a great trade-off between clean bit handling and compact representation. (Octal is roughly the same trade-off, and in days of yore was the one obvious choice, but hex has overtaken it.)

So, in summary, you are suggesting that we tell the scientific and engineering communities that we refuse to provide native support for their preferred way of writing numbers because: 1. our way is better,

Is more general, yes. If all you have is SI prefixes, you're badly scuppered. If all you have is exponential notation, you can do everything.

2. their way is bad because some uneducated person might see the numbers and not understand them,

Is, again, less general. It's a way of writing numbers that makes sense only in a VERY narrow area.

3. we already have way of representing numbers that we came up with in the '60s and we simply cannot do another,

False.

4. well we could do it, but we have decided that if you would only adapt to this new way of doing things that we just came up with, then we would not have to do any work, and that is better for us. Oh and this this new way of writing numbers, it only works in the program itself. Your out of luck when it comes to IO.

I'm not sure what you mean by "IO" here, but if you're writing a program that accepts text strings and prints text strings, it's free to do whatever it wants.

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

On Mon, Aug 29, 2016 at 7:08 PM, Ken Kundert 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.

An "emotional argument" doesn't necessarily mean that your emotions are governing everything - it's more that your line of reasoning is to play on other people's emotions, rather than on concrete data. Your primary argument has been "But think of all the scientific developers - don't you care about them??", without actually giving us code to work with. (In a recent post, you did at least give notes from a conversation with a lady of hard science, but without any of her code, we still can't evaluate the true benefit of unitless SI scaling.)

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.

No no no; your background is not a reason to discount your position. However, on its own, it's insufficient justification for your position. Suppose I come to python-ideas and say "Hey, the MUD community would really benefit from a magic decoder that would use UTF-8 where possible, ISO-8859-1 as fall-back, and Windows-1252 for characters not in 8859-1". Apart from responding that 8859-1 is a complete subset of 1252, there's not really a lot that you could discuss about that proposal, unless I were to show you some of my code. I can tell you about the number of MUDs that I play, the number of MUD clients that I've written, and some stats from my MUD server, and say "The MUD community needs this support", but it's of little value compared to actual code. (For the record, a two-step decode of "UTF-8, fall back on 1252" is exactly what I do... in half a dozen lines of code. So this does NOT need to be implemented.) That's why I keep asking you for code examples. Real-world code, taken from important projects, that would be significantly improved by this proposal. It has to be Python 3 compatible (unless you reckon that this is the killer feature that will make people take the jump from 2.7), and it has to be enough of an improvement that its authors will be willing to drop support for <3.6 (which might be a trivial concern, eg if the author expects to be the only person running the code).

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.

Maybe; or maybe you'd already be doing a lot of I/O work, and it's actually quite trivial to slap in one little function call at one call site, and magically apply it to everything you do. Without code, we can't know. (I sound like a broken record here.)

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.

Ewwww, I doubt it. That would either mean a whole lot of interchange formats would need to have a whole new form of support. You didn't mention JSON, but that's a lot more common than Pickle; and JSON is unlikely to gain a feature like this unless ECMAScript does (because JSON is supposed to be a strict subset of JavaScript's Object Notation). Pickle - at least the one in Python - doesn't need any way to store non-semantic information, so unless you intend for the scale factor to be a fundamental part of the number, it won't need changes. (People don't manually edit pickle files the way they edit JSON files.) YAML might need to be enhanced. That's the only one I can think of. And it's a big fat MIGHT.

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.

Eww eww eww. You're now predicating your benefit on a huge number of different groups gaining support for this. To what extent do they need to take notice of the SI scales on numbers? Input-only? Output? Optionally on output? How do you control this? Are SI-scaled numbers somehow different from raw numbers, or are they equivalent forms (like 1.1e3 and 1100.0)? If they're equivalent forms, how do you decide how to represent on output? Are all these questions to be answered globally, across all systems, or is it okay for one group to decide one thing and another another?

...

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.

Gain of 50k, that makes reasonable sense. Resistance as 100k is a shorthand for "100 kiloohms", and it's still fundamentally a unit-bearing value. All of this would be fine if you were building a front-end that was designed *SOLELY* for electrical engineers. So maybe that's the best way. Fork IDLE or iPython and build the very best electrical engineering interactive Python; it doesn't matter, then, how crazy it is for everyone else. You can mess with stuff on the way in and on the way out, you can interpret numbers as unitless values despite being written as "100kPa", and you can figure out what to do in all the edge cases based on actual real-world usage. You'd have your own rules for backward compatibility, rather than being bound by Python's release model (18 months between feature improvements, and nothing gets dropped without a VERY good reason), so you could chop and change as you have need. The base language would still be Python, but it'd be so optimized for electrical engineers that you'd never want to go back to vanilla CPython 3.6. Sound doable? ChrisA

On Mon, Aug 29, 2016 at 1:55 PM, Sven R. Kunze wrote:

There was no reasonable real-world code examples taken from important projects, that would be significantly improved by underscores in numbers.

I recall dozens of real world examples that came up during the discussion, and have written very numerous such examples in code of my own. This is something that directly affects readability in code I write almost every day, and is a clear and obvious win. I taught examples *today* where I would have badly liked to have underscore separators, and it was obvious to me and students that awkwardness. Writing, e.g. `range(int(1e7))` feel contrives (but usually the way I do it). Writing `range(10000000)` is nearly impossible to parse visually. In contrast, writing `range(10_000_000)` will be immediately clear and obvious. None of those things can be said of SI units as Python literals. -- 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.

On Tue, 30 Aug 2016 at 12:48 Sven R. Kunze wrote:

On 30.08.2016 04:34, David Mertz wrote:

On Mon, Aug 29, 2016 at 1:55 PM, Sven R. Kunze wrote:

...

There was no reasonable real-world code examples taken from important projects, that would be significantly improved by underscores in numbers.

I recall dozens of real world examples that came up during the discussion, and have written very numerous such examples in code of my own. This is something that directly affects readability in code I write almost every day, and is a clear and obvious win.

I taught examples *today* where I would have badly liked to have underscore separators, and it was obvious to me and students that awkwardness. Writing, e.g. `range(int(1e7))` feel contrives (but usually the way I do it). Writing `range(10000000)` is nearly impossible to parse visually. In contrast, writing `range(10_000_000)` will be immediately clear and obvious.

None of those things can be said of SI units as Python literals.

Hu? None of those things? I do think you exaggerate quite a lot here.

If your real-world example works for underscores, it works for SI units and scales as well.

There is obvious way now: G = Ghz = 1000 frequency = 1 * Ghz You can even have a non naive version Ghz that supports conversions and unit checking when doing arithmetic with it.

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

Nikolaus, I have belatedly realized that this kind of hyperbole is counter productive. So let me back away from that statement and instead try to understand your reasons for not liking the proposal. Do you think there is no value to be able to naturally read and write numbers with SI scale factors from Python? Or is your issue with something about my proposal? -Ken On Mon, Aug 29, 2016 at 06:59:15PM -0700, Nikolaus Rath wrote:

On Aug 28 2016, Ken Kundert wrote:

...

So, in summary, you are suggesting that we tell the scientific and engineering communities that we refuse to provide native support for their preferred way of writing numbers because:

I think you're making some incorrect assumptions here. Who, exactly, do you mean with "we" and "them"?

I consider myself part of the scientific community and think your proposal is a bad idea, and Google finds some Python modules from you, but no prior CPython contributions...

Best, -Nikolaus

-- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

»Time flies like an arrow, fruit flies like a Banana.« _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

On Aug 29 2016, Ken Kundert wrote:

Nikolaus, I have belatedly realized that this kind of hyperbole is counter productive. So let me back away from that statement and instead try to understand your reasons for not liking the proposal.

Do you think there is no value to be able to naturally read and write numbers with SI scale factors from Python? Or is your issue with something about my proposal?

* I think there is no value gained by being able to write 32.3m instead of 32.3e6. I think the second one is clear to everyone who uses SI prefixes, while the first one just introduces a lot of complexities. Most of them have been mentioned already: - no deducible ordering if one doesn't know the prefixes - potential for ambiguity with Exa - question about base 2 vs base 10, e.g what do you expect to be stored in *size* if you reed this: "size = 10M # we need that many bytes" - rather abitrary naming ("M" and "m" vs "T" and "p"). * I think having SI *Unit* support "32.3 kN" would be nice, but only if there is a space between number and unit, and only if the unit actually get's attached to the number. But your proposal would result in 1km + 1µN == 2 being true. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«

There are other languages too that had hexadecimal and octal.

They've been around in programming languages for decades.

How many languages have scale factors?

Does Fortran? Not that I know of.

The reason why hexadecimal and octal are in general purpose languages and real numbers with SI scale factors are not is because languages are developed by computer scientists and not by scientists. I keep using SPICE and Verilog as examples of a languages that supports SI scale factors, and that is because they are the extremely rare cases where the languages were either developed or specified by end users and not by computer scientists. The reason why computer scientists tend to add hexadecimal and octal numbers to their languages and not SI scale factors is that they use hexadecimal and octal numbers, and as we have seen by this discussion, are rather unfamiliar with real numbers with SI scale factors. It is easy for them to justify adding hex because they know from personal experience that it is useful, but if you don't use widely scaled real numbers day in and day out it is hard to understand just how tedious exponential notation is and how useful it would be to use SI scale factors.

On Sun, Aug 28, 2016 at 08:26:38PM -0700, Brendan Barnwell wrote:

On 2016-08-28 18:44, Ken Kundert wrote:

...

When working with a general purpose programming language, the above numbers become:

780kpc -> 7.8e+05 [...]

For the record, I don't know what kpc might mean. "kilo pico speed of light"? So I looked it up using units, and it is kilo-parsecs. That demonstrates that unless your audience is intimately familiar with the domain you are working with, adding units (especially units that aren't actually used for anything) adds confusion. Python is not a specialist application targetted at a single domain. It is a general purpose programming language where you can expect a lot of cross-domain people (e.g. a system administrator asked to hack on a script in a domain they know nothing about).

You've continually repeated this assertion, but I don't buy it. For the general case, exponential notation is easier to read because you can always see exactly what the exponent is as a number. To read SI units, you have to know all the SI prefixes. This may well be common within scientific communities, but to say that it is "easier" is really a bit much. The same is true of "harder to type". "kpc" is three characters; e+5 is also three (note that you don't need to write e+05),

You don't have to write e+5 either, just e5 is sufficient.

and one of those is a number that transparently indicates how many places to move the decimal, whereas all of the letters in "kpc" are opaque unless you already know what the number is meant to represent.

If you have concrete evidence (e.g., from actual user experience research) showing that it is across-the-board "easier" to read or type SI prefixes than exponential notation, that would be good to see.

I completely believe Ken that within a single tightly focussed user community, using their expected conventions (including SI prefixes) works really well. But Python users do not belong to a single tightly focussed user community. -- Steve

On 2016-08-29 00:07, Ken Kundert wrote:

...

...

I completely believe Ken that within a single tightly focussed user community, using their expected conventions (including SI prefixes) works really well. But Python users do not belong to a single tightly focussed user community. You think that Python is only used by generalists? That is silly. Have you seen SciPy? If you think that, take a look at Casa (casaguides.nrao.edu). It is written by astrophysicists for astrophysicists doing observations on radio telescope arrays. That is pretty specialized.

I think you misunderstand. My position (reiterated by the text you quote from Steven D'Aprano) is not that Python is used only by generalists. It is that we shouldn't change Python in a way that ONLY helps specialists. -- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown

On Mon, Aug 29, 2016 at 5:07 PM, Ken Kundert wrote:

I talked to astrophysicist about your comments, and what she said was: 1. She would love it if Python had built in support for real numbers with SI scale factors 2. I told her about my library for reading and writing numbers with SI scale factors, and she was much less enthusiastic because using it would require convincing the rest of the group, which would be too much effort. 3. She was amused by the "kilo pico speed of light" comment, but she was adamant that the fact that you, or some system administrator, does not understand what kpc means has absolutely no affect on her desired to use SI scale factors. Her comment: I did not write it for him. 4. She pointed out that the software she writes and uses is intended either for herself of other astrophysicists. No system administrators involved.

So can you share some of her code, and show how the ability to scale unitless numbers would help it? ChrisA

On Mon, Aug 29, 2016 at 9:07 AM, Ken Kundert wrote:

On Mon, Aug 29, 2016 at 01:45:20PM +1000, Steven D'Aprano wrote:

...

On Sun, Aug 28, 2016 at 08:26:38PM -0700, Brendan Barnwell wrote:

...

On 2016-08-28 18:44, Ken Kundert wrote:

...

When working with a general purpose programming language, the above numbers become:

780kpc -> 7.8e+05 [...]

For the record, I don't know what kpc might mean. "kilo pico speed of light"? So I looked it up using units, and it is kilo-parsecs. That demonstrates that unless your audience is intimately familiar with the domain you are working with, adding units (especially units that aren't actually used for anything) adds confusion.

Python is not a specialist application targetted at a single domain. It is a general purpose programming language where you can expect a lot of cross-domain people (e.g. a system administrator asked to hack on a script in a domain they know nothing about).

I talked to astrophysicist about your comments, and what she said was: 1. She would love it if Python had built in support for real numbers with SI scale factors 2. I told her about my library for reading and writing numbers with SI scale factors, and she was much less enthusiastic because using it would require convincing the rest of the group, which would be too much effort. 3. She was amused by the "kilo pico speed of light" comment, but she was adamant that the fact that you, or some system administrator, does not understand what kpc means has absolutely no affect on her desired to use SI scale factors. Her comment: I did not write it for him. 4. She pointed out that the software she writes and uses is intended either for herself of other astrophysicists. No system administrators involved.

Astropy also has a very powerful units package--originally derived from pyunit I think but long since diverged and grown: http://docs.astropy.org/en/stable/units/index.html It was originally developed especially for astronomy/astrophysics use and has some pre-defined units that many other packages don't have, as well as support for logarithmic units like decibel and optional (and customizeable) unit equivalences (e.g. frequency/wavelength or flux/power). That said, its power extends beyond astronomy and I heard through last week's EuroScipy that even some biology people have been using it. There's been some (informal) talk about splitting it out from Astropy into a stand-alone package. This is tricky since almost everything in Astropy has been built around it (dimensional calculations are always used where possible), but not impossible. One of the other big advantages of astropy.units is the Quantity class representing scale+dimension values. This is deeply integrated into Numpy so that units can be attached to Numpy arrays, and all Numpy ufuncs can operate on them in a dimensionally meaningful way. The needs for this have driven a number of recent features in Numpy. This is work that, unfortunately, could never be integrated into the Python stdlib.

On Aug 29, 2016, at 06:08, Erik Bray wrote:

On Mon, Aug 29, 2016 at 3:05 PM, Erik Bray mailto:erik.m.bray@gmail.com> wrote:

...

On Mon, Aug 29, 2016 at 9:07 AM, Ken Kundert wrote:

...

On Mon, Aug 29, 2016 at 01:45:20PM +1000, Steven D'Aprano wrote:

...

On Sun, Aug 28, 2016 at 08:26:38PM -0700, Brendan Barnwell wrote:

...

On 2016-08-28 18:44, Ken Kundert wrote:

...

When working with a general purpose programming language, the above numbers become:

780kpc -> 7.8e+05 [...]

For the record, I don't know what kpc might mean. "kilo pico speed of light"? So I looked it up using units, and it is kilo-parsecs. That demonstrates that unless your audience is intimately familiar with the domain you are working with, adding units (especially units that aren't actually used for anything) adds confusion.

Python is not a specialist application targetted at a single domain. It is a general purpose programming language where you can expect a lot of cross-domain people (e.g. a system administrator asked to hack on a script in a domain they know nothing about).

I talked to astrophysicist about your comments, and what she said was: 1. She would love it if Python had built in support for real numbers with SI scale factors 2. I told her about my library for reading and writing numbers with SI scale factors, and she was much less enthusiastic because using it would require convincing the rest of the group, which would be too much effort. 3. She was amused by the "kilo pico speed of light" comment, but she was adamant that the fact that you, or some system administrator, does not understand what kpc means has absolutely no affect on her desired to use SI scale factors. Her comment: I did not write it for him. 4. She pointed out that the software she writes and uses is intended either for herself of other astrophysicists. No system administrators involved.

Astropy also has a very powerful units package--originally derived from pyunit I think but long since diverged and grown:

http://docs.astropy.org/en/stable/units/index.html

It was originally developed especially for astronomy/astrophysics use and has some pre-defined units that many other packages don't have, as well as support for logarithmic units like decibel and optional (and customizeable) unit equivalences (e.g. frequency/wavelength or flux/power).

That said, its power extends beyond astronomy and I heard through last week's EuroScipy that even some biology people have been using it. There's been some (informal) talk about splitting it out from Astropy into a stand-alone package. This is tricky since almost everything in Astropy has been built around it (dimensional calculations are always used where possible), but not impossible.

One of the other big advantages of astropy.units is the Quantity class representing scale+dimension values. This is deeply integrated into Numpy so that units can be attached to Numpy arrays, and all Numpy ufuncs can operate on them in a dimensionally meaningful way. The needs for this have driven a number of recent features in Numpy. This is work that, unfortunately, could never be integrated into the Python stdlib.

I'll also add that syntactic support for units has rarely been an issue in Astropy. The existing algebraic rules for units work fine with Python's existing order of operations. It can be *nice* to be able to write "1m" instead of "1 * m" but ultimately it doesn't add much for clarity (and if really desired could be handled with a preparser--something I've considered adding for Astropy sources (via codecs).

I just want to add, as an astrophysicist who uses astropy.units: the astropy solution is pretty great, and I don’t mind the library overhead. I’d much rather have astropy.units, which does dimensional analysis, as well as handling SI prefixes for 2 reasons: 1. I don’t normally see or use SI prefixes without units, so bare SI prefixes are fairly worthless to me as a scientist. IF the units are going to be there, I’d much rather have a library that does a good job at dimensional analysis, and has taken my domain-specific concerns into account, for reasons fairly well covered in this thread. 2. I don’t find it cumbersome at all to use something like astropy.units which provides both the prefix and units for my code on input and output. The added syntactic weight of a single import, plus multiplication, is really not that big a burden, and makes it both clear what I am trying to write, and easy for the library to maintain this meaning when I use the variable later. e.g. from astropy.units import * distance = 10 * km If that multiplication symbol is really too much to handle, then I’d rather see python support implicit multiplication as suggested above (i.e. “10 km” is parsed as “10 * km") and domain-specific libraries can support SI prefixes and units. ~ Alex

Best, Erik _______________________________________________ Python-ideas mailing list Python-ideas@python.org mailto:Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/ http://python.org/psf/codeofconduct/

On 30 August 2016 at 13:48, Ken Kundert wrote:

>>> d_sun = 93e6*u.imperial.mile >>> print(d_sun.to(u.parsec)) 4.850441695494146e-06 pc

The "imperial.mile" example here highlights one key benefit that expression based approaches enjoy over dedicated syntax: easy access to Python's existing namespace features. As a quick implementation sketch, consider something like:

...

...

si_scaling = dict(k=1000, m=0.001) class SIScale: ... def __getattr__(self, key): ... return SIUnit(si_scaling[key]) ... class SIUnit: ... def __init__(self, value): ... self.value = value ... def __getattr__(self, ignored): ... return self.value ... si = SIScale() 500 * si.k.m 500000 500 * si.k.parsec 500000 500 * si.m.m 0.5 500 * si.m.N 0.5

You could also relatively easily adapt that such that there there was only one level of lookup, and you could write the examples without the second dot (you'd just need to do some parsing of the key value in __getattr__ to separate the SI prefix from the nominal units) One particular benefit of this kind of approach is that you automatically avoid the "E" ambiguity problem, since there's nothing wrong with "si.E" from Python's perspective. You also gain an easy hook to attach interactive help: "help(si)" (or si? in IPython terms) Expanding out to full dimensional analysis with something like astropy.units also becomes relatively straightforward, just by changing the kind of value that __getattr__ returns. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

Steve, Actually I initially asked for the distances in parsecs and was expecting that they would be presented in a convenient format. So, to frame it in terms of your analogy, I ordered a short black and become upset when I am delivered 8oz of coffee in a 55 gallon drum. This seems to be one of those unstated assumptions that have caused confusion in these discussions. Sometimes you want fix the prefix, sometimes you don't. For example, the Bel (B) is a unit of measure for ratios, but we never use it directly, we always use decibels (dB). Nobody uses mB or kB or even B, it is always dB. But with other units we do use the scale factors and we do tend to normalize the presentation. For example, nobody says the Usain Bolt won the 100000mm dash, or the 0.1km dash. Similarly when people refer to the length of the Olympic road race in Rio, they say 56km, not 56000m. This is really only an issue with output. What I am suggesting is adding support for the second case into stdlib. For example: >>> print('Attenuation = {:.1f}dB at {:r}m.'.format(-13.7, 50e3)) Attenuation = -13.7dB at 50km. -Ken On Tue, Aug 30, 2016 at 11:41:10PM +1000, Steven D'Aprano wrote:

On Mon, Aug 29, 2016 at 08:48:55PM -0700, Ken Kundert wrote:

...

>>> print(d_sun.to(u.kpc)) 4.850441695494146e-09 kpc

I can see where this can be helpful at times, but it kind of goes against the spirit of SI scale factors, were you are generally expected to 'normalize' the scale factor (use the scale factor that results in the digits presented before the decimal point falling between 1 and 999). So I would expected

d_andromeda = 780 kpc d_sun = 4.8504 upc

Let me see if I get this straight... you *explicitly* asked for the distance to the sun in kpc (kiloparsecs), but you expected a result in µpc (microparsecs)?

When you ask the waiter for a short black, do you get upset that he doesn't bring you a latte with soy milk? *wink*

I can see that such a normalising function would be useful, but I don't think it should be the default. (If I ask for millimetres, I want millimetres, not gigametres.) I've written and used code like that for bytes, it makes sense to apply it to other measurement units. But only if the caller requests normalisation, never by default.

I don't think there is any such general expectation that values should be normalised in that way, and certainly not that your conversion program should automatically do it for you. For example, see this list of long-lived radioactive isotopes:

http://w.astro.berkeley.edu/~dperley/areopagus/isotopetable.html

Values above 650,000,000,000 (650e9) years are shown in "scientific format", not "engineering format", e.g. Selenium-82 is given as 1.1 x 10^20 rather than 110 x 10^18.

Likewise:

http://www.nist.gov/pml/data/halflife-html.cfm

displays a range of units (minutes, hours, days) with the base value ranging up to over ten thousand, e.g. Ti-44 is shown as 22154 ± 456 days. This is NIST, which makes it pretty official. I don't think there's any general expectation that values should be shown in the range 1 to 999. (Perhaps in certain specialist areas.)

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

Guido, I am in the process of summarizing the discussion as a way of wrapping this up. As part of that I will be making a proposal that I think has a chance of being accepted, and it will largely be what you suggest. -Ken On Tue, Aug 30, 2016 at 11:59:19AM -0700, Guido van Rossum wrote:

On Tue, Aug 30, 2016 at 11:48 AM, Ken Kundert wrote:

...

[...] Similarly when people refer to the length of the Olympic road race in Rio, they say 56km, not 56000m.

However I can't help to point out that if I said the distance to the sun is 149.6 Gm, most people would do a double-take.

...

This is really only an issue with output.

So maybe the proposal should be toned down to just a way to request SI units when formatting numbers?

-- --Guido van Rossum (python.org/~guido)

I talked to astrophysicist about your comments, and what she said was: 1. She would love it if Python had built in support for real numbers with SI scale factors 2. I told her about my library for reading and writing numbers with SI scale factors, and she was much less enthusiastic because using it would require convincing the rest of the group, which would be too much effort. 3. She was amused by the "kilo pico speed of light" comment, but she was adamant that the fact that you, or some system administrator, does not understand what kpc means has absolutely no affect on her desired to use SI scale factors. Her comment: I did not write it for him. 4. She pointed out that the software she writes and uses is intended either for herself of other astrophysicists. No system administrators involved.

It has been pointed out to me that the above comes off as being condescending towards Steven, system administrators and language developers in general. For this I am profoundly sorry. It was not my intent. My only point was that the output of these numerical programs are often so highly specialized that only the authors and their peers understand it. Let me go further in saying that if anything I have said in this discussion has come off as critical or insulting please know that that was not my intent. I have tremendous respect for what you all have accomplished and I am extremely appreciative of all the feedback and help you have given me. -Ken

On 29/08/2016 13:35, Stephan Houben wrote:

Note that the Sage computer algebra system uses Python with some syntactic changes implemented by a "pre-parser".

The current proposal could be implemented in a similar way and then integrated in, say, Ipython.

If it would prove to be wildly popular, then it would make a stronger case for incorporation in the core.

Stephan

Op 29 aug. 2016 2:12 p.m. schreef "Mark Lawrence via Python-ideas" mailto:python-ideas@python.org>:

On 29/08/2016 02:44, Ken Kundert wrote:

Changing Python so that it understands SI scale factors on real numbers as first class citizens innately requires a change to the base language; it cannot be done solely through libraries. The question before you is, should we do it?

No, no, no, if the people who provide this http://www.scipy.org/ can do without it.

Now would you please be kind enough to give up with this dead horse before I take a ride to the Clifton Suspension Bridge or Beachy Head, whichever is closest.

As iPython is a core part of scipy, which I linked above, why would the developers want to incorporate this suggestion? I'd have also thought that if this idea was to be "wildly popular" it would have been done years ago. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence

On Mon, Aug 29, 2016 at 10:55 PM, Mark Lawrence via Python-ideas wrote:

I'd have also thought that if this idea was to be "wildly popular" it would have been done years ago.

Here's my question, though, if you want to see the lanterns so badly, why haven't you gone before? -- Flynn Rider, to Rapunzel There are a good few reasons, one of which is simply "nobody's actually done the work to implement it". And a lot of end users might be excited to use something if it were implemented, but wouldn't think to ask for it if nobody mentioned it. Spotting the feature that isn't there is a pretty hard thing to do (unless you're comparing two products and can say "what I want is program X but with feature Q from program Y"). ChrisA