Is there a full size image so I can read the labels and find my submission? :)
It wasn't intended for that purpose, but stand by ... EDIT: OK, I've uploaded a larger version where the labels are readable, but I've had to change the layout so the nodes don't overlap. The lengths of the edges are now not always realted to the distance, although it's approximate. http://www.solipsys.co.uk/Writings/x.dot.png Note: Yours might still not be on it, as yours might be one of the outliers. You can email…
Interviewing programmers: Analysis taster (work in progress)
11–20 of 34 posts
Re: Interviewing programmers: Analysis taster (work in progress)
#12How are you computing your similarity measure between routines?
I'm replacing recognised keywords with their initial letter, other symbols with "x", removing all spacing, retaining all punctuation, and then using a Levenshtein distance. For example, this: void condense_by_removing( char *z_terminated , char char_to_remove ) { char *p_read; for (p_read = z_terminated;*p_read;p_read++) if (*p_read != char_to_remove) *z_terminated++ = *p_read; *z_terminated = '\0'; } gets mapped to…
Next question: How are you picking (x,y) coordinates for the graph? You've explained how you determine the connectivity, but the positioning is a bit unclear -- edges with the same score often have quite different lengths.
Re: Interviewing programmers: Analysis taster (work in progress)
#13Earlier quoted context omitted.
I'm replacing recognised keywords with their initial letter, other symbols with "x", removing all spacing, retaining all punctuation, and then using a Levenshtein distance. For example, this: void condense_by_removing( char *z_terminated , char char_to_remove ) { char *p_read; for (p_read = z_terminated;*p_read;p_read++) if (*p_read != char_to_remove) *z_terminated++ = *p_read; *z_terminated = '\0'; } gets mapped to…
Did you consider tokenizing the inputs and comparing those? Based on Levenshtein distance alone you're basically saying that "++" and "!=" are twice as important as "=" or "*", which doesn't seem right to me. Next question: How are you picking (x,y) coordinates for the graph? You've explained how you determine the connectivity, but the positioning is a bit unclear -- edges with the same score often have quite differe…
I'm using neato for the layout. Graph layout is hard, and in some cases unsolved. I'm using this for rough visualisation, then I'll write code to find true clusters.
Re: Interviewing programmers: Analysis taster (work in progress)
#14Earlier quoted context omitted.
Did you consider tokenizing the inputs and comparing those? Based on Levenshtein distance alone you're basically saying that "++" and "!=" are twice as important as "=" or "*", which doesn't seem right to me. Next question: How are you picking (x,y) coordinates for the graph? You've explained how you determine the connectivity, but the positioning is a bit unclear -- edges with the same score often have quite differe…
I did consider tokenising the inputs, and probably will. The only reason not to have done so yet was that this was a no-brainer in terms of getting something working just to see if produced something useful. I'm using neato for the layout. Graph layout is hard, and in some cases unsolved. I'm using this for rough visualisation, then I'll write code to find true clusters.
Ok, so you're using all the pairwise distances for computing the layout, even though you're only showing the tree edges on the graph?
Re: Interviewing programmers: Analysis taster (work in progress)
#15Re: Interviewing programmers: Analysis taster (work in progress)
#16Earlier quoted context omitted.
I did consider tokenising the inputs, and probably will. The only reason not to have done so yet was that this was a no-brainer in terms of getting something working just to see if produced something useful. I'm using neato for the layout. Graph layout is hard, and in some cases unsolved. I'm using this for rough visualisation, then I'll write code to find true clusters.
I'm using neato for the layout. Ok, so you're using all the pairwise distances for computing the layout, even though you're only showing the tree edges on the graph?
Put every node in its own component. Find the shortest edge that joins two components, emit that edge, merge the components. Lather, Rinse, Repeat.
Also, braces penalise you twice. Code that is identical except that one includes, the other excludes, a pair of braces are distance 2 apart. There is some reason to say they should have distance 0. Fully parenthesised code, and then ignore the close (or open) brace would fix that.
Re: Interviewing programmers: Analysis taster (work in progress)
#17Wow, I was surprised to see mine at the edge of the graph on its own. I wonder is that a good or bad thing..! :-)
Re: Interviewing programmers: Analysis taster (work in progress)
#18Wow, I was surprised to see mine at the edge of the graph on its own. I wonder is that a good or bad thing..! :-)