    <rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:sy="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/">
     <channel>
        <title>ACCU  :: The Universality and Expressiveness of std::accumulate</title>
        <link>https://members.accu.org/index.php/articles/2182</link>
        <description>Professionalism in Programming</description>
        <dc:language>en-us</dc:language> 
        <dc:creator>Administrator</dc:creator> 
        <admin:generatorAgent rdf:resource="http://www.xaraya.org" /> 
        <admin:errorReportsTo rdf:resource="mailto:webeditor@accu.org" />
       <sy:updatePeriod>hourly</sy:updatePeriod>
       <sy:updateFrequency>1</sy:updateFrequency>
       <docs>http://backend.userland.com/rss</docs>




<div class="xar-mod-head"><span class="xar-mod-title">Programming Topics + Overload Journal #130 - December 2015</span></div>

<table border="0" cellpadding="1" cellspacing="0">
    <tbody>
    <tr>
        <td valign="top">
            Browse in :
       </td>
       <td valign="top">

                                            <a href="https://members.accu.org/index.php/articles/">All</a>

                     &gt;                         <a href="https://members.accu.org/index.php/articles/c13/">Topics</a>

                     &gt;                         <a href="https://members.accu.org/index.php/articles/c65/">Programming</a>
<br />

                                            <a href="https://members.accu.org/index.php/articles/">All</a>

                     &gt;                         <a href="https://members.accu.org/index.php/articles/c76/">Journals</a>

                     &gt;                         <a href="https://members.accu.org/index.php/articles/c78/">Overload</a>

                     &gt;                         <a href="https://members.accu.org/index.php/articles/c356/">o130</a>
<br />

                                            <a href="https://members.accu.org/index.php/articles/c65-356/">Any of these categories</a>

                    -                        <a href="https://members.accu.org/index.php/articles/c65+356/">All of these categories</a>
<br />
</td>
   </tr>
   </tbody>
</table>




<div class="xar-error">
   <p>
 <strong>Note:</strong> when you create a new publication type,
the articles module will automatically use the templates
<em>user-display-[publicationtype].xt</em>
and <em>user-summary-[publicationtype].xt</em>.
If those templates do not exist when you try to preview or display a new article,
you'll get this warning :-)  Please place your own templates in themes/<em>yourtheme</em>/modules/articles . The templates will get the extension .xt there. </p>
</div>
<div class="xar-norm xar-standard-box-padding">
   <h1><strong>Title:</strong>&nbsp;The Universality and Expressiveness of std::accumulate</h1>
<p><strong>Author:</strong>&nbsp;Martin Moene</p>
<p>
<strong>Date:</strong> 04 December 2015 09:43:44 +00:00 or Fri, 04 December 2015 09:43:44 +00:00</p>
<p><strong>Summary:</strong>&nbsp;Folding is a highly generic operation available through std::accumulate. Paul Keir goes beyond reduction, with the help of C++14â€™s polymorphic lambdas.</p>
<p><strong>Body:</strong>&nbsp;<p>Graham Huttonâ€™s 1999 monograph: <em>A tutorial on the universality and expressiveness of fold</em> [<a href="#[Hutton99]">Hutton99</a>] provides a fascinating and eminently readable analysis of an elementary reduction operator from functional programming: <em>fold</em>. Huttonâ€™s tutorial is punctuated by increasingly compelling examples, written in Haskell, of the use of <em>fold</em> to implement common list operations, including summation; concatenation; reversal; function composition; <em>left</em> folds; and concluding with the Ackermann function. The <em>fold</em> combinator is directly comparable to the C++ standard library function: <code>std::accumulate</code>. In this article, I focus on the <em>fold</em> examples from Hutton, and present equivalent generic C++ incarnations of each; making thorough use of appropriate C++14 library and language features, including polymorphic lambda functions<a href="#FN01"><sup>1</sup></a>.</p>

<p>The four-parameter <code>accumulate</code> function constructs a result from the repeated pairwise application of a given binary function, to elements supplied from both an iterator range; and a single â€œzeroâ€ value, having the type of the result. A canonical example is summation; the value returned from the call to <code>accumulate</code> in listing 1 is 10.</p>

<table class="sidebartable">
	<tr>
		<td>
			<pre class="programlisting">
int xs[]{1,2,3,4};
accumulate(cbegin(xs), cend(xs), 0, plus&lt;&gt;{});
			</pre>
		</td>
	</tr>
	<tr>
		<td class="title">Listing 1</td>
	</tr>
