File Exchange Pick of the Week

March 31st, 2008

The first puzzler [click here] was a big success with 33 comments added as I write this today. I wanted to go over some highlights from the comments and code that people put out there for critique.

First off, I want to say that several people posted code that solved the problem. I do not want to get into the specifics of any person’s code, that was done in the comments section [click here]. I do want to use this as reason to lay out some coding philosophy.

• Many people did not fully test their solutions and often failed on edge cases.

It is difficult to test any algorithm completely, especially when the answer is not known, but how do you know if your answer is right if you do not know the answer at all? I tested all submitted code, and often just running a bunch of random test cases lead to “solutions” that did not make sense. In this puzzle, some solutions came back with answers like “Remove rows 3 5 5″. This is a mistake since you can not remove the same row twice. In other cases, the returned matrix had an all zero column, so the job was not yet finished.

Running a lot of test cases really helps

• The code was ‘too clever’

I know we have some very clever programmers here, and that part of the fun is to find a clever, terse way of solving code in the least number of lines. We have dedicated contests to just that challenge in the past. [click here]

When I am coding ‘for real’, I know that someone else is likely to need to read and understand the code. That someone else might be me in a few weeks once I have forgotten everything about the code! I like to have descriptive variable names, and easy to understand algorithms.

I would rather have ten lines of code that is easy to understand rather than five lines that will take me ten minutes to understand. The simpler and more intuitive the algorithm, the less likely that edge cases will fail.

Sometimes you want to have that ‘clever’ code for reasons of efficiency of memory or speed of execution. My thought is get the code working once, then profile it to see where the bottle necks are. Fix those slow areas, sacrificing readability for speed of execution only if needed. There is no need to make ’speculative improvements’ to speed code up when it is not needed.

• Solve the problem by hand first

Some people misunderstood the problem. I very often will solve problems by hand on a white board so I am sure I understand the problem and the solution I intend to use. It is possible to work out this entire problem by hand.

Many problems that MATLAB users are working on can not be done by hand at all. However, engineering is the art of breaking complex problems down into pieces that are solvable. This problem originally came to me from a MATLAB user, and I highly suspect it is just one small part of a much larger problem he was solving. Once this is solved and tested, he can encapsulate this into a MATLAB function and not worry about it again!

10:05 UTC | Posted in Puzzler | Permalink |

You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.

One Response to “Wrap up on Puzzler: Removing columns and rows from binary matrices”

1. Krish replied on February 22nd, 2009 at 10:43 UTC :
   

   Thanks Doug. It is wonderful and very useful for my work

   Krish

Leave a Reply

<pre class="code">
a = magic(3);
sum(a)
</pre>

These postings are the author's and don't necessarily represent the opinions of The MathWorks.