[daniel klein]

I would really wish on Stata 17, Stata graphic files (*.gph) could be created so they are backward compatible, or at least give the option to save them so older versions of Stata can access them.

Same goes for .ster-files.

[Sergiy Radyakin]

Stata graph *.gph live graphs are literally running Stata commands when opened, so if the command is absent in the earlier version that graph can't be built.
Not sure about the asis version of the *.gph files.

[FernandoRios]

Thanks Sergy,
That is what I thought about gph. I imagine, then that it "stores" both the commands and the data required to make the graph (not only the vectorized pixels).
However, I just did a small experiment, plotting a scatter graph on Stata 16, and trying to open in Stata 14 and I get:

. graph use "C:\Users\Fernando\Desktop\Graph.gph"
file C:\Users\Fernando\Desktop\Graph.gph is a new format that this version of Stata
does not know how to read
r(610);

So there is something else behind gph format.
ALso, and based on what you mention, It would be useful to have access to the code that creates the graph, from the graph file itself.
This, assuming that the code is the wrapper (say "scatter y x").

I do share daniel klein views on also making *.ster files compatible with earlier versions of Stata.

[John Mullahy]

re: #273 The undocumented command gs_fileinfo will return the command that creates the graph in r(command)

help gs_fileinfo

[FernandoRios]

re: #273 The undocumented command gs_fileinfo will return the command that creates the graph in r(command)

help gs_fileinfo

Ohh that is gold! Thank you

[Bruce Weaver]

Re #274: Given that -help gs_fileinfo- does open a help file in the viewer, I suppose undocumented means it's not in the PDF documentation. Right?

Sorry John. I couldn't resist. As Fernando noted, this is useful info.

[John Mullahy]

Much too late in the day to attempt the logic algebra of a documented yet not documented undocumented command, Bruce.

help undocumented

yet

help gs_fileinfo

🤔

[Nick Cox]

Help on what precisely is "undocumented" can be found in

help undocumented

Undocumented commands are documented in the system help, but their documentation does not appear in the PDF
manuals. That undocumented commands are documented at all shows the "openness" of the Stata software.

So StataCorp has a Pickwickian sense of "undocumented".

On the other hand, "nondocumented" means what it says. Or doesn't say.


For example, try

help _crcslbl 
viewsource _crcslbl.ado

[Bruce Weaver]

I wish there was an official (and straightforward) Stata command to produce clustered bar charts like the ones shown in #5 and #6 of this discussion.

• https://www.statalist.org/forums/for...tegorical-data

As noted by Nick Cox, there are ways to produce something like the plot in #5. But given how frequently (pardon the pun) this type of graph is needed, one should be able to produce it much more easily without having to tweak a bunch of default settings.

Cheers,
Bruce

[Nick Cox]

Bruce Weaver #279 The code in #6 of that thread

 
 graph bar (count) , over(foreign) over(rep78) asyvars legend(pos(1) ring(0) col(1)) blabel(total) b1title("`: var label rep78'") yla(, ang(h)) bar(1, lcolor(black) fcolor(cranberry*0.8)) bar(2, lcolor(black) fcolor(blue*0.5))

is all official. What makes it odd-looking is consistent with Stata philosophy. As it creates the variables it shows they can't be specified as a varlist.

That is on all fours with the approach of graph pie, for example.

[Bruce Weaver]

Nick Cox #280:

Fair enough about that -graph bar- command being completely "official". My main point was/is that it is much easier (IMO) to produce a good looking clustered bar chart in SPSS than it is in Stata. And that will be particularly true for non-expert users.

Some similar issues were discussed in this old thread, which I was reminded of when someone posted to it again yesterday.

• https://www.statalist.org/forums/for...rror-bars-easy

Cheers,
Bruce

[Nick Cox]

Bruce Weaver My view is close to yours in that one strong motive for my own commands in this territory was to make life easier (if not easy) for non-expert users, There remain two issues at least:

What would your ideal syntax look like?

Why might StataCorp be motivated to do this when there already so many bar commands for users to choose from?

The first question should be easy — and naturally I don’t expect details of all the options there should be. I have to wonder how different the syntax would be from
that for existing community-contributed commands.