</table>

<p>Huttonâ€™s first four examples use <em>fold</em> to implement arithmetic and logic operations using built-in functions to specify the relevant binary operations. Similar function objects are provided by the C++ standard library within the <code>&lt;functional&gt;</code> header. The example above demonstrates the use of <code>plus&lt;&gt;</code> for <code>operator+</code>; while <code>operator*</code>, <code>operator&amp;&amp;</code>, and <code>operator||</code> correspond to <code>multiplies&lt;&gt;</code>,<code> logical_and&lt;&gt;</code>, and <code>logical_or&lt;&gt;</code> respectively. Note that C++14 conveniently defines a default template argument for such function objects; <code>std::plus&lt;&gt;</code> invokes a specialisation which infers the relevant types from its arguments.</p>

<h2>Accommodating std::accumulate</h2>

<p>A binary operator is said to be <em>associative</em> when an expression involving a sequence of its applications produces the same result, regardless of the order of evaluation. The four C++ function objects from the previous section all denote associative operations. Consider addition: both (1 +  2) + 3 and 1 + ( 2 + 3 ) produce the same result; 6. Operator precedence is irrelevant when faced with a &#8853; b &#8853; c; the question is whether to evaluate from the <em>left</em>; or from the <em>right</em>. In particular, which order does <code>accumulate</code> use? It uses a left ordering.</p>

<p>An elementary <em>non-associative</em> binary operation is <em>subtraction</em>. The call to <code>accumulate</code>
 in listing 2 would then produce a result equal to (( 0 - 1) - 2 ) - 3, i.e. - 6; evaluating from the left. In contrast, an evaluation ordered from the <em>right</em>, say 1- ( 2 - ( 3 - 0 )), produces a result of 2. Alas, the remaining examples from Hutton [<a href="#[Hutton99]">Hutton99</a>] firmly assume the fold operation evaluates from the <em>right</em>.</p>

<table class="sidebartable">
	<tr>
		<td>
			<pre class="programlisting">
vector&lt;double&gt; xs{1,2,3};
accumulate(cbegin(xs), cend(xs), 0, minus&lt;&gt;{});
			</pre>
		</td>
	</tr>
	<tr>
		<td class="title">Listing 2</td>
	</tr>
</table>

<p>Producing a result from <code>accumulate</code> equal to a <em>right fold</em> requires two interventions: we need the order of traversal across the container elements reversed; <em>and</em> for the order of the arguments given to the binary operation to be switched<a href="#FN02"><sup>2</sup></a>. Listing 3 defines such a wrapper for <code>accumulate</code>, called <code>foldr</code>. The C++14 functions <code>crbegin</code> and <code>crend</code> return <code>const</code> iterators to the <em>reverse beginning</em> and <em>reverse end</em> of the container argument <code>c</code>. Meanwhile, the <code>flip</code> function, uses <code>std::bind</code> to reverse the argument order for the binary function object; e.g. <code>flip(minus&lt;&gt;{})(0,1)</code> evaluates to 1; not - 1.</p>

<table class="sidebartable">
	<tr>
		<td>
			<pre class="programlisting">
template &lt;typename F&gt;
auto flip(const F &amp;f) { return bind(f,_2,_1); }

template &lt;typename F, typename T, typename C&gt;
T foldr(const F &amp;f, const T &amp;z, const C &amp;c) {
  return accumulate(crbegin(c), crend(c), z,
    flip(f));
}
			</pre>
		</td>
	</tr>
	<tr>
		<td class="title">Listing 3</td>
	</tr>
</table>

<p>The definition of <code>foldr</code> in listing 3 removes the need to call <code>crbegin</code>, <code>crend</code> and <code>flip</code>. It also allows a single container argument to drive the C++ <em>fold</em>; much as with C++ <em>ranges</em> [<a href="#[Niebler15]">Niebler15</a>]. This allows listings here to remain concise; while also facilitating a comparison of the syntactical differences between Haskell and C++. We can now invoke a <em>right fold</em>. Assuming `<code>C</code>` creates an arbitrary standard sequence container, with inferred value type<a href="#FN03"><sup>3</sup></a>, the call to <code>foldr</code> in listing 4 returns the integer 2.</p>

<table class="sidebartable">
	<tr>
		<td>
			<pre class="programlisting">
foldr(minus&lt;&gt;{}, 0, C(1,2,3))
			</pre>
		</td>
	</tr>
	<tr>
		<td class="title">Listing 4</td>
	</tr>
