[Clyde Schechter]

Re #45: making this a general feature would be extremely difficult, probably impossible. I will here just tout my own work to point up one situation where you can get this. When you are iterating some commands over subsets of the data defined by values of variables, use the -runby- command instead of -foreach- loops. Set the -status- option on -runby- and it gives you a progress report updated periodically. -runby- is written by Robert Picard and me, and is available from SSC.

Also, some commands that are inherently iterative, such as -bootstrap-, -simulate-, and -mi estimate- include a -dots- option that accomplishes this purpose.

[Allan Gregory]

Hi
I wish to see improved graphs. I am tired of all the R graphs that are so much spiffier than ours. It seems to me that the graph command has changed little over the years.

[Maarten Buis]

Allan Gregory What exactly do you want to change? Can you give examples of graphs you want to create? Have you considered changing your scheme? See e.g. the following Stata Journal articles:
https://journals.sagepub.com/doi/pdf...867X1801800301
https://journals.sagepub.com/doi/pdf...867X1801800403
https://journals.sagepub.com/doi/pdf...867X1801800402
https://journals.sagepub.com/doi/pdf...867X1701700313

[Erik Ruzek]

I agree with Maarten Buis that schemes go a long way. See also Asjad Naqvi's package of awesome schemes. But I also agree with Allan Gregory that at the frontiers there are some things you can do in ggplot+other packages or with seaborn, such as these marginal distribution plots (not marginsplots), that would be hard, if not impossible, to do in Stata.

[Allan Gregory]

Yes I am aware of the schemes but this is not exactly what I wished for. Erik touched on them . Look at https://blog.digitalogy.co/top-r-lib...visualization/ for the R libraries.

[Jonathan Sturgeon]

Ability to see SEM models visually as an output rather than an input

[Maarten Buis]

Allan Gregory can you pin down what you think is missing. These seem pretty generic graphing packages.

[Ali Atia]

Erik Ruzek -- here is one attempt to produce a plot similar to the one you linked, in fewer lines of code than are used by that website in ggplot2 (https://www.r-bloggers.com/2021/05/g...2-extension/):

clear all
import delimited "https://raw.githubusercontent.com/tidyverse/ggplot2/master/data-raw/mpg.csv"

scatter cty hwy ||lowess cty hwy||,leg(off) name(lowess) ytitle("City MPG") xtitle("Highway MPG") ysc(r(10(5)35)) xsc(r(10(10)50))
levelsof class,local(classes)
foreach class of local classes{
    local cty `cty' kdensity cty if class=="`class'",  hor||
    local hwy `hwy' kdensity hwy if class=="`class'" ||
}
twoway `cty',name(cty) leg(off) fxsize(25) ytitle("") yla(none) xtitle("⠀") ysc(r(10(5)35))
twoway `hwy',name(hwy) leg(off) fysize(25) xtitle("") xla(none) ytitle("⠀") xsc(r(10(10)50))
gr combine  hwy lowess cty, hole(2) rows(2) imargin(0 0 0 0) commonscheme scheme(s1color)

This is rough work, but with additional use of -twoway area- and the user-written grc1leg to create a common legend, you could make it even more similar to the ones produced by ggplot.

[Walid Al-Soneidar]

I don't understand why Stata is ignoring the fact that most new methods in statistics are released in R first before making it to other software packages. I love Stata's interface, help files, and resources, but I often feel left behind whenever I want to try some new tool. Would love to have integration with R, so I can do all my data preparation, descriptive analysis, modeling, in Stata, then if needed, maybe just run an R code natively for that new method. Haghish created a "workaround", but it is not perfect.

They did it for Python, so now please do it for R. Definitely R is much more important to biostatisticians & epidemiologists than Python.

[Dirk Enzmann]

Note that there is the package -rcall- by Hagish on GitHub (see Hagish, E. F. (2019). Seamless interactive language interfacing between R and Stata. The Stata Journal, 19(1), 61-82).

[Walid Al-Soneidar]

Note that there is the package -rcall- by Hagish on GitHub (see Hagish, E. F. (2019). Seamless interactive language interfacing between R and Stata. The Stata Journal, 19(1), 61-82).

Thanks, Dirk! I am familiar with this package, which I describe as a "workaround" in my comment above. But it is not perfect, and definitely could be improved and implemented natively as is the case for Python.

[Christopher Bratt]

I strongly support Walid Al-Soneidar’s suggestion. After trying the integration with Python, I have been left rather disappointed.

Python is great, but for statistical analyses, R is much better than Pandas etc in Python. Also, Jupyter Notebook or Spyder are nothing like RStudio.

But I suspect commercial interests might make StataCorp reluctant to open up for real integration with R.

[jerome falken]

I could really use a faster contourplot without having to run ggplot, i.e. code below should not take 18 hours to render:

set obs 6400
generate a=runiform()
generate b=runiform()
generate c=runiform()
twoway contour a b c

Please also note that this countourplot interpretation isn't interruptible, be ready to kill your process entirely.

Python code should be interruptible without having to quit stata entirely:

python:
import time
time.sleep(1000)

As you see, the red "stop interpretation" icon isn't actionable.

Thank you

[Fahad Mirza]

Will be wonderful if there was an export option to the Table command. Will make life really easy

[Stephen Jenkins]

#59 Fahad: please see the new facilities in version 17. New -table- functionality, and new -collect-. There are Stata blogs and YouTube videos on this stuff, as well as the info about the new version on StataCorp website