[John Mullahy]

A helpful and (I would imagine) easy to implement improvement to fracreg logit and fracreg probit would allow the lower and upper bounds to be finite values other than zero and one. While it's easy to transform an outcome defined on [a,b] to one defined on [0,1] it would make some subsequent work (e.g. predict, margins, etc.) more straightforward if the natural units of measurement could be retained throughout with no need for transformation.

Such a modification might look something like:

fracreg logit y x1 x2, lb(somevalue other than 0) ub(somevalue other than 1)

For many researchers the main motivation for using fractional regression is to enforce the requirement that E[y|x] is in the [0,1] interval. The proposed modifcation would straightforwardly enforce the requirement that E[y|x] is in [a,b].

[John Kane]

A couple of minor things:

1) Allowing for gradient backgrounds in plots (so, not a single color background). Excel does this and it looks quite nice.
2) Some built in feature to easily create animated .gif files. This can be done using third-party sites and various workarounds, but it would be great if Stata had a way of taking a bunch of .png or .pdf files from graphs, and then allowing the user to combine them all together, in a particular order, specify the speed at which it cycles through the images, specify the total length of the.gif, etc.

[George Hoffman]

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

what if more commands, including -twoway - understood that i.xvar would be categorical, and c.xvar would be continuous?

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

[Jared Greathouse]

An egen replace would be great, too

[George Ford]

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

[Jared Greathouse]

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

[alejoforero]

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

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

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

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.

[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

[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

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