</table>

<h2>Non-reducing folds</h2>

<p>Using a <em>fold</em> to concatenate two containers first requires a small helper function, which should return a new container, by adding a single element to the front of an existing one. Haskell provides the <code>(:)</code> operator for this job. Listing 5 defines this using its traditional Lisp name: â€œconsâ€.</p>

<table class="sidebartable">
	<tr>
		<td>
			<pre class="programlisting">
auto cons = [=](auto x, auto xs) {
  decltype(xs) ys{x};
  copy(begin(xs), end(xs), back_inserter(ys));
  return ys;
};
			</pre>
		</td>
	</tr>
	<tr>
		<td class="title">Listing 5</td>
	</tr>
</table>

<p>Like <em>subtraction</em>, the <code>cons</code> function is <em>non-associative</em>; and <em>non-commutative</em>. <code>cons</code> though, expects two different argument types. Listing 6 provides <code>foldr</code> with <code>cons</code>
 as the binary function, and an empty container as the â€œzeroâ€ or starting value; to define an identity <em>fold</em>. That is, <code>id(C(1,2,3))</code> will return a container object of the same type; with the same 3 elements. Meanwhile, the genericity of C++ allows a similar invocation which only changes the container type: <code>foldr(cons, list&lt;int&gt;{}, C(1,2,3))</code>.</p>

<table class="sidebartable">
	<tr>
		<td>
			<pre class="programlisting">
auto id = [=](auto xs) {
  return foldr(cons, decltype(xs){}, xs);
};
			</pre>
		</td>
	</tr>
	<tr>
		<td class="title">Listing 6</td>
	</tr>
</table>

<p>To append one container to another, listing 7 again uses <code>cons</code> for <code>foldr</code>â€™s first argument; while providing the second, a container, as its â€œzeroâ€ value. Note that while the elements of, say, <code>append(C('a'),C('b'))</code> and <code>C('a','b')</code> are equal, so too are they equal to <code>append(C&lt;list&gt;('a'),C&lt;vector&gt;('b'))</code>; as the definition is sufficiently generic.</p>

<table class="sidebartable">
	<tr>
		<td>
			<pre class="programlisting">
auto append = [=](auto xs, auto ys) {
  return foldr(cons, ys, xs);
};
			</pre>
		</td>
	</tr>
	<tr>
		<td class="title">Listing 7</td>
	</tr>
</table>

<h2>Folding with lambda arguments</h2>

<p>The three functions<a href="#FN04"><sup>4</sup></a> of listing 8 provide each corresponding <code>foldr</code> invocation with a binary lambda function, as, like Haskell, no equivalents exist within the standard library. The <code>length</code> function returns the size of its container argument, using a lambda function with unnamed first argument. Both <code>reverse</code> and <code>map</code> return a container<a href="#FN05"><sup>5</sup></a>; with <code>map</code> utilising the closure aspect of lambda expressions to capture <code>f</code>.</p>

<table class="sidebartable">
	<tr>
		<td>
			<pre class="programlisting">
auto length = [=](auto xs){
  return foldr(
    [=](auto, auto n){ return 1+n; },
    0,
    xs);
};
auto reverse = [=](auto xs){
  return foldr(
    [=](auto y, auto ys)
      { return append(ys,decltype(xs){y}); },
    decltype(xs){},
    xs);
};
auto map = [=](auto f, auto xs){
  return foldr(
    [=](auto y, auto ys){ return cons(f(y),ys); },
    vector&lt;decltype(f(*xs.begin()))&gt;{},
    xs);
};
			</pre>
		</td>
	</tr>
	<tr>
		<td class="title">Listing 8</td>
	</tr>
</table>

<p>Tuples allow a single <em>fold</em> to perform more than one calculation. For example, listing 9 defines a function which returns both the size of a container, and the sum of its elements<a href="#FN06"><sup>6</sup></a>.</p>

<table class="sidebartable">
	<tr>
		<td>
			<pre class="programlisting">
auto sumlength = [=](auto xs){
  return foldr(
    [=](auto n, auto p){
      return make_pair(n + p.first, 1 + p.second);
    },
    make_pair(0,0),
    xs);
};
			</pre>
		</td>
	</tr>
	<tr>
		<td class="title">Listing 9</td>
	</tr>
</table>

<h2>Functions from folds</h2>

