CINXE.COM

<!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <meta name="color-scheme" content="light dark"> <title>PEP 225 – Elementwise/Objectwise Operators | peps.python.org</title> <link rel="shortcut icon" href="../_static/py.png"> <link rel="canonical" href="https://peps.python.org/pep-0225/"> <link rel="stylesheet" href="../_static/style.css" type="text/css"> <link rel="stylesheet" href="../_static/mq.css" type="text/css"> <link rel="stylesheet" href="../_static/pygments.css" type="text/css" media="(prefers-color-scheme: light)" id="pyg-light"> <link rel="stylesheet" href="../_static/pygments_dark.css" type="text/css" media="(prefers-color-scheme: dark)" id="pyg-dark"> <link rel="alternate" type="application/rss+xml" title="Latest PEPs" href="https://peps.python.org/peps.rss"> <meta property="og:title" content='PEP 225 – Elementwise/Objectwise Operators | peps.python.org'> <meta property="og:description" content="This PEP describes a proposal to add new operators to Python which are useful for distinguishing elementwise and objectwise operations, and summarizes discussions in the news group comp.lang.python on this topic. See Credits and Archives section at end..."> <meta property="og:type" content="website"> <meta property="og:url" content="https://peps.python.org/pep-0225/"> <meta property="og:site_name" content="Python Enhancement Proposals (PEPs)"> <meta property="og:image" content="https://peps.python.org/_static/og-image.png"> <meta property="og:image:alt" content="Python PEPs"> <meta property="og:image:width" content="200"> <meta property="og:image:height" content="200"> <meta name="description" content="This PEP describes a proposal to add new operators to Python which are useful for distinguishing elementwise and objectwise operations, and summarizes discussions in the news group comp.lang.python on this topic. See Credits and Archives section at end..."> <meta name="theme-color" content="#3776ab"> </head> <body> <svg xmlns="http://www.w3.org/2000/svg" style="display: none;"> <symbol id="svg-sun-half" viewBox="0 0 24 24" pointer-events="all"> <title>Following system colour scheme</title> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"> <circle cx="12" cy="12" r="9"></circle> <path d="M12 3v18m0-12l4.65-4.65M12 14.3l7.37-7.37M12 19.6l8.85-8.85"></path> </svg> </symbol> <symbol id="svg-moon" viewBox="0 0 24 24" pointer-events="all"> <title>Selected dark colour scheme</title> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"> <path stroke="none" d="M0 0h24v24H0z" fill="none"></path> <path d="M12 3c.132 0 .263 0 .393 0a7.5 7.5 0 0 0 7.92 12.446a9 9 0 1 1 -8.313 -12.454z"></path> </svg> </symbol> <symbol id="svg-sun" viewBox="0 0 24 24" pointer-events="all"> <title>Selected light colour scheme</title> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"> <circle cx="12" cy="12" r="5"></circle> <line x1="12" y1="1" x2="12" y2="3"></line> <line x1="12" y1="21" x2="12" y2="23"></line> <line x1="4.22" y1="4.22" x2="5.64" y2="5.64"></line> <line x1="18.36" y1="18.36" x2="19.78" y2="19.78"></line> <line x1="1" y1="12" x2="3" y2="12"></line> <line x1="21" y1="12" x2="23" y2="12"></line> <line x1="4.22" y1="19.78" x2="5.64" y2="18.36"></line> <line x1="18.36" y1="5.64" x2="19.78" y2="4.22"></line> </svg> </symbol> </svg> <script> document.documentElement.dataset.colour_scheme = localStorage.getItem("colour_scheme") || "auto" </script> <section id="pep-page-section"> <header> <h1>Python Enhancement Proposals</h1> <ul class="breadcrumbs"> <li><a href="https://www.python.org/" title="The Python Programming Language">Python</a> » </li> <li><a href="../pep-0000/">PEP Index</a> » </li> <li>PEP 225</li> </ul> <button id="colour-scheme-cycler" onClick="setColourScheme(nextColourScheme())"> <svg aria-hidden="true" class="colour-scheme-icon-when-auto"><use href="#svg-sun-half"></use></svg> <svg aria-hidden="true" class="colour-scheme-icon-when-dark"><use href="#svg-moon"></use></svg> <svg aria-hidden="true" class="colour-scheme-icon-when-light"><use href="#svg-sun"></use></svg> Toggle light / dark / auto colour theme </button> </header> <article> <section id="pep-content"> <h1 class="page-title">PEP 225 – Elementwise/Objectwise Operators</h1> <dl class="rfc2822 field-list simple"> <dt class="field-odd">Author:</dt> <dd class="field-odd">Huaiyu Zhu <hzhu at users.sourceforge.net>, Gregory Lielens <gregory.lielens at fft.be></dd> <dt class="field-even">Status:</dt> <dd class="field-even"><abbr title="Formally declined and will not be accepted">Rejected</abbr></dd> <dt class="field-odd">Type:</dt> <dd class="field-odd"><abbr title="Normative PEP with a new feature for Python, implementation change for CPython or interoperability standard for the ecosystem">Standards Track</abbr></dd> <dt class="field-even">Created:</dt> <dd class="field-even">19-Sep-2000</dd> <dt class="field-odd">Python-Version:</dt> <dd class="field-odd">2.1</dd> <dt class="field-even">Post-History:</dt> <dd class="field-even"></dd> </dl> <hr class="docutils" /> <section id="contents"> <details><summary>Table of Contents</summary><ul class="simple"> <li><a class="reference internal" href="#introduction">Introduction</a></li> <li><a class="reference internal" href="#background">Background</a></li> <li><a class="reference internal" href="#proposed-extension">Proposed extension</a></li> <li><a class="reference internal" href="#prototype-implementation">Prototype Implementation</a></li> <li><a class="reference internal" href="#alternatives-to-adding-new-operators">Alternatives to adding new operators</a></li> <li><a class="reference internal" href="#alternative-forms-of-infix-operators">Alternative forms of infix operators</a></li> <li><a class="reference internal" href="#semantics-of-new-operators">Semantics of new operators</a></li> <li><a class="reference internal" href="#examples">Examples</a></li> <li><a class="reference internal" href="#miscellaneous-issues">Miscellaneous issues</a></li> <li><a class="reference internal" href="#impact-on-general-elementization">Impact on general elementization</a><ul> <li><a class="reference internal" href="#notes">Notes</a></li> </ul> </li> <li><a class="reference internal" href="#impact-on-named-operators">Impact on named operators</a></li> <li><a class="reference internal" href="#credits-and-archives">Credits and archives</a></li> <li><a class="reference internal" href="#additional-references">Additional References</a></li> </ul> </details></section> <div class="pep-banner sticky-banner deprecated rejected admonition warning"> Warning This PEP has been rejected. × The approach in the later <a class="pep reference internal" href="../pep-0465/" title="PEP 465 – A dedicated infix operator for matrix multiplication">PEP 465</a> was eventually accepted in lieu of this PEP. The <a class="pep reference internal" href="../pep-0465/#rejected-alternatives-to-adding-a-new-operator" title="PEP 465 – A dedicated infix operator for matrix multiplication § Rejected alternatives to adding a new operator">Rejected Ideas</a> of that PEP explains the rationale in more detail. </div> <section id="introduction"> <h2><a class="toc-backref" href="#introduction" role="doc-backlink">Introduction</a></h2> This PEP describes a proposal to add new operators to Python which are useful for distinguishing elementwise and objectwise operations, and summarizes discussions in the news group comp.lang.python on this topic. See Credits and Archives section at end. Issues discussed here include: <ul class="simple"> <li>Background.</li> <li>Description of proposed operators and implementation issues.</li> <li>Analysis of alternatives to new operators.</li> <li>Analysis of alternative forms.</li> <li>Compatibility issues</li> <li>Description of wider extensions and other related ideas.</li> </ul> A substantial portion of this PEP describes ideas that do not go into the proposed extension. They are presented because the extension is essentially syntactic sugar, so its adoption must be weighed against various possible alternatives. While many alternatives may be better in some aspects, the current proposal appears to be overall advantageous. The issues concerning elementwise-objectwise operations extends to wider areas than numerical computation. This document also describes how the current proposal may be integrated with more general future extensions. </section> <section id="background"> <h2><a class="toc-backref" href="#background" role="doc-backlink">Background</a></h2> Python provides six binary infix math operators: <code class="docutils literal notranslate">+</code> <code class="docutils literal notranslate">-</code> <code class="docutils literal notranslate">*</code> <code class="docutils literal notranslate">/</code> <code class="docutils literal notranslate">%</code> <code class="docutils literal notranslate">**</code> hereafter generically represented by <code class="docutils literal notranslate">op</code>. They can be overloaded with new semantics for user-defined classes. However, for objects composed of homogeneous elements, such as arrays, vectors and matrices in numerical computation, there are two essentially distinct flavors of semantics. The objectwise operations treat these objects as points in multidimensional spaces. The elementwise operations treat them as collections of individual elements. These two flavors of operations are often intermixed in the same formulas, thereby requiring syntactical distinction. Many numerical computation languages provide two sets of math operators. For example, in MatLab, the ordinary <code class="docutils literal notranslate">op</code> is used for objectwise operation while <code class="docutils literal notranslate">.op</code> is used for elementwise operation. In R, <code class="docutils literal notranslate">op</code> stands for elementwise operation while <code class="docutils literal notranslate">%op%</code> stands for objectwise operation. In Python, there are other methods of representation, some of which already used by available numerical packages, such as: <ul class="simple"> <li>function: mul(a,b)</li> <li>method: a.mul(b)</li> <li>casting: a.E*b</li> </ul> In several aspects these are not as adequate as infix operators. More details will be shown later, but the key points are: <ul class="simple"> <li>Readability: Even for moderately complicated formulas, infix operators are much cleaner than alternatives.</li> <li>Familiarity: Users are familiar with ordinary math operators.</li> <li>Implementation: New infix operators will not unduly clutter Python syntax. They will greatly ease the implementation of numerical packages.</li> </ul> While it is possible to assign current math operators to one flavor of semantics, there is simply not enough infix operators to overload for the other flavor. It is also impossible to maintain visual symmetry between these two flavors if one of them does not contain symbols for ordinary math operators. </section> <section id="proposed-extension"> <h2><a class="toc-backref" href="#proposed-extension" role="doc-backlink">Proposed extension</a></h2> <ul class="simple"> <li>Six new binary infix operators <code class="docutils literal notranslate">~+</code> <code class="docutils literal notranslate">~-</code> <code class="docutils literal notranslate">~*</code> <code class="docutils literal notranslate">~/</code> <code class="docutils literal notranslate">~%</code> <code class="docutils literal notranslate">~**</code> are added to core Python. They parallel the existing operators <code class="docutils literal notranslate">+</code> <code class="docutils literal notranslate">-</code> <code class="docutils literal notranslate">*</code> <code class="docutils literal notranslate">/</code> <code class="docutils literal notranslate">%</code> <code class="docutils literal notranslate">**</code>.</li> <li>Six augmented assignment operators <code class="docutils literal notranslate">~+=</code> <code class="docutils literal notranslate">~-=</code> <code class="docutils literal notranslate">~*=</code> <code class="docutils literal notranslate">~/=</code> <code class="docutils literal notranslate">~%=</code> <code class="docutils literal notranslate">~**=</code> are added to core Python. They parallel the operators <code class="docutils literal notranslate">+=</code> <code class="docutils literal notranslate">-=</code> <code class="docutils literal notranslate">*=</code> <code class="docutils literal notranslate">/=</code> <code class="docutils literal notranslate">%=</code> <code class="docutils literal notranslate">**=</code> available in Python 2.0.</li> <li>Operator <code class="docutils literal notranslate">~op</code> retains the syntactical properties of operator <code class="docutils literal notranslate">op</code>, including precedence.</li> <li>Operator <code class="docutils literal notranslate">~op</code> retains the semantical properties of operator <code class="docutils literal notranslate">op</code> on built-in number types.</li> <li>Operator <code class="docutils literal notranslate">~op</code> raise syntax error on non-number builtin types. This is temporary until the proper behavior can be agreed upon.</li> <li>These operators are overloadable in classes with names that prepend t (for tilde) to names of ordinary math operators. For example, <code class="docutils literal notranslate">__tadd__</code> and <code class="docutils literal notranslate">__rtadd__</code> work for <code class="docutils literal notranslate">~+</code> just as <code class="docutils literal notranslate">__add__</code> and <code class="docutils literal notranslate">__radd__</code> work for <code class="docutils literal notranslate">+</code>.</li> <li>As with existing operators, the <code class="docutils literal notranslate">__r*__()</code> methods are invoked when the left operand does not provide the appropriate method.</li> </ul> It is intended that one set of <code class="docutils literal notranslate">op</code> or <code class="docutils literal notranslate">~op</code> is used for elementwise operations, the other for objectwise operations, but it is not specified which version of operators stands for elementwise or objectwise operations, leaving the decision to applications. The proposed implementation is to patch several files relating to the tokenizer, parser, grammar and compiler to duplicate the functionality of corresponding existing operators as necessary. All new semantics are to be implemented in the classes that overload them. The symbol <code class="docutils literal notranslate">~</code> is already used in Python as the unary bitwise not operator. Currently it is not allowed for binary operators. The new operators are completely backward compatible. </section> <section id="prototype-implementation"> <h2><a class="toc-backref" href="#prototype-implementation" role="doc-backlink">Prototype Implementation</a></h2> Greg Lielens implemented the infix <code class="docutils literal notranslate">~op</code> as a patch against Python 2.0b1 source <a class="footnote-reference brackets" href="#id2" id="id1">[1]</a>. To allow <code class="docutils literal notranslate">~</code> to be part of binary operators, the tokenizer would treat <code class="docutils literal notranslate">~+</code> as one token. This means that currently valid expression <code class="docutils literal notranslate">~+1</code> would be tokenized as <code class="docutils literal notranslate">~+</code> <code class="docutils literal notranslate">1</code> instead of <code class="docutils literal notranslate">~ + 1</code>. The parser would then treat <code class="docutils literal notranslate">~+</code> as composite of <code class="docutils literal notranslate">~ +</code>. The effect is invisible to applications. Notes about current patch: <ul class="simple"> <li>It does not include <code class="docutils literal notranslate">~op=</code> operators yet.</li> <li>The <code class="docutils literal notranslate">~op</code> behaves the same as <code class="docutils literal notranslate">op</code> on lists, instead of raising exceptions.</li> </ul> These should be fixed when the final version of this proposal is ready. <ul> <li>It reserves <code class="docutils literal notranslate">xor</code> as an infix operator with the semantics equivalent to:<div class="highlight-default notranslate"><div class="highlight"><pre>def __xor__(a, b): if not b: return a elif not a: return b else: 0 </pre></div> </div> </li> </ul> This preserves true value as much as possible, otherwise preserve left hand side value if possible. This is done so that bitwise operators could be regarded as elementwise logical operators in the future (see below). </section> <section id="alternatives-to-adding-new-operators"> <h2><a class="toc-backref" href="#alternatives-to-adding-new-operators" role="doc-backlink">Alternatives to adding new operators</a></h2> The discussions on comp.lang.python and python-dev mailing list explored many alternatives. Some of the leading alternatives are listed here, using the multiplication operator as an example. <ol class="arabic"> <li>Use function <code class="docutils literal notranslate">mul(a,b)</code>.Advantage: <ul class="simple"> <li>No need for new operators.</li> </ul> Disadvantage: <ul class="simple"> <li>Prefix forms are cumbersome for composite formulas.</li> <li>Unfamiliar to the intended users.</li> <li>Too verbose for the intended users.</li> <li>Unable to use natural precedence rules.</li> </ul> </li> <li>Use method call <code class="docutils literal notranslate">a.mul(b)</code>.Advantage: <ul class="simple"> <li>No need for new operators.</li> </ul> Disadvantage: <ul class="simple"> <li>Asymmetric for both operands.</li> <li>Unfamiliar to the intended users.</li> <li>Too verbose for the intended users.</li> <li>Unable to use natural precedence rules.</li> </ul> </li> <li>Use shadow classes. For matrix class define a shadow array class accessible through a method <code class="docutils literal notranslate">.E</code>, so that for matrices a and b, <code class="docutils literal notranslate">a.E*b</code> would be a matrix object that is <code class="docutils literal notranslate">elementwise_mul(a,b)</code>.Likewise define a shadow matrix class for arrays accessible through a method <code class="docutils literal notranslate">.M</code> so that for arrays a and b, <code class="docutils literal notranslate">a.M*b</code> would be an array that is <code class="docutils literal notranslate">matrixwise_mul(a,b)</code>. Advantage: <ul class="simple"> <li>No need for new operators.</li> <li>Benefits of infix operators with correct precedence rules.</li> <li>Clean formulas in applications.</li> </ul> Disadvantage: <ul class="simple"> <li>Hard to maintain in current Python because ordinary numbers cannot have user defined class methods; i.e. <code class="docutils literal notranslate">a.E*b</code> will fail if a is a pure number.</li> <li>Difficult to implement, as this will interfere with existing method calls, like <code class="docutils literal notranslate">.T</code> for transpose, etc.</li> <li>Runtime overhead of object creation and method lookup.</li> <li>The shadowing class cannot replace a true class, because it does not return its own type. So there need to be a <code class="docutils literal notranslate">M</code> class with shadow <code class="docutils literal notranslate">E</code> class, and an <code class="docutils literal notranslate">E</code> class with shadow <code class="docutils literal notranslate">M</code> class.</li> <li>Unnatural to mathematicians.</li> </ul> </li> <li>Implement matrixwise and elementwise classes with easy casting to the other class. So matrixwise operations for arrays would be like <code class="docutils literal notranslate">a.M*b.M</code> and elementwise operations for matrices would be like <code class="docutils literal notranslate">a.E*b.E</code>. For error detection <code class="docutils literal notranslate">a.E*b.M</code> would raise exceptions.Advantage: <ul class="simple"> <li>No need for new operators.</li> <li>Similar to infix notation with correct precedence rules.</li> </ul> Disadvantage: <ul class="simple"> <li>Similar difficulty due to lack of user-methods for pure numbers.</li> <li>Runtime overhead of object creation and method lookup.</li> <li>More cluttered formulas.</li> <li>Switching of flavor of objects to facilitate operators becomes persistent. This introduces long range context dependencies in application code that would be extremely hard to maintain.</li> </ul> </li> <li>Using mini parser to parse formulas written in arbitrary extension placed in quoted strings.Advantage: <ul class="simple"> <li>Pure Python, without new operators</li> </ul> Disadvantage: <ul class="simple"> <li>The actual syntax is within the quoted string, which does not resolve the problem itself.</li> <li>Introducing zones of special syntax.</li> <li>Demanding on the mini-parser.</li> </ul> </li> <li>Introducing a single operator, such as <code class="docutils literal notranslate">@</code>, for matrix multiplication.Advantage: <ul class="simple"> <li>Introduces less operators</li> </ul> Disadvantage: <ul class="simple"> <li>The distinctions for operators like <code class="docutils literal notranslate">+</code> <code class="docutils literal notranslate">-</code> <code class="docutils literal notranslate">**</code> are equally important. Their meaning in matrix or array-oriented packages would be reversed (see below).</li> <li>The new operator occupies a special character.</li> <li>This does not work well with more general object-element issues.</li> </ul> </li> </ol> Among these alternatives, the first and second are used in current applications to some extent, but found inadequate. The third is the most favorite for applications, but it will incur huge implementation complexity. The fourth would make applications codes very context-sensitive and hard to maintain. These two alternatives also share significant implementational difficulties due to current type/class split. The fifth appears to create more problems than it would solve. The sixth does not cover the same range of applications. </section> <section id="alternative-forms-of-infix-operators"> <h2><a class="toc-backref" href="#alternative-forms-of-infix-operators" role="doc-backlink">Alternative forms of infix operators</a></h2> Two major forms and several minor variants of new infix operators were discussed: <ul> <li>Bracketed form:<div class="highlight-default notranslate"><div class="highlight"><pre>(op) [op] {op} <op> :op: ~op~ %op% </pre></div> </div> </li> <li>Meta character form:<div class="highlight-default notranslate"><div class="highlight"><pre>.op @op ~op </pre></div> </div> Alternatively the meta character is put after the operator. </li> <li>Less consistent variations of these themes. These are considered unfavorably. For completeness some are listed here:<ul class="simple"> <li>Use <code class="docutils literal notranslate">@/</code> and <code class="docutils literal notranslate">/@</code> for left and right division</li> <li>Use <code class="docutils literal notranslate">[*]</code> and <code class="docutils literal notranslate">(*)</code> for outer and inner products</li> <li>Use a single operator <code class="docutils literal notranslate">@</code> for multiplication.</li> </ul> </li> <li>Use <code class="docutils literal notranslate">__call__</code> to simulate multiplication:<div class="highlight-default notranslate"><div class="highlight"><pre>a(b) or (a)(b) </pre></div> </div> </li> </ul> Criteria for choosing among the representations include: <ul class="simple"> <li>No syntactical ambiguities with existing operators.</li> <li>Higher readability in actual formulas. This makes the bracketed forms unfavorable. See examples below.</li> <li>Visually similar to existing math operators.</li> <li>Syntactically simple, without blocking possible future extensions.</li> </ul> With these criteria the overall winner in bracket form appear to be <code class="docutils literal notranslate">{op}</code>. A clear winner in the meta character form is <code class="docutils literal notranslate">~op</code>. Comparing these it appears that <code class="docutils literal notranslate">~op</code> is the favorite among them all. Some analysis are as follows: <ul class="simple"> <li>The <code class="docutils literal notranslate">.op</code> form is ambiguous: <code class="docutils literal notranslate">1.+a</code> would be different from <code class="docutils literal notranslate">1 .+a</code>.</li> <li>The bracket type operators are most favorable when standing alone, but not in formulas, as they interfere with visual parsing of parentheses for precedence and function argument. This is so for <code class="docutils literal notranslate">(op)</code> and <code class="docutils literal notranslate">[op]</code>, and somewhat less so for <code class="docutils literal notranslate">{op}</code> and <code class="docutils literal notranslate"><op></code>.</li> <li>The <code class="docutils literal notranslate"><op></code> form has the potential to be confused with <code class="docutils literal notranslate"><</code> <code class="docutils literal notranslate">></code> and <code class="docutils literal notranslate">=</code>.</li> <li>The <code class="docutils literal notranslate">@op</code> is not favored because <code class="docutils literal notranslate">@</code> is visually heavy (dense, more like a letter): <code class="docutils literal notranslate">a@+b</code> is more readily read as <code class="docutils literal notranslate">a@ + b</code> than <code class="docutils literal notranslate">a @+ b</code>.</li> <li>For choosing meta-characters: Most of existing ASCII symbols have already been used. The only three unused are <code class="docutils literal notranslate">@</code> <code class="docutils literal notranslate">$</code> <code class="docutils literal notranslate">?</code>.</li> </ul> </section> <section id="semantics-of-new-operators"> <h2><a class="toc-backref" href="#semantics-of-new-operators" role="doc-backlink">Semantics of new operators</a></h2> There are convincing arguments for using either set of operators as objectwise or elementwise. Some of them are listed here: <ol class="arabic simple"> <li><code class="docutils literal notranslate">op</code> for element, <code class="docutils literal notranslate">~op</code> for object<ul class="simple"> <li>Consistent with current multiarray interface of Numeric package.</li> <li>Consistent with some other languages.</li> <li>Perception that elementwise operations are more natural.</li> <li>Perception that elementwise operations are used more frequently</li> </ul> </li> <li><code class="docutils literal notranslate">op</code> for object, <code class="docutils literal notranslate">~op</code> for element<ul class="simple"> <li>Consistent with current linear algebra interface of MatPy package.</li> <li>Consistent with some other languages.</li> <li>Perception that objectwise operations are more natural.</li> <li>Perception that objectwise operations are used more frequently.</li> <li>Consistent with the current behavior of operators on lists.</li> <li>Allow <code class="docutils literal notranslate">~</code> to be a general elementwise meta-character in future extensions.</li> </ul> </li> </ol> It is generally agreed upon that <ul class="simple"> <li>There is no absolute reason to favor one or the other.</li> <li>It is easy to cast from one representation to another in a sizable chunk of code, so the other flavor of operators is always minority.</li> <li>There are other semantic differences that favor existence of array-oriented and matrix-oriented packages, even if their operators are unified.</li> <li>Whatever the decision is taken, codes using existing interfaces should not be broken for a very long time.</li> </ul> Therefore, not much is lost, and much flexibility retained, if the semantic flavors of these two sets of operators are not dictated by the core language. The application packages are responsible for making the most suitable choice. This is already the case for NumPy and MatPy which use opposite semantics. Adding new operators will not break this. See also observation after subsection 2 in the Examples below. The issue of numerical precision was raised, but if the semantics is left to the applications, the actual precisions should also go there. </section> <section id="examples"> <h2><a class="toc-backref" href="#examples" role="doc-backlink">Examples</a></h2> Following are examples of the actual formulas that will appear using various operators or other representations described above. <ol class="arabic"> <li>The matrix inversion formula:<ul> <li>Using <code class="docutils literal notranslate">op</code> for object and <code class="docutils literal notranslate">~op</code> for element:<div class="highlight-default notranslate"><div class="highlight"><pre>b = a.I - a.I * u / (c.I + v/a*u) * v / a b = a.I - a.I * u * (c.I + v*a.I*u).I * v * a.I </pre></div> </div> </li> <li>Using <code class="docutils literal notranslate">op</code> for element and <code class="docutils literal notranslate">~op</code> for object:<div class="highlight-default notranslate"><div class="highlight"><pre>b = a.I @- a.I @* u @/ (c.I @+ v@/a@*u) @* v @/ a b = a.I ~- a.I ~* u ~/ (c.I ~+ v~/a~*u) ~* v ~/ a b = a.I (-) a.I (*) u (/) (c.I (+) v(/)a(*)u) (*) v (/) a b = a.I [-] a.I [*] u [/] (c.I [+] v[/]a[*]u) [*] v [/] a b = a.I <-> a.I <*> u </> (c.I <+> v</>a<*>u) <*> v </> a b = a.I {-} a.I {*} u {/} (c.I {+} v{/}a{*}u) {*} v {/} a </pre></div> </div> </li> </ul> Observation: For linear algebra using <code class="docutils literal notranslate">op</code> for object is preferable. Observation: The <code class="docutils literal notranslate">~op</code> type operators look better than <code class="docutils literal notranslate">(op)</code> type in complicated formulas. <ul> <li>using named operators:<div class="highlight-default notranslate"><div class="highlight"><pre>b = a.I @sub a.I @mul u @div (c.I @add v @div a @mul u) @mul v @div a b = a.I ~sub a.I ~mul u ~div (c.I ~add v ~div a ~mul u) ~mul v ~div a </pre></div> </div> </li> </ul> Observation: Named operators are not suitable for math formulas. </li> <li>Plotting a 3d graph<ul> <li>Using <code class="docutils literal notranslate">op</code> for object and <code class="docutils literal notranslate">~op</code> for element:<div class="highlight-default notranslate"><div class="highlight"><pre>z = sin(x~**2 ~+ y~**2); plot(x,y,z) </pre></div> </div> </li> <li>Using op for element and ~op for object:<div class="highlight-default notranslate"><div class="highlight"><pre>z = sin(x**2 + y**2); plot(x,y,z) </pre></div> </div> </li> </ul> Observation: Elementwise operations with broadcasting allows much more efficient implementation than MatLab. Observation: It is useful to have two related classes with the semantics of <code class="docutils literal notranslate">op</code> and <code class="docutils literal notranslate">~op</code> swapped. Using these the <code class="docutils literal notranslate">~op</code> operators would only need to appear in chunks of code where the other flavor dominates, while maintaining consistent semantics of the code. </li> <li>Using <code class="docutils literal notranslate">+</code> and <code class="docutils literal notranslate">-</code> with automatic broadcasting:<div class="highlight-default notranslate"><div class="highlight"><pre>a = b - c; d = a.T*a </pre></div> </div> Observation: This would silently produce hard-to-trace bugs if one of b or c is row vector while the other is column vector. </li> </ol> </section> <section id="miscellaneous-issues"> <h2><a class="toc-backref" href="#miscellaneous-issues" role="doc-backlink">Miscellaneous issues</a></h2> <ul> <li>Need for the <code class="docutils literal notranslate">~+</code> <code class="docutils literal notranslate">~-</code> operators. The objectwise <code class="docutils literal notranslate">+</code> <code class="docutils literal notranslate">-</code> are important because they provide important sanity checks as per linear algebra. The elementwise <code class="docutils literal notranslate">+</code> <code class="docutils literal notranslate">-</code> are important because they allow broadcasting that are very efficient in applications.</li> <li>Left division (solve). For matrix, <code class="docutils literal notranslate">a*x</code> is not necessarily equal to <code class="docutils literal notranslate">x*a</code>. The solution of <code class="docutils literal notranslate">a*x==b</code>, denoted <code class="docutils literal notranslate">x=solve(a,b)</code>, is therefore different from the solution of <code class="docutils literal notranslate">x*a==b</code>, denoted <code class="docutils literal notranslate">x=div(b,a)</code>. There are discussions about finding a new symbol for solve. [Background: MatLab use <code class="docutils literal notranslate">b/a</code> for <code class="docutils literal notranslate">div(b,a)</code> and <code class="docutils literal notranslate">a\b</code> for <code class="docutils literal notranslate">solve(a,b)</code>.]It is recognized that Python provides a better solution without requiring a new symbol: the <code class="docutils literal notranslate">inverse</code> method <code class="docutils literal notranslate">.I</code> can be made to be delayed so that <code class="docutils literal notranslate">a.I*b</code> and <code class="docutils literal notranslate">b*a.I</code> are equivalent to Matlab’s <code class="docutils literal notranslate">a\b</code> and <code class="docutils literal notranslate">b/a</code>. The implementation is quite simple and the resulting application code clean. </li> <li>Power operator. Python’s use of <code class="docutils literal notranslate">a**b</code> as <code class="docutils literal notranslate">pow(a,b)</code> has two perceived disadvantages:<ul class="simple"> <li>Most mathematicians are more familiar with <code class="docutils literal notranslate">a^b</code> for this purpose.</li> <li>It results in long augmented assignment operator <code class="docutils literal notranslate">~**=</code>.</li> </ul> However, this issue is distinct from the main issue here. </li> <li>Additional multiplication operators. Several forms of multiplications are used in (multi-)linear algebra. Most can be seen as variations of multiplication in linear algebra sense (such as Kronecker product). But two forms appear to be more fundamental: outer product and inner product. However, their specification includes indices, which can be either<ul class="simple"> <li>associated with the operator, or</li> <li>associated with the objects.</li> </ul> The latter (the Einstein notation) is used extensively on paper, and is also the easier one to implement. By implementing a tensor-with-indices class, a general form of multiplication would cover both outer and inner products, and specialize to linear algebra multiplication as well. The index rule can be defined as class methods, like: <div class="highlight-default notranslate"><div class="highlight"><pre>a = b.i(1,2,-1,-2) * c.i(4,-2,3,-1) # a_ijkl = b_ijmn c_lnkm </pre></div> </div> Therefore, one objectwise multiplication is sufficient. </li> <li>Bitwise operators.<ul class="simple"> <li>The proposed new math operators use the symbol ~ that is bitwise not operator. This poses no compatibility problem but somewhat complicates implementation.</li> <li>The symbol <code class="docutils literal notranslate">^</code> might be better used for <code class="docutils literal notranslate">pow</code> than bitwise <code class="docutils literal notranslate">xor</code>. But this depends on the future of bitwise operators. It does not immediately impact on the proposed math operator.</li> <li>The symbol <code class="docutils literal notranslate">|</code> was suggested to be used for matrix solve. But the new solution of using delayed <code class="docutils literal notranslate">.I</code> is better in several ways.</li> <li>The current proposal fits in a larger and more general extension that will remove the need for special bitwise operators. (See elementization below.)</li> </ul> </li> <li>Alternative to special operator names used in definition,<div class="highlight-default notranslate"><div class="highlight"><pre>def "+"(a, b) in place of def __add__(a, b) </pre></div> </div> This appears to require greater syntactical change, and would only be useful when arbitrary additional operators are allowed. </li> </ul> </section> <section id="impact-on-general-elementization"> <h2><a class="toc-backref" href="#impact-on-general-elementization" role="doc-backlink">Impact on general elementization</a></h2> The distinction between objectwise and elementwise operations are meaningful in other contexts as well, where an object can be conceptually regarded as a collection of elements. It is important that the current proposal does not preclude possible future extensions. One general future extension is to use <code class="docutils literal notranslate">~</code> as a meta operator to elementize a given operator. Several examples are listed here: <ol class="arabic"> <li>Bitwise operators. Currently Python assigns six operators to bitwise operations: and (<code class="docutils literal notranslate">&</code>), or (<code class="docutils literal notranslate">|</code>), xor (<code class="docutils literal notranslate">^</code>), complement (<code class="docutils literal notranslate">~</code>), left shift (<code class="docutils literal notranslate"><<</code>) and right shift (<code class="docutils literal notranslate">>></code>), with their own precedence levels.Among them, the <code class="docutils literal notranslate">&</code> <code class="docutils literal notranslate">|</code> <code class="docutils literal notranslate">^</code> <code class="docutils literal notranslate">~</code> operators can be regarded as elementwise versions of lattice operators applied to integers regarded as bit strings.: <div class="highlight-default notranslate"><div class="highlight"><pre>5 and 6 # 6 5 or 6 # 5 5 ~and 6 # 4 5 ~or 6 # 7 </pre></div> </div> These can be regarded as general elementwise lattice operators, not restricted to bits in integers. In order to have named operators for <code class="docutils literal notranslate">xor</code> <code class="docutils literal notranslate">~xor</code>, it is necessary to make <code class="docutils literal notranslate">xor</code> a reserved word. </li> <li>List arithmetics.:<div class="highlight-default notranslate"><div class="highlight"><pre>[1, 2] + [3, 4] # [1, 2, 3, 4] [1, 2] ~+ [3, 4] # [4, 6] ['a', 'b'] * 2 # ['a', 'b', 'a', 'b'] 'ab' * 2 # 'abab' ['a', 'b'] ~* 2 # ['aa', 'bb'] [1, 2] ~* 2 # [2, 4] </pre></div> </div> It is also consistent to Cartesian product: <div class="highlight-default notranslate"><div class="highlight"><pre>[1,2]*[3,4] # [(1,3),(1,4),(2,3),(2,4)] </pre></div> </div> </li> <li>List comprehension.:<div class="highlight-default notranslate"><div class="highlight"><pre>a = [1, 2]; b = [3, 4] ~f(a,b) # [f(x,y) for x, y in zip(a,b)] ~f(a*b) # [f(x,y) for x in a for y in b] a ~+ b # [x + y for x, y in zip(a,b)] </pre></div> </div> </li> <li>Tuple generation (the zip function in Python 2.0):<div class="highlight-default notranslate"><div class="highlight"><pre>[1, 2, 3], [4, 5, 6] # ([1,2, 3], [4, 5, 6]) [1, 2, 3]~,[4, 5, 6] # [(1,4), (2, 5), (3,6)] </pre></div> </div> </li> <li>Using <code class="docutils literal notranslate">~</code> as generic elementwise meta-character to replace map:<div class="highlight-default notranslate"><div class="highlight"><pre>~f(a, b) # map(f, a, b) ~~f(a, b) # map(lambda *x:map(f, *x), a, b) </pre></div> </div> More generally,: <div class="highlight-default notranslate"><div class="highlight"><pre>def ~f(*x): return map(f, *x) def ~~f(*x): return map(~f, *x) ... </pre></div> </div> </li> <li>Elementwise format operator (with broadcasting):<div class="highlight-default notranslate"><div class="highlight"><pre>a = [1,2,3,4,5] print ["%5d "] ~% a a = [[1,2],[3,4]] print ["%5d "] ~~% a </pre></div> </div> </li> <li>Rich comparison:<div class="highlight-default notranslate"><div class="highlight"><pre>[1, 2, 3] ~< [3, 2, 1] # [1, 0, 0] [1, 2, 3] ~== [3, 2, 1] # [0, 1, 0] </pre></div> </div> </li> <li>Rich indexing:<div class="highlight-default notranslate"><div class="highlight"><pre>[a, b, c, d] ~[2, 3, 1] # [c, d, b] </pre></div> </div> </li> <li>Tuple flattening:<div class="highlight-default notranslate"><div class="highlight"><pre>a = (1,2); b = (3,4) f(~a, ~b) # f(1,2,3,4) </pre></div> </div> </li> <li>Copy operator:<div class="highlight-default notranslate"><div class="highlight"><pre>a ~= b # a = b.copy() </pre></div> </div> </li> </ol> <blockquote> <div>There can be specific levels of deep copy:<div class="highlight-default notranslate"><div class="highlight"><pre>a ~~= b # a = b.copy(2) </pre></div> </div> </div></blockquote> <section id="notes"> <h3><a class="toc-backref" href="#notes" role="doc-backlink">Notes</a></h3> <ol class="arabic simple"> <li>There are probably many other similar situations. This general approach seems well suited for most of them, in place of several separated extensions for each of them (parallel and cross iteration, list comprehension, rich comparison, etc).</li> <li>The semantics of elementwise depends on applications. For example, an element of matrix is two levels down from the list-of-list point of view. This requires more fundamental change than the current proposal. In any case, the current proposal will not negatively impact on future possibilities of this nature.</li> </ol> Note that this section describes a type of future extensions that is consistent with current proposal, but may present additional compatibility or other problems. They are not tied to the current proposal. </section> </section> <section id="impact-on-named-operators"> <h2><a class="toc-backref" href="#impact-on-named-operators" role="doc-backlink">Impact on named operators</a></h2> The discussions made it generally clear that infix operators is a scarce resource in Python, not only in numerical computation, but in other fields as well. Several proposals and ideas were put forward that would allow infix operators be introduced in ways similar to named functions. We show here that the current extension does not negatively impact on future extensions in this regard. <ol class="arabic"> <li>Named infix operators.Choose a meta character, say <code class="docutils literal notranslate">@</code>, so that for any identifier <code class="docutils literal notranslate">opname</code>, the combination <code class="docutils literal notranslate">@opname</code> would be a binary infix operator, and: <div class="highlight-default notranslate"><div class="highlight"><pre>a @opname b == opname(a,b) </pre></div> </div> Other representations mentioned include: <div class="highlight-default notranslate"><div class="highlight"><pre>.name ~name~ :name: (.name) %name% </pre></div> </div> and similar variations. The pure bracket based operators cannot be used this way. This requires a change in the parser to recognize <code class="docutils literal notranslate">@opname</code>, and parse it into the same structure as a function call. The precedence of all these operators would have to be fixed at one level, so the implementation would be different from additional math operators which keep the precedence of existing math operators. The current proposed extension do not limit possible future extensions of such form in any way. </li> <li>More general symbolic operators.One additional form of future extension is to use meta character and operator symbols (symbols that cannot be used in syntactical structures other than operators). Suppose <code class="docutils literal notranslate">@</code> is the meta character. Then: <div class="highlight-default notranslate"><div class="highlight"><pre>a + b, a @+ b, a @@+ b, a @+- b </pre></div> </div> would all be operators with a hierarchy of precedence, defined by: <div class="highlight-default notranslate"><div class="highlight"><pre>def "+"(a, b) def "@+"(a, b) def "@@+"(a, b) def "@+-"(a, b) </pre></div> </div> One advantage compared with named operators is greater flexibility for precedences based on either the meta character or the ordinary operator symbols. This also allows operator composition. The disadvantage is that they are more like line noise. In any case the current proposal does not impact its future possibility. These kinds of future extensions may not be necessary when Unicode becomes generally available. Note that this section discusses compatibility of the proposed extension with possible future extensions. The desirability or compatibility of these other extensions themselves are specifically not considered here. </li> </ol> </section> <section id="credits-and-archives"> <h2><a class="toc-backref" href="#credits-and-archives" role="doc-backlink">Credits and archives</a></h2> The discussions mostly happened in July to August of 2000 on news group comp.lang.python and the mailing list python-dev. There are altogether several hundred postings, most can be retrieved from these two pages (and searching word “operator”): <blockquote> <div><a class="reference external" href="http://www.python.org/pipermail/python-list/2000-July/">http://www.python.org/pipermail/python-list/2000-July/</a> <a class="reference external" href="http://www.python.org/pipermail/python-list/2000-August/">http://www.python.org/pipermail/python-list/2000-August/</a></div></blockquote> The names of contributors are too numerous to mention here, suffice to say that a large proportion of ideas discussed here are not our own. Several key postings (from our point of view) that may help to navigate the discussions include: <blockquote> <div><a class="reference external" href="http://www.python.org/pipermail/python-list/2000-July/108893.html">http://www.python.org/pipermail/python-list/2000-July/108893.html</a> <a class="reference external" href="http://www.python.org/pipermail/python-list/2000-July/108777.html">http://www.python.org/pipermail/python-list/2000-July/108777.html</a> <a class="reference external" href="http://www.python.org/pipermail/python-list/2000-July/108848.html">http://www.python.org/pipermail/python-list/2000-July/108848.html</a> <a class="reference external" href="http://www.python.org/pipermail/python-list/2000-July/109237.html">http://www.python.org/pipermail/python-list/2000-July/109237.html</a> <a class="reference external" href="http://www.python.org/pipermail/python-list/2000-July/109250.html">http://www.python.org/pipermail/python-list/2000-July/109250.html</a> <a class="reference external" href="http://www.python.org/pipermail/python-list/2000-July/109310.html">http://www.python.org/pipermail/python-list/2000-July/109310.html</a> <a class="reference external" href="http://www.python.org/pipermail/python-list/2000-July/109448.html">http://www.python.org/pipermail/python-list/2000-July/109448.html</a> <a class="reference external" href="http://www.python.org/pipermail/python-list/2000-July/109491.html">http://www.python.org/pipermail/python-list/2000-July/109491.html</a> <a class="reference external" href="http://www.python.org/pipermail/python-list/2000-July/109537.html">http://www.python.org/pipermail/python-list/2000-July/109537.html</a> <a class="reference external" href="http://www.python.org/pipermail/python-list/2000-July/109607.html">http://www.python.org/pipermail/python-list/2000-July/109607.html</a> <a class="reference external" href="http://www.python.org/pipermail/python-list/2000-July/109709.html">http://www.python.org/pipermail/python-list/2000-July/109709.html</a> <a class="reference external" href="http://www.python.org/pipermail/python-list/2000-July/109804.html">http://www.python.org/pipermail/python-list/2000-July/109804.html</a> <a class="reference external" href="http://www.python.org/pipermail/python-list/2000-July/109857.html">http://www.python.org/pipermail/python-list/2000-July/109857.html</a> <a class="reference external" href="http://www.python.org/pipermail/python-list/2000-July/110061.html">http://www.python.org/pipermail/python-list/2000-July/110061.html</a> <a class="reference external" href="http://www.python.org/pipermail/python-list/2000-July/110208.html">http://www.python.org/pipermail/python-list/2000-July/110208.html</a> <a class="reference external" href="http://www.python.org/pipermail/python-list/2000-August/111427.html">http://www.python.org/pipermail/python-list/2000-August/111427.html</a> <a class="reference external" href="http://www.python.org/pipermail/python-list/2000-August/111558.html">http://www.python.org/pipermail/python-list/2000-August/111558.html</a> <a class="reference external" href="http://www.python.org/pipermail/python-list/2000-August/112551.html">http://www.python.org/pipermail/python-list/2000-August/112551.html</a> <a class="reference external" href="http://www.python.org/pipermail/python-list/2000-August/112606.html">http://www.python.org/pipermail/python-list/2000-August/112606.html</a> <a class="reference external" href="http://www.python.org/pipermail/python-list/2000-August/112758.html">http://www.python.org/pipermail/python-list/2000-August/112758.html</a><a class="reference external" href="http://www.python.org/pipermail/python-dev/2000-July/013243.html">http://www.python.org/pipermail/python-dev/2000-July/013243.html</a> <a class="reference external" href="http://www.python.org/pipermail/python-dev/2000-July/013364.html">http://www.python.org/pipermail/python-dev/2000-July/013364.html</a> <a class="reference external" href="http://www.python.org/pipermail/python-dev/2000-August/014940.html">http://www.python.org/pipermail/python-dev/2000-August/014940.html</a> </div></blockquote> These are earlier drafts of this PEP: <blockquote> <div><a class="reference external" href="http://www.python.org/pipermail/python-list/2000-August/111785.html">http://www.python.org/pipermail/python-list/2000-August/111785.html</a> <a class="reference external" href="http://www.python.org/pipermail/python-list/2000-August/112529.html">http://www.python.org/pipermail/python-list/2000-August/112529.html</a> <a class="reference external" href="http://www.python.org/pipermail/python-dev/2000-August/014906.html">http://www.python.org/pipermail/python-dev/2000-August/014906.html</a></div></blockquote> There is an alternative PEP (officially, <a class="pep reference internal" href="../pep-0211/" title="PEP 211 – Adding A New Outer Product Operator">PEP 211</a>) by Greg Wilson, titled “Adding New Linear Algebra Operators to Python”. Its first (and current) version is at: <blockquote> <div><a class="reference external" href="http://www.python.org/pipermail/python-dev/2000-August/014876.html">http://www.python.org/pipermail/python-dev/2000-August/014876.html</a> <a class="pep reference internal" href="../pep-0211/" title="PEP 211 – Adding A New Outer Product Operator">PEP 211</a></div></blockquote> </section> <section id="additional-references"> <h2><a class="toc-backref" href="#additional-references" role="doc-backlink">Additional References</a></h2> <aside class="footnote-list brackets"> <aside class="footnote brackets" id="id2" role="doc-footnote"> <dt class="label" id="id2">[<a href="#id1">1</a>]</dt> <dd><a class="reference external" href="http://MatPy.sourceforge.net/Misc/index.html">http://MatPy.sourceforge.net/Misc/index.html</a></aside> </aside> </section> </section> <hr class="docutils" /> Source: <a class="reference external" href="https://github.com/python/peps/blob/main/peps/pep-0225.rst">https://github.com/python/peps/blob/main/peps/pep-0225.rst</a> Last modified: <a class="reference external" href="https://github.com/python/peps/commits/main/peps/pep-0225.rst">2024-04-14 20:08:31 GMT</a> </article> <nav id="pep-sidebar"> <h2>Contents</h2> <ul> <li><a class="reference internal" href="#introduction">Introduction</a></li> <li><a class="reference internal" href="#background">Background</a></li> <li><a class="reference internal" href="#proposed-extension">Proposed extension</a></li> <li><a class="reference internal" href="#prototype-implementation">Prototype Implementation</a></li> <li><a class="reference internal" href="#alternatives-to-adding-new-operators">Alternatives to adding new operators</a></li> <li><a class="reference internal" href="#alternative-forms-of-infix-operators">Alternative forms of infix operators</a></li> <li><a class="reference internal" href="#semantics-of-new-operators">Semantics of new operators</a></li> <li><a class="reference internal" href="#examples">Examples</a></li> <li><a class="reference internal" href="#miscellaneous-issues">Miscellaneous issues</a></li> <li><a class="reference internal" href="#impact-on-general-elementization">Impact on general elementization</a><ul> <li><a class="reference internal" href="#notes">Notes</a></li> </ul> </li> <li><a class="reference internal" href="#impact-on-named-operators">Impact on named operators</a></li> <li><a class="reference internal" href="#credits-and-archives">Credits and archives</a></li> <li><a class="reference internal" href="#additional-references">Additional References</a></li> </ul> <a id="source" href="https://github.com/python/peps/blob/main/peps/pep-0225.rst">Page Source (GitHub)</a> </nav> </section> <script src="../_static/colour_scheme.js"></script> <script src="../_static/wrap_tables.js"></script> <script src="../_static/sticky_banner.js"></script> </body> </html>