[Castor Comploj]

Wishlist: Please add more color schemes than the 4 provided (white, grey, blue, black). Something between black and white is comfortable at times.

[Jean-Michel Galarneau]

This does seem to work relatively well with continuous data. It does not work when trying to combine it with mimrgns for multiply imputed data.
Thank you for this suggestion.

[Jonathan Afilalo]

It would be uber-practical if STATA 18 had native support for ML models such as XGBoost to perform classification/regression analysis on tabular data. I know it can be done through the Python API, but this is far from ideal from a user friendliness and experience point of view.

[Jared Greathouse]

Now that it's on my mind, it would also be cool to integrate hex colors into Stata's customization scheme. So if I like the color imperial red, I could just do

lcol("#ed2939")

instead of

lcol("237 41 57")

[Jared Greathouse]

Hey, so say I have a time series that looks like this

* Example generated by -dataex-. For more info, type help dataex
clear
input double cf float(cigsale3 year)
122.09479671055374   123 1970
 121.6065529858943   121 1971
123.65496555673786 123.5 1972
124.10483385256285 124.4 1973
126.75462121002437 126.7 1974
126.63825689453941 127.1 1975
127.92824675473713   128 1976
 126.4873238266998 126.4 1977
125.37864959522437 126.1 1978
122.34822098598946 121.9 1979
  119.928632673551 120.2 1980
119.10175992318514 118.6 1981
115.68795915144617 115.4 1982
111.04282414949492 110.8 1983
104.56636628133799 104.8 1984
 102.7682761771388 102.8 1985
 99.35677151118881  99.7 1986
 97.39989301281054  97.5 1987
 91.15104874688336  90.1 1988
 88.66315821472102  82.4 1989
 85.21665593484636  77.8 1990
 80.76789213762831  68.7 1991
 79.08976003988303  67.5 1992
 79.33037122087953  63.4 1993
 76.85184614706827  58.6 1994
 74.46827712093958  56.4 1995
 73.64585997258112  54.5 1996
 73.61649595338298  53.8 1997
 71.64467330066938  52.3 1998
 70.90756101627477  47.2 1999
 65.74723052634468  41.6 2000
end
format %ty year

cap set scheme gg_w3d 

if _rc {
    
net install schemepack, ///
from("https://raw.githubusercontent.com/asjadnaqvi/stata-schemepack/main/installation/") ///
replace    
    
}

lab var cf "Counterfactual Sales"
lab var cig "Real Cigarette Sales"

tsset year, y
cls
tsline cig, lcol("12 10 0") lwidth(thick) || /// Observed Sales
tsline cf, lcol("237 41 57") lwidth(medthick) lpat(--),, /// Counterfactual
scheme(gg_w3d) ///
tline(1989, lcol(blue) lpat(solid) lwid(medthick)) ///
legend(ring(0) pos(3)) ///
tti(Year) ///
yti(Cigarette Sales) ///
plotregion(fcol(gs12))

The coordinates are meant to rep the x-y axis respectively, allowing the user to place the legend literally wherever they please. At present the legend appears such that it intersects with the counterfactual (I know I can just delete the color from within the legend box, but suppose I like the color and wanna keep it). Say I also, arbitrarily, wanna keep the legend on the right side of the graph. In a situation where I could do, for example,

legend(pos(coord(1990, 99.5)))

we'd have the legend's box moved inward, such that its left vertice touches 1990, and its centroid intersects with the y value of 99.5. Now of course, this could get a lot trickier when multiple things are plotted, so no doubt some tinkering and adjustment would be needed. I like the clock way, but I always wondered why we couldn't simply be arbitrary and place it wherever our heart desires. wbuchanan

[wbuchanan]

Jared Greathouse what would those coordinates represent? Also, are you just asking to define where the upper left corner would begin/start or something else?

[Jared Greathouse]

Another thing I would most appreciate is to allow pinpoint customizations of the legend placement with coordinates, e.g.,

legend(pos(coord(1970, 45)))

[Sebastian Kripfganz]

It would be very useful if there was an option to fvexpand which removes base values, as Mark Schaffer's fvstrip does (which is also in Sergio Correia's ftools under the name ms_fvstrip):
https://www.statalist.org/forums/for...-fvexpand-list

[Aaron Wolf]

Stata kernel for Jupyter notebooks. The current Stata magic command works, but is a little clunky, and I am not a fan of needing to write in at the start of each cell. It is also a bit slow, in my experience. Much slower than running in Stata directly. Likewise, Stata should likely find a way to help notebooks with syntax highlighting.

[wbuchanan]

Leonardo Guizzetti
Assuming there is only one categorical variable of interest, I’ll post a different solution I developed to this challenge (which also includes some other functionality related to the task) a bit later. The solution I created requires an additional command call to set up the infrastructure, but will deal with any number of categories (and assumes the intercept is not of interest), captures the model command call, and allows additional info to be passed to describe the model. The approach I took uses a Mata object that I defined after I figured out that struct objects didn’t seem to persist between calls to an ado. So all the metadata needed gets stored in an object and the methods defined on the object handle all the storage and retrieval work.

[Bjarte Aagnes]

