Doug's MATLAB Video Tutorials

June 25th, 2010

By Doug Hull

Doug first used MATLAB in 1994, could not figure it out until he got some help in 1995. He is now dedicated to making sure that no one else wastes a year of their life not knowing MATLAB like he did.

17:22 UTC | Posted in Format: Video, Level: Basic | Permalink | 12 Comments »

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 “using temporary variables”

1. Peter replied on June 25th, 2010 at 19:00 UTC :
   

   Wouldn’t it be better to add this line add the end of the code to make it really temporary?

   clear hMainGui lengthColormap colorMapToUse
   

   Don’t you “spam” your workspace this way?

2. dhull replied on June 25th, 2010 at 19:28 UTC :
   

   Some people might say that, but I am not worried for a few reasons:

   * I generally make short functions, these variables will be out of scope quickly anyways.

   * I use good variable names, so these variables will be understandable

   * I am not worried about ‘memory issues’ from variables. If I were, I could clean these out in the appropriate way.

   -Thanks for the comment,
   Doug

3. Matt Fig replied on June 25th, 2010 at 21:37 UTC :
   

   While I don’t usually like the deeply nested function calls either, I also am averse to filling up the workspace with unnecessary variables. In cases like this, I often prefer to use comments to document the code and just reassign the variable. For example, instead of this:

   hMainGui = getappdata(0,'hMainGui');
   lengthColormap = getappdata(hMainGui,'scaling');
   colorMapToUse = bone(lengthColormap);
   cmap_data = colormap(colorMapToUse);
   

   I might do this:

   cmap_data = getappdata(0,'hMainGui'); % Handle to GUI.
   cmap_data = getappdata(cmap_data,'scaling');  % Stored Scaling from GUI.
   cmap_data = bone(cmap_data);  % Create new colormap from BONE.
   cmap_data = colormap(cmap_data); % Set figure's colormap.
   

   Thus I try to be an avid code commenter.

4. Oleg replied on June 26th, 2010 at 10:47 UTC :
   

   I do like to align code as Doug does (not always though):

   a    = somefcn(input1, input2);
   useA = useit  (     a,     10);
   

   I find it especially useful when writing T-SQL queries.

   Oleg

5. Oleg replied on June 26th, 2010 at 10:49 UTC :
   

   Also (about alignment, which helps to mantain code), using Matt’s code I would write it like:

   cmap_data = getappdata(        0,'hMainGui'); % Handle to GUI.
   cmap_data = getappdata(cmap_data,'scaling');  % Stored Scaling from GUI.
   cmap_data = bone    (cmap_data);              % Create new colormap from BONE.
   cmap_data = colormap(cmap_data);              % Set figure's colormap.
   

6. dhull replied on June 28th, 2010 at 17:49 UTC :
   

   @Oleg and @Matt

   I like the combination in #5. I have never gotten into the reuse a variable to build it incrementally code pattern, but I think that it works just fine. The trade off is less variable names at the cost of access to the intermediate states.

   If you were to try and debug this, you would have to step through to get the intermediate states. Mine you would not. However when it is done, I have littered the workspace.

   Doug

7. Peter replied on June 29th, 2010 at 08:41 UTC :
   

   Doug, I totally get your point, when you put it in a function. Then I agree with you.

   The rest: Thank you for the inspiration. I myself, even though coding for quite a whilie, am pretty new to MATLAB and glad to see a few ideas and hints.

   Peter

8. Ryan Gray replied on June 29th, 2010 at 18:59 UTC :
   

   I don’t get the obsession with littering the workspace. Clearly, this is an example, and the code could be in any context, but most often, it would/should be in a function, limiting the scope and lifetime of these variables. To me, the bigger problem of “spamming the workspace” are scripts that assume they are not going to overwrite a variable I’m already using or that assume their plot command will make a new figure and not trash another one.

   I’d be interested in a comparison of the two methods from a memory usage point of view to know when or if I might want to use the nested form.

9. EBS replied on July 7th, 2010 at 18:49 UTC :
   

   @Oleg and @Matt

   One small point to note with the ‘incremental overwrite’ approach you demonstrate is that it has the potential to prevent the JIT compiler system from performing the fullest degree of optimizations that it is capable of.

   From my understanding (which was current as of a couple years ago), the more ‘static’ you keep your code the better the JIT can optimize it – for instance this means not changing the data type/size/complexity/etc of a variable during it’s lifetime.

10. dhull replied on July 7th, 2010 at 18:50 UTC :
    

    @EBS

    Good point, I had not considered that.

    Doug

11. Matt Fig replied on July 7th, 2010 at 18:56 UTC :
    

    @EBS,

    Interesting point, but I have never observed the effect. I guess this would most likely be noticed in a FOR loop? I will keep an eye out for this in the future!

12. Jai Pillai replied on July 23rd, 2010 at 02:04 UTC :
    

    Good point Doug, but I feel the style should depend on the application. This idea definitely make the code more readable, but leads to more memory requirements. Consider for example cases when the output of functions are huge matrices taking lots of space. It may not be a good idea to use temporary variables like this which are not cleared. A better option may be just to use a single line and write proper comments.

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.