The second is more awkward, and optional.

[Bruce Weaver]

Responding to Nick Cox in #282:

Good questions, Nick. I think my main problem with generating a nice looking clustered bar chart in Stata is that the basic command generated via the GUI does not produce the output I expected, and would like to see. E.g., here is a command I just generated via the GUI:

clear *
sysuse auto
graph bar (count), over(foreign) over(rep78) ytitle(Frequency)

Given that command, I would like to see a graph something like the ones shown in #5 and #6 of that other thread. Notice in particular that those graphs have:

• Colour-coding for domestic vs foreign
• Small/no space between Domestic and Foreign bars within each level of rep78
• Clear separation between the levels of rep78

I know that with the right options, one can achieve all of that--you provided examples in #6. I just think that this ought to be what one gets by default when issuing a basic graph bar command like the one above.


I wonder if the approach I used in #4 of that other thread might not be easier for newbies and users coming to Stata from SPSS. Since posting that example, I remembered the -separate- command, so might now do it a bit differently as follows:

separate foreign, by(foreign)
* Rename the variables to improve labeling on the graph
rename (foreign0 foreign1) (Domestic Foreign)
* Basic version with default colours etc.
graph bar (count) Domestic Foreign, over(rep78) ///
 title(# of Domestic v Foreign cars by Repair Record) ///
 ytitle(Frequency) ylab(0(5)30,grid)

This last approach matches the approach shown in this example from the Stata FAQ, so might be an approach newbies find when searching for help.

Why might StataCorp be motivated to do this when there already so many bar commands for users to choose from?

I would hope that (like you), they are interested in making life as easy as possible for users who want to produce basic graphs. ;-)

Cheers,
Bruce

[Nae Khar]

Please note that there is a big difference between user friendly and downright awful.

There are ways to be user friendly while maintaining the programs strength, soul and identity — so that one can still be a self-respecting nerd and use it.

Look at how Josh Angerst has brought applied econometrics to the masses through fun, informative, and high quality youtube lectures (https://www.youtube.com/playlist?lis...6hDib27OCvcyW8). Stata can bring data analysis to the masses through a more user friendly and discoverable interface.

Especially when today, predictive modeling and the use of data analysis has expanded greatly to a wide variety of majors and jobs.

There is a huge business opportunity here, but an even bigger service opportunity to bring powerful predictive modeling to a wider audience, who are not your traditional code savy base.



@Bruce Weaver
I work with longitudinal datasets to run econometric models such as DID, IV, and FE regression. I like to believe that that is serious enough.

By no means do I mean that this addition should eliminate syntax. When you double click to open a dataset in Stata, you can see the syntax pop up at the bottom stating something like: use "/Users/Desktop/test.dta". In the same way, I want to be able to open data editor and simply drag a variable or observation (column or row) and have that syntax pop up. I can still document everything and reproduce exactly what have been done. This is one example of the user friendliness which I was referring to, rather than have something so basic buried in a long manual.

This may not be the perfect analogy, but here goes: I will allow my students to use a calculator during a calculus exam, lets say to forgo having to use their time to multiply pi manually, in order to focus on solving the bigger problems that are related to the learning outcomes of the calculus course.

When I use Stata in academic research or teach in the business school, I am not trying to be or produce an expert coder. I am trying to teach predictive modeling and its benefits to business profitability and economic policy.


@wbuchanan
I have tried something similar toPower Bi and Tabluae, but this is definitely not what I meant. The reason being is that these types of programs do not provide me with the same flexibility to apply methods from health economics to large scale business policy research questions.

With the way that everything has developed, this is one area where Stata is stuck in the stone age.

You can be "serious" and have a great interface. If you don't believe it yet, just wait until we meet in a conference.


@Nick Cox
Those laughtracks though

[Nick Cox]

Bruce Weaver #283 I have two main bar chart commands that I regard as current -- catplot and tabplot -- and ten predecessors that almost share the oblivion of most history -- and some further commands that can produce bar charts under recast(). So, your coming up with yet another design can't be a surprise.

Having to generate new variables first before you can draw a bar chart makes sense to you as an experienced user, but the issue is what newish users can appreciate. Good to see separate coming in useful.