<p><br>
On Dec 11, 2011 10:26 AM, "Tony Yu" <<a href="mailto:tsyu80@gmail.com">tsyu80@gmail.com</a>> wrote:<br>
><br>
> On Sun, Dec 11, 2011 at 12:46 PM, Zachary Pincus <<a href="mailto:zachary.pincus@yale.edu">zachary.pincus@yale.edu</a>> wrote:<br>
>><br>
>> Stéfan may be able to amplify, but IIRC he has some other code to put into measure that should more clearly differentiate the two sub-modules. Right now it's correct that both the content in 'measure' (marching-squares contour-finding) and in 'graph' (Dijkstra's algorithm on a lattice) are both about tracing paths through pixel arrays, albeit in very different contexts. So it might not be bad to re-organize.<br>

>><br>
>> But contour-finding is not a graph operation, so such a re-org should be more than putting that code in the 'graph' package.<br>
><br>
> Oh, I meant the other way around: getting the minimum-cost path seems like something you measure in an image. (Sort of.) That was under the assumption that nothing else was planned for the graph package.</p>
<p>I was thinking of putting things like graph cuts in there, but placing an emphasis on the way a function is implemented rather than what it does may be the wrong approach. E.g., we don't put image filters in the Fourier submodule. What can go in there is maybe graph handling utilities for other functions. </p>

<p>So, where would a good home for shortest path be? We'll keep a link to the original location for backward compatibility too. </p>
<p>Cheers<br>
Stéfan <br><br></p>