Using macro loops for simulation

2

Last week I wrote an article in which I pointed out that many SAS programmers write a simulation in SAS by writing a macro loop. This approach is extremely inefficient, so I presented a more efficient technique.

Not only is the macro loop approach slow, but there are other undesirable side effects that can occur. For example, in the example code that I presented, I used the OPTION NONOTES statement and made the comment that the option "prevents the SAS log from overflowing." Someone asked me to explain what I meant by that comment.

Recall that each iteration of the macro loop called the DATA step, PROC MEANS, and PROC APPEND. By default, SAS writes a NOTE to the SAS log when a procedure completes. For example, for each iteration of the macro loop, the SAS log displays the following NOTES:

NOTE: The data set WORK.TEMP has 10 observations and 2 variables.
NOTE: DATA statement used (Total process time):
      real time           0.01 seconds
      cpu time            0.00 seconds

NOTE: There were 10 observations read from the data set WORK.TEMP.
NOTE: The data set WORK.OUT has 1 observations and 3 variables.
NOTE: PROCEDURE MEANS used (Total process time):
      real time           0.03 seconds
      cpu time            0.00 seconds

NOTE: Appending WORK.OUT to WORK.OUTSTATS.
NOTE: BASE data set does not exist. DATA file is being copied to BASE file.
NOTE: There were 1 observations read from the data set WORK.OUT.
NOTE: The data set WORK.OUTSTATS has 1 observations and 3 variables.
NOTE: PROCEDURE APPEND used (Total process time):
      real time           0.01 seconds
      cpu time            0.01 seconds

These notes require time to print and they are unnecessary for the simulation, so I suppress the notes by using OPTIONS NONOTES.

If you do not suppress the notes and you run the program in the SAS windowing environment (DMS mode), you might see the Log WINDOW FULL dialog box which states "Window is full and must be cleared." This is not only annoying, but it prevents your simulation from running to completion!

You can use the NONOTES option to eliminate this problem, and use the NOPRINT option on the PROC MEANS statement to prevent a similar problem from occurring to the output window.

An expert SAS user recently remarked to me:

Some days I just wish the macro language didn't exist... a lot of code would look a lot better if people had to code it through SAS/IML, SQL, etc., without using macro loops.

I agree. The macro language can be a useful tool, but avoid using macro loops for simulations.

Share

About Author

Rick Wicklin

Distinguished Researcher in Computational Statistics

Rick Wicklin, PhD, is a distinguished researcher in computational statistics at SAS and is a principal developer of SAS/IML software. His areas of expertise include computational statistics, simulation, statistical graphics, and modern methods in statistical data analysis. Rick is author of the books Statistical Programming with SAS/IML Software and Simulating Data with SAS.

2 Comments

  1. Quentin McMullen on

    Thanks for the blog, RIck.

    I agree with your point that macro looping is a bad way to approach simulations.

    But I think your quote from the expert SAS user treads too close to maligning the macro language (which is frequently maligned).

    It is possible to write bad / inefficient SAS code (e.g. do a simulation by copy-and-paste 10000 data steps). The macro language generates SAS code. It is possible to use the macro language to generate bad/inefficient SAS code (as in your simulation example). I would venture to say that you can also write bad IML code, and bad SQL code.

    One thing that often leads to bad macro language code is that people sometimes learn the macro language before they have learned enough about the SAS language to decide when the macro language is useful. Macro loops are very useful in many situations.

    • Rick Wicklin

      Thank you for the thoughtful response. I agree with you: every language can be misused and abused. That doesn't mean that the language is bad. It means that we programmers have to learn enough to know when and how to use the various tools in our arsenal.

Leave A Reply

Back to Top