Can PROC TABULATE do everything PROC REPORT can and more?

[VX_Xc]

PROC TABULATE makes more sense to me than PROC REPORT. I know there are many ways to achieve the same outcome but I just want to master one way. Preferably I would choose one procedure that strictly dominates another.

So can;

      PROC TABULATE do at least as much as PROC REPORT ?

      DATA step do at least as much as PROC IMPORT?  (In the context where we have a complex raw data, such as html)

      SAS Enterprise guide interface do at least as much as what basic SAS interface can do?

[art297]

I'm not familiar enough with either proc tabulate or proc report to answer your first question.

As for whether the datastep can do as much as proc import, take a look at: http://torsas.ca/attachments/File/09162011/Copy_and_paste_almost_anything.pdf

It is a presentation that I'll be doing at SGF2012 and, in my very biased opinion, there are many things that you can do with a datastep regarding importing data, that can not be done using proc import.  However, in all fairness, proc import combined with some of the SAS/Access products, can do some things that would be quite difficult to accomplish with a datastep.

I am not an EG user, as I don't like the facts that one can't run SAS/AF on it and I've simply been using the basic interface for far too long to adapt to something new without quickly seeing benefits from doing so.

Regardless, my recommendation would be to learn as much as you can, rather than trying to become an expert on just one method.  There are things you can do with one or another proc or method that are either easier to accomplish or simply accomplishable, that are either more difficult or impossible with another proc or method.

My experience with SAS is that the more you know, the better off you will be.  Both for solving problems, learning or discovering new applications, and career path advancements.

[VX_Xc]

awesome!

[Reeza]

What about PROC SQL?

I'm sorry, but this seems like a strange question.

      PROC TABULATE do at least as much as PROC REPORT ?

          Not in my opinion, they do different things.

      DATA step do at least as much as PROC IMPORT?  (In the context where we have a complex raw data, such as html)

          Datastep does more, but less automated. I typically use proc import, take the code and start from there for CSV files for example. The Data step also comprises a huge number of different topics, such as merges, arrays. In combination with the libname statement you can import a bunch of different things easily as well.

      SAS Enterprise guide interface do at least as much as what basic SAS interface can do?

          No. SAS EG does not allow DDE and its slower. If you want to learn to code use base sas. If you want to point and click use EG.  At some point, you'll still need to code IMO.

If you want to pick one thing to master, master the datastep and proc report.

Between those two you can get everything you need.

Then when you get tired of typing code you can learn the other procs such as report/tabulate/means/SQL that will save you time.

[VX_Xc]

Isn't SQL for managing tables? relational data? SQL would be good once raw data is transformed to database (table), yes you are right SQL is a must-learn procedure. SQL is kinda chunky (I might be wrong) as it plays with columns and rows rather than individual cells.

For PROC TABULATE and PROC REPORT, what I meant was that use PROC TABULATE to make the desired report form then use simple PROC REPORT to report, rather than using PROC REPORT to make desired report form and report. So the focus is on making the desired layout or format of the report. Still PROC REPORT better?

thanks

[Reeza]

I typicall use Proc Report only to display/format my data and create the datasets prior, usually using proc means or freq.

Depending on what you're doing I find that Means and Freq will get me 90% of what I need, sometimes Proc Tabulate will get you there.

Proc SQL does some things that will take multiple steps in SAS, ie adding a column in with the overall mean or group mean, SQL can do it in one 'programming' step. As you've stated its when you want column processing rather than row by row processing. There's times when either comes in convenient.

I think Art's right though, you need to learn more about everything rather than about one thing.

proc sql;

     create table want as

     select *, avg(weight) as avg_weight

from sashelp.class

group by sex;

quit;

[ballardw]

My take on the TABULATE vs REPORT question is:

Report lets you add calculated columns (within limits) and control of summary breaks.

Tabulate does a better job of nesting both row and columns.

Regardless, there are times that I make the summary values I want and use Tabulate to control table layouts.

[Cynthia_sas · Accepted solution]

Hi:

  I want to respond to your question about whether "PROC TABULATE (can) do at least as much as PROC REPORT?"

  The answer is yes...and...no. It's the old apples and oranges problem. Yes, they're both fruit. No, they don't taste the same, they're not the same color, you eat/use them in different ways, they have different vitamins, etc, etc. Can oranges do at least as much as apples? Well, I'm not sure I'd really want to try the equivalent of applesauce made with oranges. And I'm pretty sure that apple zest wouldn't taste the same as orange zest in my baking.

  REPORT and TABULATE are both SAS reporting procedures. They have different syntaxes and different purposes. TABULATE is based on the old TPL (table producing language) and it creates highly nested summary tables using a very elegant syntax. REPORT can create detail reports (where 1 report row represents 1 observation), summary reports (where 1 report row represents the summary of a group of observations) and cross-tabular reports. REPORT syntax is more verbose than TABULATE, especially when you get into using COMPUTE blocks.

    I frequently joke that TABULATE is the premium slicer, dicer and table maker of SAS. It has 3 possible dimensions that it can build, PAGE, ROW, COLUMN, and is VERY efficient at building cross-tabular summary tables. But let's say that I have a dataset of employees spread over 4 departments in 6 countries. TABULATE could give me a summary report of statistics in a crosstabular form, but if I wanted to calculate the amount needed for bonuses, I could not use TABULATE to calculate the needed bonus amount for each department or country. I'd have to make a work dataset with a BONUS variable and then make another pass through the data to  run TABULATE; on the other hand, PROC REPORT has a COMPUTE block, where you can calculate a new item using a COMPUTE block inside the procedure.

  A quick comparison of features is shown in the table below. It is not comprehensive, but hits the highlights.

Feature                 TABULATE     REPORT (Technique)

----------------------- ----------   -----------------------------------

Detail Reports            NO          YES (1 report row = 1 obs)

Summary Reports          YES          YES (1 report row = summary of obs)

CrossTabular Reports     YES          YES (ACROSS Usage)

SubTotals between Groups YES          YES

Grand Totals             YES          YES

Custom Percent Keywords  YES           NO (but can calculate)

KURTOSIS, SKEWNESS stats YES           NO

STYLE= overrides         YES          YES

Compute New Items         NO          YES (Compute Block)

Customize Break Lines     NO          YES (Compute Block)

Add Extra Break Lines     NO          YES (Compute Block)

Trafficlighting          YES (1 way)  YES (2 ways)

Multi-Label Formats      YES           NO

  A few years ago, at the SAS Global Forum/SUGI meetings, there was a series of papers, spread over several years, where some long-time users debated the pros and cons of REPORT vs TABULATE or just talked about REPORT/TABULATE usage. Here are links to some of those and other useful papers. They are fun and informative reading.

http://www2.sas.com/proceedings/sugi27/p133-27.pdf

http://www2.sas.com/proceedings/sugi28/133-28.pdf

http://www2.sas.com/proceedings/sugi29/122-29.pdf

http://www2.sas.com/proceedings/sugi29/242-29.pdf

http://www2.sas.com/proceedings/forum2008/171-2008.pdf

http://www2.sas.com/proceedings/sugi28/071-28.pdf

  You say that you only want to learn or master one of these procedures. I think it is worth the investment of your time to learn both procedures. Would you have a toolbox with only hammers and no wrenches?

cynthia

[VX_Xc]

:smileysilly: I want a Sonic Screwdriver! 

Thank you very much. It really answered my question. Guess I would have to read the whole book on both PROC TABULATE, PROC REPORT, and SQL among other things...:smileycry: