RE: st: Stata 12: wish list

[Thomas Speidel <thomas@tmbx.com>]

Thanks Nick for your input on this topic.  I agree it is a very comlex  
problem with different expectations from different users.   
Nonetheless, when I look at graphs in Stata, there is hardly anything  
I don't like, enough possibilities to please anyone, and in my mind  
there is virtually no limit to the kind of graph one can produce.

One day I would love to see the same thick manual for tables (and I  
promise I will not complain).  I can alreay visualize one example:
[T] table export -- Export current table
                   implied
        suffix     option         output format
        ---------------------------------------------------------------------
        .tex       as(tex)        LaTeX
        .rtf       as(rtf)        RTF (Rich Text Format)
        .xml       as(xml)        Extensible Markup Language
        .pdf       as(pdf)        PDF
        .epf       as(epf)        an Evil Proprietary Format :-)
        ---------------------------------------------------------------------

P.S. Not to discriminate against other leading software, we need an  
acronym for SPSS too!

--
Thomas Speidel

Quoting Nick Cox <n.j.cox@durham.ac.uk> Tue  2 Nov 07:31:58 2010:

> I think that is a good summary of a widely held view. I have no axe  
> to grind here as I am not a provider in the main territory that  
> Thomas has in mind, but on behalf of fellow user-programmers I  
> suggest that the descriptor "ad hoc" does not quite fit the situation.
>
> Of the programs implied here, and that I know about, I'd say that  
> they all have a clear vision of what they want to do which has been  
> maintained throughout their development. It can seem ad hoc if you  
> want to do something else, but that is a different matter. As I've  
> already remarked in this thread, user-programmers tend to write  
> programs for themselves, with no guarantee of meeting anyone else's  
> needs.
>
> The overall problem here is describable in two words "better tables"  
> and lots of users want to second that. But some want more unified  
> syntax for tables within Stata, some want more detailed control,  
> some want greater support for export to their own favourite foreign  
> programs, standard or otherwise, and some want two or three of  
> those. All understandable enough, but don't complain if this all  
> turns into a [T] manual several hundred pages long to meet not only  
> your reasonable requests, but most other people's too!
>
> Emphasis here varies depending on where you come from. Some people  
> seem routinely to be producing tens or hundreds of tables in rigid  
> formats full of coefficients, standard errors and P-values and those  
> awful stars. Do people actually read them too?
>
> Nick
> n.j.cox@durham.ac.uk
>
> P.S. On a key question of intellectual priority, I lay claim to  
> "Some Alternative Software", as indeed could anyone else who came up  
> with it earlier or later.  But (with thanks to Maarten for the  
> compliment) the joke about there being so many standards to choose  
> from is certainly not mine. Andrew Tanenbaum got there much earlier.
>
> Thomas Speidel
>
> While I understand the intricacies of such a task, for me too this has
> been on the wish list for some time.  Judging from the number of
> user-written programs, the presentations at user group meetings and
> conferences and how Some Alternative Sofwtare (don't remember who came
> up with this acronym) fares in this area, I suspect the folks at Stata
> are taking notice.  I am not sure how far up this topic is in the
> priority list.
>
> One common response I hear is that solutions exists in the form of
> user written programs.  There is a large number of great work (Ian
> Watson, John Gallup, Michael Lokshin, Ben Jann, Roger Newson to name a
> few authors).  But these tend to be ad-hoc solutions:  some only
> handle a certain type of data, some will display p-values but no
> confidence intervals, etc etc. This in my view has the side effect of
> forcing the user to either write his or her program, or produce the
> tables from scratch in Excel/OpenOffice/Latex.
>
> Making more estimates available after estimation and more results
> stored in locals in general could perhaps be a good starting point.
> Eventually, I would love to see more automation in this area from Stata.
>
> Richard Ohrvall
>
> > I do not know if requests for features in the coming version of Stata
> > is of any use, but since it seems as if the Stata people are reading
> > this list and they seem like nice people, I take my chance.
> >
> > I would really like a better support for creating tables in the next
> > version of Stata. By this I mean an output of tables that is easily
> > imported into Word or any other word processor. I would also like to
> > see a bit more flexibility in the table commands. To me it is a bit
> > surprising that you e.g. can't control the number of decimals in the
> > output of -tab-. This is very annoying when you want to see a
> > proportion with a specific number of decimals. All other major
> > statistical programs seem to be ahead of Stata in these aspects. Yes,
> > I know that there are user-written programs that do these things, but
> > these seem like basic functions that should be included in the
> > program. One solution could be an optional output window (like the
> > graph window), so that those who want to keep the present design and
> > output could do so.
>
> *
> *   For searches and help try:
> *   http://www.stata.com/help.cgi?search
> *   http://www.stata.com/support/statalist/faq
> *   http://www.ats.ucla.edu/stat/stata/



--
Thomas Speidel


*
*   For searches and help try:
*   http://www.stata.com/help.cgi?search
*   http://www.stata.com/support/statalist/faq
*   http://www.ats.ucla.edu/stat/stata/