<h2 dir="auto">PC details</h2>
<ul dir="auto">
<li>scipy==0.12.0</li>
<li><code class="notranslate">Linux dana 3.8.0-30-generic #44-Ubuntu SMP Thu Aug 22 20:52:24 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux</code></li>
<li>Intel(R) Xeon(R) CPU E5-1650 0 @ 3.20GHz</li>
<li>Linked against Intel MKL (though issue replicated on a machine linked against Atlas)</li>
</ul>
<h2 dir="auto">Issue</h2>
<p dir="auto">With this <a href="https://gist.github.com/patricksnape/6793845">mesh</a> I am seeing inconsistent results from <code class="notranslate">scipy.spatial.Delaunay</code>. Assuming that the mesh has been loaded using <code class="notranslate">numpy.loadtxt</code> into a variable called <code class="notranslate">points</code>, I duplicate the issue as follows:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="from scipy.spatial import Delaunay
scipy_t = Delaunay(points).simplices"><pre class="notranslate"><code class="notranslate">from scipy.spatial import Delaunay
scipy_t = Delaunay(points).simplices
</code></pre></div>
<p dir="auto">I have some code that checks the consistency of a triangulation (in terms of ordering) and the above code generates an inconsistent triangulation.</p>
<h2 dir="auto">Ground Truth</h2>
<p dir="auto">In order to sanity check I compared the triangulation against the one created by <code class="notranslate">pyhull</code>. This is created using the same point set as follows:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="from pyhull.delaunay import DelaunayTri
pyhull_t = np.asarray(DelaunayTri(points).vertices)"><pre class="notranslate"><code class="notranslate">from pyhull.delaunay import DelaunayTri
pyhull_t = np.asarray(DelaunayTri(points).vertices)
</code></pre></div>
<p dir="auto">I've also generated the triangulation in Matlab using both <code class="notranslate">delaunay</code> and <code class="notranslate">delaunayn</code> and it yields results identical to <code class="notranslate">pyhull_t</code>. My triangulation consistency verifier also confirms that the <code class="notranslate">pyhull_t</code> triangulation is correct.</p>
<h2 dir="auto">Options</h2>
<p dir="auto">In order to try and ensure that <code class="notranslate">scipy.spatial.Delaunay</code> is applying the same algorithm as <code class="notranslate">pyhull</code>, I dove in to their source code. There I noticed that they always set the following flags:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="i Qt Qc Qbb"><pre class="notranslate"><code class="notranslate">i Qt Qc Qbb
</code></pre></div>
<p dir="auto">but running with those flags as follows:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="from scipy.spatial import Delaunay
scipy_t = Delaunay(points, qhull_options='Qbb Qc').simplices"><pre class="notranslate"><code class="notranslate">from scipy.spatial import Delaunay
scipy_t = Delaunay(points, qhull_options='Qbb Qc').simplices
</code></pre></div>
<p dir="auto">still does not yield correct results.</p>
<h2 dir="auto">Example output</h2>
<p dir="auto">An example of the triangulation I am seeing using the flags <code class="notranslate">Qbb Qc</code>:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="print scipy_t

[[16549 35521 21080]
 [58451 78938 91348]
 [38031 32638 33401]
 ..., 
 [47968 47967 48281]
 [47968 47656 47969]
 [47968 47655 47656]]

print pyhull_t

[[35521 16549 21080]
 [78938 58451 91348]
 [32638 38031 33401]
 ..., 
 [47968 47967 48281]
 [47656 47968 47969]
 [47655 47968 47656]]"><pre class="notranslate"><code class="notranslate">print scipy_t

[[16549 35521 21080]
 [58451 78938 91348]
 [38031 32638 33401]
 ..., 
 [47968 47967 48281]
 [47968 47656 47969]
 [47968 47655 47656]]

print pyhull_t

[[35521 16549 21080]
 [78938 58451 91348]
 [32638 38031 33401]
 ..., 
 [47968 47967 48281]
 [47656 47968 47969]
 [47655 47968 47656]]
</code></pre></div>
<p dir="auto">where we can see that the same indices are being generated, but the first two are sometimes swapped.</p>
<p dir="auto"><em>Original ticket <a href="http://projects.scipy.org/scipy/ticket/642" rel="nofollow">http://projects.scipy.org/scipy/ticket/642</a> on 2008-04-15 by trac user AchimGaedke, assigned to unknown.</em></p>
<p dir="auto">Hello!</p>
<p dir="auto">I use scipy.optimize.leastsq to adopt paramters of a model to measured data. Each evaluation of that model costs 1.5 h of computation time. Unfortunately I can not specify a gradient function.</p>
<p dir="auto">While observing the approximation process I found that the first 3 runs were always with the same parameters. First I thought, the parameter variation for gradient approximation is too tiny for a simple print command. Later I found out, that these three runs were independent of the number of fit parameters.</p>
<p dir="auto">A closer look to the code reveals the reason (svn dir trunk/scipy/optimize):</p>
<p dir="auto">1st call is to check with python code wether the function is valid</p>
<p dir="auto">line 265 of minpack.py</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="m = check_func(func,x0,args,n)[0]"><pre class="notranslate"><code class="notranslate">m = check_func(func,x0,args,n)[0]
</code></pre></div>
<p dir="auto">2nd call is to get the right amount of memory for paramters.</p>
<p dir="auto">line 449 of _ _ minpack.h</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="ap_fvec = (PyArrayObject *)call_python_function(fcn, n, x, extra_args, 1, minpack_error);"><pre class="notranslate"><code class="notranslate">ap_fvec = (PyArrayObject *)call_python_function(fcn, n, x, extra_args, 1, minpack_error);
</code></pre></div>
<p dir="auto">3rd call is from inside the fortran algorithm (the essential one!)</p>
<p dir="auto">Unfortunately that behaviour is not described and I would eagerly demand to avoid the superficial calls to the function.</p>