re #531/#532 another variant of very clunky

frame change specifications

des, varlist
local varlist `r(varlist)'  

forvalues i = 1/`=_N' {
    
    foreach arg of local varlist {

        loc `arg' = `arg'[`i']
    }    

    frame default {
        
        regress price i.foreign `xvars', vce(`vcetype')
        frame post results ("`name'") (_b[1.foreign]) (_se[1.foreign])
    }
}

[Leonardo Guizzetti]

I don't think I've seen this one so far: it would be really great to have a simple syntax for frame iteration (looping through the rows of a frame, loading variable values into local macros that can then be used in the execution of code within a loop). A common use case for me would be iterating through candidate specifications where each iteration of the loop requires multiple pieces of information to run. More generally, frame iteration would accomplish many of the same patterns that are accomplished in Python with list or dictionary iteration, and in SAS with hash object iterators.

A very simple and non-sensical example (more typical use would have the specifications frame loaded from another source):

sysuse auto

frame create specifications strL( name xvars vcetype )
frame post specifications ("weight only") ("weight") ("ols")
frame post specifications ("weight and length, robust") ("weight length") ("robust")
frame post specifications ("weight and mpg, bootstrap") ("weight mpg") ("bootstrap")

frame create results strL( name b se )

foreach of frame specifications {

regress price i.foreign `xvars', vce(`vcetype')
frame post results ("`name'") (_b[1.foreign]) (_se[1.foreign])

}

I'm not wedded to this specific syntax, but you get the idea. Iterating over observations of a frame now is very clunky, because each local macro variable has to be explicitly assigned inside an observation counter loop, rather than being automatically assigned using the name of the corresponding variable in the frame.

Also want to +1 on appending frames to one another as built-in functionality. I have found the various frame appending packages to be buggy.

What you've described can already be done with a little tweaking. It wouldn't be too much more work to load in specifications from an external file (say an Excel sheet), and to split out the part of the loop into a utility program that serves to fetch the relevant specs from a specific row. Nevertheless, this is one, minimal technique that works.

* Prepare Specs and results frames
frame create specifications str64( name xvars vcetype )
frame post specifications ("weight only") ("weight") ("ols")
frame post specifications ("weight and length, robust") ("weight length") ("robust")
frame post specifications ("weight and mpg, bootstrap") ("weight mpg") ("bootstrap")
frame specifications: compress

frame create results str64(name) double(b se)

// Load data, and step through regressions, driven by the Specs
mkf data
cwf data
sysuse auto

frame specifications: local nspecs = _N
forval i = 1/`nspecs' {
  cwf specifications
  local i_name = "`=name[`i']'"
  local i_xvars = "`=xvars[`i']'"
  local i_vce = "`=vcetype[`i']'"
 
  cwf data
  regress price i.foreign `i_xvars', vce(`i_vce')
  frame post results ("`i_name'") (_b[1.foreign]) (_se[1.foreign])
}

cwf results
list

As an aside, it's better to store estimation results as numeric types (here, double) so you can manipulate them later if needed. You can also keep your specs to strings shorter than strL because it's unlikely (or impossible) to have such long strings in most cases, and you can save some memory by being more conservative.

[Lee Tucker]

I don't think I've seen this one so far: it would be really great to have a simple syntax for frame iteration (looping through the rows of a frame, loading variable values into local macros that can then be used in the execution of code within a loop). A common use case for me would be iterating through candidate specifications where each iteration of the loop requires multiple pieces of information to run. More generally, frame iteration would accomplish many of the same patterns that are accomplished in Python with list or dictionary iteration, and in SAS with hash object iterators.

A very simple and non-sensical example (more typical use would have the specifications frame loaded from another source):

sysuse auto

frame create specifications strL( name xvars vcetype )
frame post specifications ("weight only") ("weight") ("ols")
frame post specifications ("weight and length, robust") ("weight length") ("robust")
frame post specifications ("weight and mpg, bootstrap") ("weight mpg") ("bootstrap")

frame create results strL( name b se )

foreach of frame specifications {

    regress price i.foreign `xvars', vce(`vcetype')
    frame post results ("`name'") (_b[1.foreign]) (_se[1.foreign])

}

I'm not wedded to this specific syntax, but you get the idea. Iterating over observations of a frame now is very clunky, because each local macro variable has to be explicitly assigned inside an observation counter loop, rather than being automatically assigned using the name of the corresponding variable in the frame.

Also want to +1 on appending frames to one another as built-in functionality. I have found the various frame appending packages to be buggy.

[Sebastian Kripfganz]

I have long asked for xthtaylor to work with the special case in which there are no exogenous time-invariant regressors. Currently, the command aborts with an error message. There is no econometric reason for preventing the estimation of such a model. This should be a relatively straightforward update. See also: https://www.statalist.org/forums/for...nous-variables

[Jared Greathouse]

I or others may have mentioned it, but integrating R code into Stata would be awesome too like we've done with Python. Too often, we have to "choose" between Python or R... where instead, we should have the best of the three worlds- data cleaning in Stata, and fancier statistical analyses in R/Python. It would go a great way into making people bi or trilingual, as well as expand the scope of Stata's use to others.