Talk:Closest-pair problem: Difference between revisions

(→‎Comment on Algorithms Given: link to "Critique of pseudocode explanations of the Closest Pair Algorithm")
Line 20:
==Comment on Algorithms Given==
[http://paddy3118.blogspot.com/2009/05/critique-of-pseudocode-explanations-of_12.html Critique of pseudocode explanations of the Closest Pair Algorithm] --[[User:Paddy3118|Paddy3118]] 05:39, 12 May 2009 (UTC)
: The new code (id est, as it is now) '''works'''. The code that had problems was the previous one (in your blog you report the most recent version, that, as said, works). Maybe I've chosen a not so communicative pseudolanguage... but I thought we were familiar with such notation like "ceil" or "floor", or the meaning of {elements...} (which resembles a set; here we intend an ordered, indexable, "set"); and it seemed to me intuitive that a P(i)<sub>x</sub> refers to the point i-th, x coordinate, even though it would be better to write (P(i))<sub>x</sub> maybe. I would have used P<sub>i,x</sub> but at the end I preferred the P(index) form in general; I could have written P<sub>x</sub>(index) instead... maybe it is clearer? Using the last reference, I've corrected the last part of the pseudocode (and in fact the while loop is fundamentally the one you can see there). The syntax I am dissatisfied with is the last I've added to explicitly take care of the points' coordinates, e.g. <code>(closest, closestPair)</code>... but it is the faster modification I was able to think to add that without too many efforts.
: Language apart, the algorithm now works (at least, Smalltalk, C and Perl implementations, based on that, works).
: Anyone interested in writing better pseudocode (even in changing the current "language" keeping the same "code") is welcome of course! --[[User:ShinTakezou|ShinTakezou]] 09:04, 12 May 2009 (UTC)