Fred Wolfe wrote:
Our group recently had an experience with SAS vs. Stata that maybe
illuminating. We collected, managed and analyzed data from a clinical trial
using interfaces that we in part designed that made use of scanning
software (Teleform), SQL and Stata. At the end of the study the sponsor
unexpectedly asked us for 102 specially formatted tables. The format of the
Hmm. It's not standard practice for corporate sponsors to unexpectedly ask
for this kind of thing at the end of a study. I wonder what they're up to.
The convention is to agree upon "shell tables" well in advance of the end of
the study. Even earlier, before you prepared your bid, when the corporate
sponsor laid out the specifications for the job, it was supposed let you
know that these kinds of specially formatted tables will be expected from
you.
tables was complex, but was based on SAS generated tables that were
standard for the sponsor. The tables had multiple columns, statistics
placed at special points within the tables, group comparisons and
interspersed headings. Although we could easily produce individual
components of the tables, the completed tables as requested was something
we could not do but that they did easily in SAS. When I say we could not do
it, I don't mean it was impossible. But at best it would have required very
complex Stata programming. The amount of work required on our part would
have been enormous and we refused to do it. Instead, we provided the
SAS does have a couple of procedures that are extensively used for what is
called "reporting," among them PROC REPORT and PROC TABULATE. Despite
these, those custom tables weren't necessarily so easy for the corporate
sponsor to do, not even in SAS. Corporate sponsors spend a lot of time and
money producing the SAS code for their custom tables. Most of their SAS
programmers on staff don't do statistical analysis, but rather do this sort
of thing. Corporations have house styles for these tables and listings, and
they hold as property the SAS code written by their employees to produce
them, as do contracting consultancies that serve the industry by doing this
sort of thing.
corporate sponsor with SAS files using -fdasave- so that they could make
the tables they wished.
Stata has problem with output formatting and reports. Although this is
rarely limiting for manuscripts and short reports, a substantial number of
postings to this list (and programs) are concerned with production of
formatted output. In the world I live in, I have to share output with
colleagues and journals using the most commonly used formats: MS Word (or
equivalent) and Excel (or equivalent). I need attractive, non-proportional
fonts, flexible page formatting and simple control of labels and titles.
Easy to request and very hard to implement, I'm sure. But such abilities
would make Stata an even greater package than it is now.
I'd second that. It's much more important than a display format for time or
date-time. There is a lot that you can do with SMCL, but you rapidly reach
its limits. I've tried -log2html- and other avenues, but these are also not
going to get you there without a lot of development. There's little doubt
that SAS's Output Delivery System (ODS) was just for customers like you who
in turn have customers demanding work to be delivered in the file formats of
the industry-standard office software packages or document-processing
software packages that they use, or in which the government regulatory
agencies in turn demand of them.
Joseph Coveney
*
* For searches and help try:
* http://www.stata.com/support/faqs/res/findit.html
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
