[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

[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]

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 #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]

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]

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

[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

🤔

[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.

[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

[John Mullahy]

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

help gs_fileinfo

[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.

[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.

[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.

[FernandoRios]

I think this comes once in a while but,
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.

[Sergiy Radyakin]

Dear Leonardo, Colleagues,

yes, certainly tried that. It is not the same. Tiled windows are independent. So if you switch to e.g. Word or Outlook - it covers both. Then you need to go back to Stata. You seek for Stata window to bring it on top, then you start seeking for the corresponding do-editor to bring that on top of word as well. If you mis-switch accidentally to 3rd program - start all over again. Or (as is common with me) open some 6-12 Stata sessions with each of them having a separate (one or more) do-editors. There is no way to even understand in which Stata window to seek for the output of it running. This is related to my other wish to have a button/hotkey to bring the Stata window from the do-editor. My workflow is :

• correct the do file;
• press Ctrl+S to save;
• press Ctrl+D to execute;
• press Ctrl+O to switch to the corresponding Stata window to see the output.

Since the last combination doesn't exist, instead I have to seek among the tons of windows which one corresponds to what. Annoying and frustrating. (Not as frustrating as in the good old times when I used to send do-files for remote execution and get the error back a week later, but the demands have risen since then )

After that of course one would wish to jump back to the do editor. I admit this is a bit more complicated, since there may be multiple do editors for the same Stata session (though only 1 session for each editor!!), but jumping to the last that was active is the most reasonable behavior (imho), so that Ctrl+O can switch back and force between the code and the output that it produces.

On my screen now:

Another bit that aggravates the issue is that the headers are named non-traditionally:

- common: "Document1 - Microsoft Word", "Google.com - Internet Explorer", "Picture1.png - Paint", "Untitled - Notepad"
- Stata: "Do-file Editor - ...", "Graph - D...", "Viewer - help tw..."

so that the most valuable part, the specification of the document I am working with, Stata places at the end, making it disappear in abbreviation with multiple windows competing for space.

I am not sure if there are rules for sorting the windows in this list, e.g. whether the windows for the same session of Stata are grouped together, but based on the simple trials they are not, and perhaps they are sorted chronologically, (type help something in the first session window, and it will appear after the last session window), or based on the next available PID or something else.

And if you think that it's my own problem - imagine being called by a colleague (with a similar mess on the screen) for troubleshooting something (happened to me all the time in those days when the office work was possible). It's a nightmare. You have no idea about how many windows are open, to which sessions they are attached, which program generated which output, and what will be lost if I attempt to close something. The number of queries on this list about how to recover the do-file overwritten with data or data file overwritten by code is a testament to this confusion.

Oh, yeah, and try to disconnect one of those 3 monitors connected currently. You'll have more chances of winning on a zero in Las Vegas, than finding which window will jump into which position.

There is a need for some meaningful higher-level management actions, more then just maximizing the current window.

• show the list of all windows associated with the current session (data, code, graphs, etc) with the status saved/not saved, named/not named, and a possibility to switch there;
• sort windows grouping by session;
• bring forward all windows associated with current session;
• minimize everything else except related to the current session.
• tile or cascade the current session windows.
• circle-navigate between the windows of the current session.
• join all the tabs of multiple (two specific or all open) do-editors into one.
• etc, etc, etc.

There are four different versions of execute/do/run in the do-editor menu, but not a single one of them allows to do-and-switch-to-output, which imho is the most logical on a single-screen machine.

Lots of more thoughts on this, but not much time. "Close all viewers" was added relatively recently, I believe, so perhaps someone is thinking about/working on these issues (no hotkey for that, sigh). It was earlier confirmed that code folding is coming soon. Hope more could be done for window management too. Visual Studio, imho, is also not perfect in managing the windows, though it has a much more diverse nomenclature. Yet somehow I've managed to find a comfortable arrangement of code on one screen and everything else docked in another.

Users on Windows platform may refer to https://www.windowscentral.com/best-...oard-shortcuts for a comprehensive list of keyboard shortcuts in modern Windows (if you think you know there is just Ctrl+C and Ctrl+V, just check...).

🚩 None of the above should be interpreted as critique of Stata product. It is absolutely wonderful and I love it. It is just that the mess is stemming from the complexity of the tasks it handles. If you are a beginner wishing to load your data, run a regression and plot the residuals, don't worry at all about any of those issues, you will likely not encounter them.

Best, Sergiy