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

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

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

[Niels Henrik Bruun]

I want a category version of -twoway-.
I mean the x-scale from, e.g., boxplot and the twoway choices for the y-scale.
Consider the command syntax: -catway rcap calculated_value1 calculated_value2 calculated_value2, over(cat1) over(cat2)-.

[Tim Huegerich]

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.

For now, you can forego the Stata magic command with this Stata 17 kernel: https://hugetim.github.io/nbstata/
There's also a JupyterLab extension with (imperfect) syntax highlighting: https://github.com/kylebarron/jupyte...tata-highlight

[Doug DeMoulin]

It would be nice for the stata 18 to have the type of study design being used for power calculations and/or inserting what model/test is to be run with the appropriate power calculations listed under that respective test statistic

[Niels Henrik Bruun]

I wish for an ODBC and/or a JDBC driver for Stata datasets build into Stata. The URL option could refer to a folder, so that all Stata datasets in there are accessible. No user and password are needed. Then the power of SQL could be used for very powerful data management.

[wbuchanan]

Niels Henrik Bruun I think your request would require Stata to implement an SQL engine since ODBC and JDBC are purely communications protocols to submit queries to a database and retrieve the result sets.

[Niels Henrik Bruun]

wbuchanan I do not know hard it is to build such an engine. I can only say, that it would be a nice feature. I had hoped, that there were some libraries making the development of such an engine relatively easy.

[wbuchanan]

Niels Henrik Bruun I totally agree that having SQL functionality would be a useful feature. There are several open source SQL options (e.g., H2, PostgreSQL, SQLite, etc...). There'd likely also be some other challenges related to native integration that would affect performance if SQL tables were being used to manage data in the backend (primarily because SQL engines keep the majority of data on disk whereas Stata keeps it in memory). That said, I think extending some of the current data management functionality to provide some SQL features (e.g., union vs union all, subqueries, etc...) could be useful. Maybe that functionality will be built out using frames?

[alejoforero]

Pretty basic but, it would be great to be able to stop loops using the stop button.

[Jared Greathouse]

alejoforero I don't understand. Why would this be needed?

[George Ford]

adding the ability to use weights in egen as in asgen.

[Jared Greathouse]

An egen replace would be great, too

[Joro Kolev]

I totally agree with George Ford #553 and Jared Greathouse #554. Stata Corp should provide a replace option to all egen functions, or an alternative suit of ereplace commands. And all the egens that produce summaries and estimates should be taking weights, just like all summary statistics and estimation commands in Stata take weights.

But for some reason it seems that Stata Corp has lost interest in egen, and has left the egen suit to users for development. In fact the egen suit was not updated at all roughly between Stata 6 and Stata 16. Somebody at Stata Corp sit down and rewrote many egen functions in 2020. Before this there were no updates for some 20 years.

In my view the choice by Stata Corp to neglect the egen suit is regrettable, because one of the main strengths of Stata are data manipulations, and this is just what egen does, data manipulations. If I were Stata Corp, I would assign people to always look out for potential additions and improvements to the native functions in the core going with gen, and the added ado functions in egen.