<titledata-rh="true">Vague postconditions and proving correctness of algorithms | mf</title><metadata-rh="true"name="viewport"content="width=device-width,initial-scale=1"><metadata-rh="true"name="twitter:card"content="summary_large_image"><metadata-rh="true"property="og:url"content="https://blog.mfocko.xyz/algorithms/algorithms-correctness/postcondition-ambiguity/"><metadata-rh="true"property="og:locale"content="en"><metadata-rh="true"name="docusaurus_locale"content="en"><metadata-rh="true"name="docsearch:language"content="en"><metadata-rh="true"name="docusaurus_version"content="current"><metadata-rh="true"name="docusaurus_tag"content="docs-algorithms-current"><metadata-rh="true"name="docsearch:version"content="current"><metadata-rh="true"name="docsearch:docusaurus_tag"content="docs-algorithms-current"><metadata-rh="true"property="og:title"content="Vague postconditions and proving correctness of algorithms | mf"><metadata-rh="true"name="description"content="Debuggingandtestingwithprecisepostconditions.
<p><ahref="/files/algorithms/algorithms-correctness/postcondition-ambiguity/test_sort.py"target="_blank"rel="noopener noreferrer">Source code</a> used later on.</p>
<h2class="anchor anchorWithStickyNavbar_LWe7"id="implementation-of-select-sort-from-the-exercises">Implementation of select sort from the exercises<ahref="#implementation-of-select-sort-from-the-exercises"class="hash-link"aria-label="Direct link to Implementation of select sort from the exercises"title="Direct link to Implementation of select sort from the exercises"></a></h2>
<p>To implement select sort from the exercises and make it as easy to read as possible, I have implemented maximum function that returns index of the biggest element from the first <spanclass="katex"><spanclass="katex-mathml"><mathxmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mi>n</mi></mrow><annotationencoding="application/x-tex">n</annotation></semantics></math></span><spanclass="katex-html"aria-hidden="true"><spanclass="base"><spanclass="strut"style="height:0.4306em"></span><spanclass="mord mathnormal">n</span></span></span></span> elements.</p>
<p>For the sake of time and memory complexity, I am also using <code>itertools.islice</code>, which makes a slice, but does not copy the elements into the memory like normal slice does.</p>
<p>There is also a <code>check_loop_invariant</code> function that will be described later.</p>
<h2class="anchor anchorWithStickyNavbar_LWe7"id="discussed-preconditions-loop-invariants-and-postconditions">Discussed preconditions, loop invariants and postconditions<ahref="#discussed-preconditions-loop-invariants-and-postconditions"class="hash-link"aria-label="Direct link to Discussed preconditions, loop invariants and postconditions"title="Direct link to Discussed preconditions, loop invariants and postconditions"></a></h2>
<p>You can safely replace <code>A</code> with <code>arr</code> or array for list.</p>
<h3class="anchor anchorWithStickyNavbar_LWe7"id="precondition">Precondition<ahref="#precondition"class="hash-link"aria-label="Direct link to Precondition"title="Direct link to Precondition"></a></h3>
<p>As a precondition we have established that <code>A</code> represents an array of values and <spanclass="katex"><spanclass="katex-mathml"><mathxmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mi>n</mi></mrow><annotationencoding="application/x-tex">n</annotation></semantics></math></span><spanclass="katex-html"aria-hidden="true"><spanclass="base"><spanclass="strut"style="height:0.4306em"></span><spanclass="mord mathnormal">n</span></span></span></span> is length of the <code>A</code>.</p>
<h3class="anchor anchorWithStickyNavbar_LWe7"id="loop-invariant">Loop invariant<ahref="#loop-invariant"class="hash-link"aria-label="Direct link to Loop invariant"title="Direct link to Loop invariant"></a></h3>
<p>As for loop invariant we have established that we require two properties:</p>
<ol>
<li><code>A[i + 1 : n]</code> is sorted</li>
<li>all elements of <code>A[i + 1 : n]</code> are bigger or equal to the other elements</li>
</ol>
<p>This invariant is later defined as <code>check_loop_invariant</code> function. It is checked before the first iteration and after each iteration.</p>
<h3class="anchor anchorWithStickyNavbar_LWe7"id="postcondition">Postcondition<ahref="#postcondition"class="hash-link"aria-label="Direct link to Postcondition"title="Direct link to Postcondition"></a></h3>
<p>For the postcondition the first suggestion was that <code>A</code> must be sorted. And later we have added that <code>A'</code> must be a permutation of <code>A</code>.</p>
<blockquote>
<p>However at the end of the session question arose if it is really required to state in the postcondition that <code>A'</code> is a permutation.</p>
</blockquote>
<h2class="anchor anchorWithStickyNavbar_LWe7"id="so-is-the-permutation-really-required">So is the permutation really required?<ahref="#so-is-the-permutation-really-required"class="hash-link"aria-label="Direct link to So is the permutation really required?"title="Direct link to So is the permutation really required?"></a></h2>
<p>As I have said it is better to have postconditions explicit and do not expect anything that is not stated explicitly, e.g. <em>name suggests it</em>. In reality we could consider it as a smaller mistake (but it has consequences).</p>
<p>On the other hand explicit postconditions can be used to our advantage <strong>and also</strong> help our proof of correctness.</p>
<p>Consequences:</p>
<ol>
<li>
<p>Property-based testing</p>
<p>If we have explicit postconditions we can use them to define properties of the output from our algorithms. That way we can use property-based testing, which does not depend on specific inputs and expected outputs, but rather on randomly generated input and checking if the output conforms to our expectations (the postconditions are fulfilled).</p>
</li>
<li>
<p>Proof of correctness</p>
<p>If we can prove that algorithm is correct even for algorithm that <strong>is not</strong> correct, we have a problem. That proof has no value and is useless.</p>
</li>
</ol>
<p>For the sake of showcasing the power of postconditions I will introduce "select sort" that is not correct, but will comply with both the loop invariant and our vague postcondition and thus pass the tests.</p>
<h2class="anchor anchorWithStickyNavbar_LWe7"id="implementation-of-the-broken-select-sort">Implementation of the broken select sort<ahref="#implementation-of-the-broken-select-sort"class="hash-link"aria-label="Direct link to Implementation of the broken select sort"title="Direct link to Implementation of the broken select sort"></a></h2>
<p>To make sure this thing passes everything, but our explicit postcondition with permutation will <em>blow it up</em>, I have designed this "select sort" as follows:</p>
<ol>
<li>If I get empty list, there is nothing to do.</li>
<li>I find maximum in the array.</li>
<li>For each index from the end, I will assign <code>maximum + index</code>.
This will ensure that even if the maximum in the original array was the first element, I will always satisfy that 2nd part of the loop invariant.</li>
<divclass="theme-admonition theme-admonition-tip admonition_xJq3 alert alert--success"><divclass="admonitionHeading_Gvgb"><spanclass="admonitionIcon_Rf37"><svgviewBox="0 0 12 16"><pathfill-rule="evenodd"d="M6.5 0C3.48 0 1 2.19 1 5c0 .92.55 2.25 1 3 1.34 2.25 1.78 2.78 2 4v1h5v-1c.22-1.22.66-1.75 2-4 .45-.75 1-2.08 1-3 0-2.81-2.48-5-5.5-5zm3.64 7.48c-.25.44-.47.8-.67 1.11-.86 1.41-1.25 2.06-1.45 3.23-.02.05-.02.11-.02.17H5c0-.06 0-.13-.02-.17-.2-1.17-.59-1.83-1.45-3.23-.2-.31-.42-.67-.67-1.11C2.44 6.78 2 5.65 2 5c0-2.2 2.02-4 4.5-4 1.22 0 2.36.42 3.22 1.19C10.55 2.94 11 3.94 11 5c0 .66-.44 1.78-.86 2.48zM4 14h5c-.23 1.14-1.3 2-2.5 2s-2.27-.86-2.5-2z"></path></svg></span>tip</div><divclass="admonitionContent_BuS1"><p>There is also an easier way to break this, I leave that as an exercise ;)</p></div></div>
<h2class="anchor anchorWithStickyNavbar_LWe7"id="property-based-tests-for-our-sorts">Property-based tests for our sorts<ahref="#property-based-tests-for-our-sorts"class="hash-link"aria-label="Direct link to Property-based tests for our sorts"title="Direct link to Property-based tests for our sorts"></a></h2>
<p>Since we have talked a lot about proofs at the seminar, I would like to demonstrate it on the testing of the sorts. In the following text I will cover implementation of the loop invariant and both postconditions we have talked about and then test our sorts using them.</p>
<h3class="anchor anchorWithStickyNavbar_LWe7"id="loop-invariant-1">Loop invariant<ahref="#loop-invariant-1"class="hash-link"aria-label="Direct link to Loop invariant"title="Direct link to Loop invariant"></a></h3>
<p>To check loop invariant I have implemented this function:</p>
<p>First part checks if the "ending" of the array is sorted.</p>
<p>In second part I have used a <em>dirty trick</em> of taking just the first element that is the smallest and compared the rest of the elements to it. Why is it enough? I leave it as an exercise ;)</p>
<h3class="anchor anchorWithStickyNavbar_LWe7"id="postconditions">Postcondition(s)<ahref="#postconditions"class="hash-link"aria-label="Direct link to Postcondition(s)"title="Direct link to Postcondition(s)"></a></h3>
<p>I have defined both the vague and explicit postconditions:</p>
<h3class="anchor anchorWithStickyNavbar_LWe7"id="putting-it-together">Putting it together<ahref="#putting-it-together"class="hash-link"aria-label="Direct link to Putting it together"title="Direct link to Putting it together"></a></h3>
<p>Now that we have everything implement, we can move on to the implementation of the tests:</p>
<p>We pass to the sorting function <strong>copy</strong> of the numbers we got, this ensures that once we are checking the more strict postcondition, we can gather the necessary information even after sorting the list in-situ, i.e. we can check if the <code>result</code> is really a <code>permutation</code> of the <code>numbers</code> even though the sorting functions has modified the passed in list.</p>
</li>
</ol>
<divclass="theme-admonition theme-admonition-caution admonition_xJq3 alert alert--warning"><divclass="admonitionHeading_Gvgb"><spanclass="admonitionIcon_Rf37"><svgviewBox="0 0 16 16"><pathfill-rule="evenodd"d="M8.893 1.5c-.183-.31-.52-.5-.887-.5s-.703.19-.886.5L.138 13.499a.98.98 0 0 0 0 1.001c.193.31.53.501.886.501h13.964c.367 0 .704-.19.877-.5a1.03 1.03 0 0 0 .01-1.002L8.893 1.5zm.133 11.497H6.987v-2.003h2.039v2.003zm0-3.004H6.987V5.987h2.039v4.006z"></path></svg></span>caution</div><divclass="admonitionContent_BuS1"><p>Now we get to the more complicated part and it is the <em>decorators</em>.</p></div></div>
<olstart="3">
<li>
<p>1st <code>parametrize</code> from the bottom</p>
<p>This tells pytest, that we want to pass the values from the list to the parameter <code>sorting_function</code>. In other words, this lets us use the same test function for both the correct and incorrect select sort.</p>
</li>
<li>
<p>2nd <code>parametrize</code> from the bottom is similar, but works with the postcondition.
The reason why they are separated is pretty simple, this way they act like cartesian product: for each sorting function we also use each postcondition.</p>
</li>
<li>
<p><code>@settings</code> raises the count of tests that hypothesis runs (from default of 100(?)).</p>
</li>
<li>
<p><code>@given(lists(integers()))</code>
This means hypothesis is randomly creating lists of integers and passing them to the function, which has only one parameter left and that is <code>numbers</code>.</p>
</li>
</ol>
<h3class="anchor anchorWithStickyNavbar_LWe7"id="lets-run-the-tests">Let's run the tests!<ahref="#lets-run-the-tests"class="hash-link"aria-label="Direct link to Let's run the tests!"title="Direct link to Let's run the tests!"></a></h3>
<p>In case you want to experiment locally, you should install <code>pytest</code> and <code>hypothesis</code> from the PyPI.</p>
<p>We can clearly see that our broken select sort has passed the <em>vague postcondition</em>, but the explicit one was not satisfied.</p>
<h2class="anchor anchorWithStickyNavbar_LWe7"id="summary">Summary<ahref="#summary"class="hash-link"aria-label="Direct link to Summary"title="Direct link to Summary"></a></h2>
<p>For proving the correctness of the algorithm it is better to be explicit than prove that algorithm is correct even though it is not. Being explicit also allows you to test smaller <em>chunks</em> of code better.</p></div><footerclass="theme-doc-footer docusaurus-mt-lg"><divclass="theme-doc-footer-tags-row row margin-bottom--sm"><divclass="col"><b>Tags:</b><ulclass="tags_jXut padding--none margin-left--sm"><liclass="tag_QGVx"><aclass="tag_zVej tagRegular_sFm0"href="/algorithms/tags/python/">python</a></li><liclass="tag_QGVx"><aclass="tag_zVej tagRegular_sFm0"href="/algorithms/tags/testing/">testing</a></li><liclass="tag_QGVx"><aclass="tag_zVej tagRegular_sFm0"href="/algorithms/tags/postconditions/">postconditions</a></li><liclass="tag_QGVx"><aclass="tag_zVej tagRegular_sFm0"href="/algorithms/tags/sorting/">sorting</a></li></ul></div></div><divclass="theme-doc-footer-edit-meta-row row"><divclass="col"><ahref="https://github.com/mfocko/blog/tree/main/algorithms/02-algorithms-correctness/2021-03-18-postcondition-ambiguity.md"target="_blank"rel="noopener noreferrer"class="theme-edit-this-page"><svgfill="currentColor"height="20"width="20"viewBox="0 0 40 40"class="iconEdit_Z9Sw"aria-hidden="true"><g><pathd="m34.5 11.7l-3 3.1-6.3-6.3 3.1-3q0.5-0.5 1.2-0.5t1.1 0.5l3.9 3.9q0.5 0.4 0.5 1.1t-0.5 1.2z m-29.5 17.1l18.4-18.5 6.3 6.3-18.4 18.4h-6.3v-6.2z"></path></g></svg>Edit this page</a></div><divclass="col lastUpdated_vwxv"><spanclass="theme-last-updated">Last updated<!----> on <b><timedatetime="2021-03-18T00:00:00.000Z">Mar 18, 2021</time></b></span></div></div></footer></article><navclass="pagination-nav docusaurus-mt-lg"aria-label="Docs pages"><aclass="pagination-nav__link pagination-nav__link--prev"href="/algorithms/category/algorithms-and-correctness/"><divclass="pagination-nav__sublabel">Previous</div><divclass="pagination-nav__label">Algorithms and Correctness</div></a><aclass="pagination-nav__link pagination-nav__link--next"href="/algorithms/category/asymptotic-notation-and-time-complexity/"><divclass="pagination-nav__sublabel">Next</div><divclass="pagination-nav__label">Asymptotic Notation and Time Complexity</div></a></nav></div></div><divclass="col col--3"><divclass="tableOfContents_bqdL thin-scrollbar theme-doc-toc-desktop"><ulclass="table-of-contents table-of-contents__left-border"><li><ahref="#introduction"class="table-of-contents__link toc-highlight">Introduction</a></li><li><ahref="#implementation-of-select-sort-from-the-exercises"class="table-of-contents__link toc-highlight">Implementation of select sort from the exercises</a></li><li><ahref="#discussed-preconditions-loop-invariants-and-postconditions"class="table-of-contents__link toc-highlight">Discussed preconditions, loop invariants and postconditions</a><ul><li><ahref="#precondition"class="table-of-contents__link toc-highlight">Precondition</a></li><li><ahref="#loop-invariant"class="table-of-contents__link toc-highlight">Loop invariant</a></li><li><ahref="#postcondition"class="table-of-contents__link toc-highlight">Postcondition</a></li></ul></li><li><ahref="#so-is-the-permutation-really-required"class="table-of-contents__link toc-highlight">So is the permutation really required?</a></li><li><ahref="#implementation-of-the-broken-select-sort"class="table-of-contents__link toc-highlight">Implementation of the broken select sort</a></li><li><ahref="#property-based-tests-for-our-sorts"class="table-of-contents__link toc-highlight">Property-based tests for our sorts</a><ul><li><ahref="#loop-invariant-1"class="table-of-contents__link toc-highlight">Loop invariant</a></li><li><ahref="#postconditions"class="table-of-contents__link toc-highlight">Postcondition(s)</a></li><li><ahref="#putting-it-together"class="table-of-contents__link toc-highlight">Putting it together</a></li><li><ahref="#lets-run-the-tests"class="table-of-contents__link toc-highlight">Let's run the tests!</a></li></ul></li><li><ahref="#summary"class="table-of-contents__link toc-highlight">Summary</a></li></ul></div></div><