<p>The result of applying the <em>composition</em> of two functions <code>f</code> and <code>g</code> to an argument <code>x</code> can be achieved in C++ with the expression: <code>f(g(x))</code>. In Haskell an elementary binary operator, <code>(.)</code>, can also be used; accepting two functions as arguments, and returning a <em>new</em> function representing their composition. In listing 10, the <em>fold</em>â€™s binary function argument is a comparable lambda expression for composition. The result of invoking <code>compose</code> with a container of callable elements is a function object representing the chained composition of each function in sequence. The â€œzeroâ€ argument of <code>foldr</code> uses a simple lambda identity function; though notice it is wrapped by the type of the container element: an instantiation of <code>std::function</code>. Why? While the type of each lambda expression is unique, the type of each container element is the same. <code>std::function </code>provides exactly the required homogeneity; each lambda accepting and returning say an <code>int</code>, becomes simply <code>std::function&lt;int(int)&gt;</code>. The â€œzeroâ€, meanwhile, needs the same wrapper, as it provides the type of the <em>fold</em>â€™s result.</p>

<table class="sidebartable">
	<tr>
		<td>
			<pre class="programlisting">
auto compose = [=](auto fs){
  using fn_t = typename decltype(fs)::value_type;
  return foldr(
    [=](auto f, auto g)
      { return [=](auto x){ return f(g(x)); }; },
    fn_t([=](auto x){ return x; }),
    fs);
};
			</pre>
		</td>
	</tr>
	<tr>
		<td class="title">Listing 10</td>
	</tr>
</table>

<p>One of the most intriguing functions capable of definition by a <em>right fold</em>, such as our <code>foldr</code>, is a <em>left fold</em>. Listing 11 provides such a definition. As before, an identity function is required for the <em>fold</em>â€™s starting value, and again this wild lambda needs the guiding hand of <code>std::function</code>; though the type in question is calculated in a different manner. Unlike <code>compose</code>, the function object returned by <code>foldr</code> is invoked within <code>foldl</code>; upon <code>z</code>. Our journey has brought us full circle to a <em>left fold</em>, akin to <code>std::accumulate</code>; an invocation such as <code>foldl(minus&lt;&gt;{}, 0, C(1,2,3))</code> will produce -6; much as listing 2.</p>

<table class="sidebartable">
	<tr>
		<td>
			<pre class="programlisting">
auto foldl = [=](auto f, auto z, auto xs){
  using z_t  = decltype(z);
  using fn_t = std::function&lt;z_t(z_t)&gt;;
  return foldr(
    [=](auto x, auto g){
      return [=](auto a){ return g(f(a,x)); };
    },
    fn_t([=](auto x){ return x; }),xs)(z);
};
			</pre>
		</td>
	</tr>
	<tr>
		<td class="title">Listing 11</td>
	</tr>
</table>

<p>One last comment regarding <em>left</em> and <em>right</em> folds: should you ever be in the embarrassing situation of being uncertain of the handedness of your <em>fold</em> definition, the expression in listing 12 could be useful. Simply replace <code>fold</code> with either <code>foldr</code> or <code>foldl</code>; for a <code>true</code> or <code>false</code> evaluation respectively.</p>

<table class="sidebartable">
	<tr>
		<td>
			<pre class="programlisting">
fold([](auto x, auto){ return x; },
  false, C(true))
			</pre>
		</td>
	</tr>
	<tr>
		<td class="title">Listing 12</td>
	</tr>
</table>

<p>Our final fold example, and so too in [<a href="#[Hutton99]">Hutton99</a>], is Ackermannâ€™s function [<a href="#[Ackermann28]">Ackermann28</a>]. Ackermannâ€™s function is commonly cited as a recursive function which is not <em>primitive recursive</em> in a first-order programming language. John Reynolds, however, demonstrated [<a href="#[Reynolds85]">Reynolds85</a>] that the function <em>is</em> primitive recursive in a higher-order programming language. The C++ implementation in listing 13 includes similar idioms to previous examples, but is given additional treatment to avoid the use of <em>currying</em> seen in Huttonâ€™s definition. While the binary lambda function provided to the innermost <em>fold</em> in the curried original appears unary, Î» <em>y </em>&#8594; <em>g</em>, the C++ version must be uncurried: Î» <em>y</em> <em>as</em> &#8594; <em>g(as)</em>. Note too, that these Ackermann <em>folds</em> encode the traditional natural number arguments within the size of the input and output container values.</p>

<table class="sidebartable">
	<tr>
		<td>
			<pre class="programlisting">
