Talk:Hough transform: Difference between revisions
→Can I get some pseudo-code...and possibly an amen: A little clarification on multiple counts.
(→Can I get some pseudo-code...and possibly an amen: A little clarification on multiple counts.) |
|||
Line 3:
: Not really. What's important at the surface is that the inputs match and the outputs match. How different examples achieve this will vary by how the problem best maps to each language. MATLAB's implementation ''should'' differ, because MATLAB looks at mathematical problems differently from TCL or C. Though, yes, we definitely need more examples. --[[User:Short Circuit|Michael Mol]] 18:35, 9 August 2010 (UTC)
::But, I thought the point of Rosetta Code was to be able to compare implementations of a common task between languages. I understand that this definition doesn't invalidate your response, but I don't see the point of ''not'' specifying a pseudo-code to implement. It would be much easier for: not only novices trying to figure out how to do something using the solutions as examples, but also developers who are confused about how to implement this particular algorithm, if there were pseudo-code to refer to. I say this especially since my implementation requires an "edge-detected" version of the image as the input (a boolean array where the array member at the index of an "edge" pixel is true). And, from what I can tell, the TCL and C solutions don't. So, I am not exactly sure what is going on in those algorithms which allows them to produce valid output. This is why pseudo-code is important.--[[User:Cferri|Chris Ferri]]
::: The problem is that pseudocode makes assumptions about implementation. I can write pseudocode that says "do this, then do this, then do this", but that tends to assume an imperative programming paradigm. It may be possible to have a universal pseudocode, but I doubt it. [http://www.reddit.com/r/programming/comments/5zypl/ask_reddit_is_therecan_there_be_a_standard_for/ This] is what I got the last time I poked around for one. That doesn't leave me hopeful. I've seen what happens when someone creates procedural pseudocode as part of a task description, assuming that it was part and parcel to what the task was supposed to accomplish, and then I've had to deal with reconciling the task's description against its intent and the languages which it accidentally made things structurally difficult for.
::: As I understand it, Hough depends a great deal on averaging values, which is going to be very difficult if you're only allowing yourself 1 bit of precision. You might try expanding that 1 bit to a larger range (i.e. an integer 0 for false, 255 for true, or a float type with 0 for false, 1 for true) before doing your operations, and then compressing back down to 1 bit prior to output. I'd make suggestions about how to choose range size, but I think that depends a great deal on your use case.) --[[User:Short Circuit|Michael Mol]] 19:40, 9 August 2010 (UTC)
==PNG Image==
| |||