How to calculate average by variable and with conditions

[KachiM]

@PaigeMiller 

I respect your views. But I differ from you.

"Especially for beginners, PROC MEANS is much easier (and it is a much more tested and therefore less risky) than any data step code to calculate the mean. "

I believe that the OP will choose a solution that is convenient to him. He might also be interested to learn other solutions. Besides, there are several others who wish to to learn Data Step Programming in the Community. I further believe that adding and dividing is not more risky for SAS Programmers.

Kind regards

DATASP

[PaigeMiller]

I have no objections to people learning data steps and deciding what code to use that is best for them. In fact, every SAS programmer needs to learn how to do things in data steps, because data steps can perform a wide variety of extremely useful tasks, many of which cannot be performed in any other way in SAS.

But when I advise people on what to do, I will advise what I said, that using a SAS PROC to perform a task (if such a PROC exists) is what I advise.

---

@KachiM wrote:

I further believe that adding and dividing is not more risky for SAS Programmers.

---

And as we have seen in this thread, data is presented with missing values, and people have written data step code that doesn't properly account for the missing values and produces the wrong answer ... in other words, it is more risky.

[Reeza]

I've actually caught this mistake a few times across code reviews - which is why we also introduced a coding standard similar to what Paige has recommeded.

We also prioritize programming time over run time. Run time doesn't cost me money, programming time does. You need to optimize the right metrics, which varies from situation to situation.

[hashman]

@Reeza;

 >We also prioritize programming time over run time. Run time doesn't cost me money, programming time does.<

Hope you realize that priorities like these depend on the nature of "we", that of the task, specific platform, data volume, how much time you have to run your programs, whether they can be run repeatedly based on the latter, etc. Run time may not cost you money. However, elsewhere it not only can cost a lot of money but makes the very difference between a job having been done on time and not done at all. An example:

Suppose that a programmer was tasked with piecing together an ETL process that starts at 21:00 and must run overnight, as the analysts enterprise-wide absolutely must have their updated data by 7:00. Suppose further that he spent a remarkably short time to program it correctly from the standpoint of the output data, except it has a few wrinkles, such as any of the following:

• takes 15 hours to run
• bombs due to insufficient resources after running for 8 hours
• gobbles up so much system resources that it causes other critical processes running in parallel to abend    
• other side effects, too numerous to mention here 

Would the client for whom this kind of work is done will be elated to hear from this programmer that he has saved them money by prioritizing programming time over run time? I suppose it's a rhetorical question...

Kind regards

Paul D.  

[Reeza]

@hashman of course, that's why I said 'we' and didn't generalize that statement. But I do have control over my team and can make those decisions accordingly. I'm in the camp of developer time is more important. IME, if you have more time, you also have time to improve your skill set and keep up with what the best methods are so you don't often run into time issues anyways because you're aware of the most efficient methods to develop solutions. Everything is relative. 

[hashman]

@Reeza:

>I'm in the camp of developer time is more important<

I'm in the camp of the notion that coding with efficiency/performance in mind hardly takes more time than coding without giving it a hoot, especially since once the habit of coding efficiently has been developed, it becomes one's second nature. OTOH, it cannot be developed by folks who routinely code never thinking of efficiency because they don't have to (whether it's due to their data volume, the nature of their tasks, or other factors). As to using the freed up time to "keep up with what the best methods are", the latter can be internalized only by using them practically day in day out. I agree, though, that none of this is important in specific segments of certain industries.

>Everything is relative.< 

Well, this statement is absolute ;).

Kind regards

Paul D.