auto ack = [=](auto xs, auto ys){
  using ys_t = decltype(ys);
  using fn_t = std::function&lt;ys_t(ys_t)&gt;;
  return [=](auto zs){
    return foldr(
      [=](auto, auto g){
        return [=](auto ws){
          return foldr(
            [=](auto, auto as){ return g(as); },
            g(ys_t{1}),
            ws
          );
        };
      },
      fn_t([=](auto bs){ return cons(1,bs); }),
      zs
    );
  }(xs)(ys);
};
			</pre>
		</td>
	</tr>
	<tr>
		<td class="title">Listing 13</td>
	</tr>
</table>

<h2>Summary</h2>

<p>C++ lambda functions, including the polymorphic variety now available in C++14, allow the generic <em>fold</em> operation supported by <code>std::accumulate</code> to extend well beyond simple reductions. While a complex <em>fold</em> can be less readable or idiomatic than the traditional form, the approach can be refined to construct and transform programs, as well as prove specific program properties; while building on established software engineering principles of reuse and abstraction.</p>

<p>The article places less emphasis on performance considerations, instead focusing on pedagogy and algorithmic aspects; while maintaining parity with the equivalent Haskell, with consistent use of <code>auto</code> for type inference.</p>

<p>C++17 will introduce <em>fold expressions</em> [<a href="#[Sutton14]">Sutton14</a>]. Here, a <em>finite</em> set of operators, will share the brevity of the <em>comma</em> in pack expansion; consider <code>*</code> versus <code>std::multiplies&lt;&gt;{}</code>. One restriction is the variadic template pack length must be known at compile-time.</p>

<h2>Appendix</h2>

<p>All examples, along with code for <code>dropWhile</code>, <code>filter</code> and other folds are available at <a href="https://bitbucket.org/pgk/accumulate">https://bitbucket.org/pgk/accumulate</a>.</p>

<h2>References</h2>

<p class="bibliomixed"><a id="[Ackermann28]"></a>[Ackermann28]  W. Ackermann. <em>Zum Hilbertschen Aufbau der reellen Zahlen</em> Mathematische Annalen, 1928.</p>

<p class="bibliomixed"><a id="[Bird88]"></a>[Bird88]  R. Bird and P. Wadler.<em> Introduction to Functional Programming</em> Prentice Hall, 1988.</p>

<p class="bibliomixed"><a id="[Gill93]"></a>[Gill93]  A. Gill, J. Launchbury and S.P. Jones. <em>A Short Cut to Deforestation</em>. ACM Press, 1993.</p>

<p class="bibliomixed"><a id="[Hutton99]"></a>[Hutton99]  G. Hutton. <em>A tutorial on the universality and expressiveness of fold</em> Cambridge University Press, 1999.</p>

<p class="bibliomixed"><a id="[Niebler15]"></a>[Niebler15]  E. Niebler. <em>Working Draft, C++ extensions for Range</em>s. The C++ Standards Committee, 2015.</p>

<p class="bibliomixed"><a id="[Reynolds85]"></a>[Reynolds85]  J.C. Reynolds. <em>Three approaches to type structure</em> Springer-Verlag, 1985.</p>

<p class="bibliomixed"><a id="[Sutton14]"></a>[Sutton14]  A. Sutton and R. Smith. <em>Folding expressions</em>. The C++ Standards Committee, 2014.</p>

<p class="footnotes"></p>

<ol>
	<li><a id="FN01"></a>Note that most of these fold examples can also be found in [<a href="#[Bird88]">Bird88</a>] or [<a href="#[Gill93]">Gill93</a>].</li>

	<li><a id="FN02"></a>This is described as the third duality theorem in [<a href="#[Bird88]">Bird88</a>, p68].</li>

	<li><a id="FN03"></a>Assume a <code>vector</code> default; i.e. <code>C(1,2)</code> becomes: <code>C&lt;vector,int&gt;(1,2)</code>.</li>

	<li><a id="FN04"></a>A definition of <code>filter</code> from [<a href="#[Hutton99]">Hutton99</a>] appears in the appendix.</li>

	<li><a id="FN05"></a>Note that <code>map</code> returns a <code>vector</code> object here solely for brevity.</li>

	<li><a id="FN06"></a>A similar tuple-based definition of <code>dropWhile</code> appears in the appendix.</li>
</ol>
</p>
<p><strong>Notes:</strong>&nbsp;</p>
<p><em>More fields may be available via dynamicdata ..</em></p>
</div>
</channel>
</rss>
