File Exchange Pick of the Week

December 13th, 2006

Cleaner code in MATLAB part one of series

I am guilty of making some pretty horrible code from time to time, especially when I think no one else is looking. I wanted to take the next few videos to show how you can go from code that is hard to read and maintain to code you proudly sign your name to.

This week we will define a simple problem, show some awful code that happens to work, and then make the code better by breaking down a logic check to smaller, easier to understand statements.

PS. It was actually difficult to write code this bad. I ended up writing the code well and messing it up because I could not write such awful code that actually worked properly!

9:47 pm | Posted in Video | 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.

12 Responses to “Cleaner code in MATLAB part one of series”

1. Terry Brennan replied on December 14th, 2006 at 3:05 pm :
   

   Doug - I have found that 2-d geometry problems are best solved in complex coordinates

   zc = xc+i*yc;
   z = x+i*y;
   e = z-zc;

   if abs(e)>1 & abs(real(e))

2. Doug replied on December 14th, 2006 at 3:15 pm :
   

   Terry,

   Thanks for the comment.

   As you can see, this code was far from efficient so that I would have something to improve upon. I was not planning on converting the code to imaginary coordinates, but for a more realistic problem, that is an good idea.

   It looks like the code is cleaner your way. I was planning on focusing on the benefits of good variable names, breaking down logic checks and the like. The actual problem domain is not important, so I was not going to make domain specific code changes.

   Thanks,
   Doug

3. Nick Cheilakos replied on December 16th, 2006 at 11:37 pm :
   

   We have a mess code but is efficient an we have a clean code but loses in speed. Which code we prefer?

   In your example which code is faster? The first or the clean version?

   ps: I know, that if we have clean code we can do debugging very easy.But i dont know if sometimes we earn something else

4. DanK replied on December 18th, 2006 at 1:14 pm :
   

   I have the same question as Nick. My solution has generally been to write the complicated code, and then provide the “simple” code as a comment, so that I don’t have to give up speed. I also wonder about the merits of cluttering up the variable name space… Is this yet another case, “there is never really one size that fits all”?

5. Doug replied on December 20th, 2006 at 9:29 am :
   

   Dan and Nick,

   There are times when cryptic code code does give faster results. The profiler, as outlined in an earlier video helps to diagnose that. However, I think that sloppy code, like the kind in my original file, is rarely faster, simply harder to understand. Even if the clearer code were slower, the ease of understanding would outweigh most small performance gains in most situations.

   That being said, I think it is worth adding another video at the end to compare the two. My instinct is that their will be negligible difference in speed.

   Doug

6. DanK replied on December 20th, 2006 at 12:13 pm :
   

   Doug,
   I’m thinking mainly of the extra time required in memory allocation and handling, when you are processing large volumes of data. What I am really unsure of here, is what memory usage MatLab makes for intermediate steps in complex computations. Is it allocating the memory just the same as it would if we assigned each intermediate value to a variable and then clearing that allocation at the end of the computation? If so then I would imagine you really don’t lose much time. For reference I’m thinking about processing done on arrays that are, for example 20,000×25, which can definitely chew up a bunch of memory.

   Dan

7. Loren Shure replied on December 20th, 2006 at 1:23 pm :
   

   Dan-

   With respect to temporary expressions, MATLAB cleans up or reuses the memory as it goes. So, for example, assuming all variables and sizes are suitable for this expression

   (a+b)+(c+d)

   We end up with 2 intermediate temporaries (not 3). The temporaries start off being for the expressions in parentheses. And when those subexpressions are added, MATLAB is smart enough to know that it can overwrite one of the temps with the final value. So at most here, you have only one extra temporary).

   There are some extra considerations that MATLAB does for expressions like

   A = A + 1;

   when this is inside a function M-file. I will be writing about that soon in one of my upcoming blog articles.

   –Loren

8. DanK replied on December 21st, 2006 at 9:14 am :
   

   Loren,
   Thanks for the answer. From that response it does sound like the complicated, ugly, code probably does save a lot of memory allocation, at least when you are dealing with large sets of data.

   As a side note, it would be interesting if profiler had a mechanism which allowed one to know what part of an expression was using time, rather than just line by line. I’m guessing that that is a far from simple modification, however.
   Dan

9. sebaa replied on June 9th, 2007 at 7:26 am :
   

   dear sir
   do you have a NSGA-II coded in matlab with binary code

   thanks

10. Doug replied on June 11th, 2007 at 7:28 am :
    

    File exchange to the rescue:

    http://www.mathworks.com/matlabcentral/fileexchange/loadFile.do?objectId=10429&objectType=File

11. Nasser replied on December 5th, 2007 at 6:14 am :
    

    Thank indeed for ur help but I’m looking for NSGA-II with binary coded (representation) the one that have u sent if real vector

12. Nasser replied on December 5th, 2007 at 7:05 am :
    

    Hi sebaa,

    Have u found a NSGA-II coded in matlab with binary code

Leave a Reply

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