<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 2082: Misleading complexity requirements in &lt;algorithm&gt;</title>
<meta property="og:title" content="Issue 2082: Misleading complexity requirements in &lt;algorithm&gt;">
<meta property="og:description" content="C++ library issue. Status: NAD">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue2082.html">
<meta property="og:type" content="website">
<meta property="og:image" content="http://cplusplus.github.io/LWG/images/cpp_logo.png">
<meta property="og:image:alt" content="C++ logo">
<style>
  p {text-align:justify}
  li {text-align:justify}
  pre code.backtick::before { content: "`" }
  pre code.backtick::after { content: "`" }
  blockquote.note
  {
    background-color:#E0E0E0;
    padding-left: 15px;
    padding-right: 15px;
    padding-top: 1px;
    padding-bottom: 1px;
  }
  ins {background-color:#A0FFA0}
  del {background-color:#FFA0A0}
  table.issues-index { border: 1px solid; border-collapse: collapse; }
  table.issues-index th { text-align: center; padding: 4px; border: 1px solid; }
  table.issues-index td { padding: 4px; border: 1px solid; }
  table.issues-index td:nth-child(1) { text-align: right; }
  table.issues-index td:nth-child(2) { text-align: left; }
  table.issues-index td:nth-child(3) { text-align: left; }
  table.issues-index td:nth-child(4) { text-align: left; }
  table.issues-index td:nth-child(5) { text-align: center; }
  table.issues-index td:nth-child(6) { text-align: center; }
  table.issues-index td:nth-child(7) { text-align: left; }
  table.issues-index td:nth-child(5) span.no-pr { color: red; }
  @media (prefers-color-scheme: dark) {
     html {
        color: #ddd;
        background-color: black;
     }
     ins {
        background-color: #225522
     }
     del {
        background-color: #662222
     }
     a {
        color: #6af
     }
     a:visited {
        color: #6af
     }
     blockquote.note
     {
        background-color: rgba(255, 255, 255, .10)
     }
  }
</style>
</head>
<body>
<hr>
<p><em>This page is a snapshot from the LWG issues list, see the <a href="lwg-active.html">Library Active Issues List</a> for more information and the meaning of <a href="lwg-active.html#NAD">NAD</a> status.</em></p>
<h3 id="2082"><a href="lwg-closed.html#2082">2082</a>. Misleading complexity requirements in <code>&lt;algorithm&gt;</code></h3>
<p><b>Section:</b> 26 <a href="https://wg21.link/algorithms">[algorithms]</a> <b>Status:</b> <a href="lwg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Nicolai Josuttis <b>Opened:</b> 2011-09-02 <b>Last modified:</b> 2016-01-28</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View other</b> <a href="lwg-index-open.html#algorithms">active issues</a> in [algorithms].</p>
<p><b>View all other</b> <a href="lwg-index.html#algorithms">issues</a> in [algorithms].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>

<p>
The <code>partition_point()</code> algorithm is specified with:
</p>
<blockquote><p>
<i>Complexity</i>: <i>O(log(last - first))</i> applications of <code>pred</code>.
</p></blockquote>
<p>
While this is correct, it gives the impression that this is a logarithmic algorithm.
But unless random access iterators are used it is not logarithmic because for advancing 
the iterator we have last-first steps, which means that the complexity becomes linear here.
<p/>
Shouldn't we clarify the complexity here to something like:
</p>
<blockquote><p>
<i>Complexity</i>: logarithmic for random-access iterators and linear otherwise
            (in any case <i>O(log(last - first)</i>) applications of <code>pred</code>).
</p></blockquote>
<p>
Or should we even require <i>O(log(last - first)</i> for random-access iterators only because 
for other iterators just iterating over all elements, while calling <code>pred</code> for each element, 
might often be faster.
</p>

<p>
Daniel Kr&uuml;gler:
</p>
<blockquote><p>
I agree that especially this description is a bit misleading. I'm not
convinced that this is a real defect, because the whole bunch of
templates within <code>&lt;algorithm&gt;</code> document the complexity solely of
<em>applications*</em> of predicates, assignment, or swaps, but never the
complexity of traversal operations (e.g. increment or iterator
equality tests). This means, the standard is consistent for this
function template, even though it could say a bit more.
<p/>
I would like to see a wording improvement, but I would rather think that
the complexity of the predicate should be mentioned first (as in other
algorithms) and that a non-normative note could be added for
specifically this algorithm to point out that this does not imply
a logarithmic traversal complexity. The note could give more details,
by explicity pointing out the linear traversal complexity for
non-random-Access iterators.
</p></blockquote>
<p>
Howard Hinnant:
</p>
<blockquote><p>
If we are going to make such improvements, they should be made across the 
board in <code>&lt;algorithm&gt;</code>, not to just <code>partition_point</code>.  
For example all 4 algorithms in 26.8.4 <a href="https://wg21.link/alg.binary.search">[alg.binary.search]</a> have the 
same issue, and have since C++98.
<p/>
<code>stable_partition</code> and <code>inplace_merge</code> should be inspected as well.
<p/>
Perhaps a new paragraph in 26.1 <a href="https://wg21.link/algorithms.general">[algorithms.general]</a>, similar to 
p12 would be a better place to address this issue.
</p></blockquote>

<p><i>[2012, Kona]</i></p>

<p>
Move to NAD.
</p>
<p>
There was some concern that the issue, if it were to be addressed, is much larger than
the couple of algorithms called out here, and applies across the whole library.  There
is no interest in looking at this or similar issues without a paper addressing the whole
library.  In fairness to anyone considering writing such a paper, it should be noted
that there was not much interest in such a paper in the group, although no strong opposition
either.
</p>



<p id="res-2082"><b>Proposed resolution:</b></p>





</body>
</html>
