You are not logged in. You can browse but not post. Login or Register by clicking 'Login or Register' at the top-right of this page. For more information on Statalist, see the FAQ.
It would be convenient if, following a logistic or probit regression, -estat gof- with the -table- option returned the table, say as a matrix, in r(). I say that because it is often useful to plot the observed against the predicted numbers to get a visual gestalt of the fit. This adds considerable value, in my opinion, to the chi square and p-value.
Re #458: I think that the purpose of the -table- command is to produce a table that can be read and understood by human eyes. If we take that as the purpose, then 3,000 cells is probably already more than adequate. If what is wanted is to create a Stata dataset that contains the information that -table- displays, that is already available with the -collapse- command. Am I missing something?
It might have been posted already, but there is an inconsistency in the behaviour of st_tsrevar. tsrevar can deal with operators such as L(0/5).y, st_tsrevar cannot:
Code:
clear
set obs 100
gen t = _n
drawnorm y
tsset t
* works:
tsrevar L(0/5).y
* produces error
mata st_tsrevar("L(0/7).y")
One other feature that I think would be interesting to add would be an option to save results to a frame for commands that would normally allow replacing the data in memory. So the replace option could still exist for backwards compatibility but would also offer the flexibility for newer versions of Stata to use frames to provide the same behavior without destroying the data actively in memory.
Adding to the previous comment, I think any instances where there are range limitations based on older underlying code should be migrated to be constrained by available memory instead. For example, the table command has a limit on the total number of cells that is roughly 3000 or so cells; why have this arbitrary ceiling if the computer has the capacity to produce a more complex table without breaking a sweat (especially since it is fairly routine for SQL engines to do the equivalent work but without any limitations on the number of cells that can be returned). Another example is the limit on the number of string elements that can be passed to the inlist() function. Again, if the machine is capable of handling many more elements than 7, why limit the number of elements arbitrarily. Some of these built in limitations also create differences that don’t exist in other languages which makes Stata appear to be a bit antiquated in these specific contexts.
I'd like to see the behavior of table be made consistent when displaying the results and replacing the data in memory with the result set. For example, with the missing option specified Stata will display several tables filled with missing values across the dimensions of interest, but when using the replace option those records are not retained. Given that a missing value could be reported for the statistics, it isn't clear why there would be a difference in behavior (particularly when trying to generate results sets that are standardized for some format).
In project manager I would suggest the possibility of having a pre and a post script that are run automatically before and/or after a do file is run in the project manager settings.
This way paths could be set etc and there could some code for cleaning up.
I tweeted a thread earlier today about problems that can arise with dummy RHS variables in Poisson regression and the fact that Stata produces an apparently converged estimate when it should not be able to produce an estimate. (Note: The problem is more general than Poisson regression.) https://twitter.com/JohnMullahy/stat...72211692036096
I'm wondering whether v17 might consider building in errors (or at least warnings) akin those that exist for probit and logit
Code:
outcome = x2 <= 0 predicts data perfectly
r(2000);
I could not agree more; I was hoping this article would lead to that, but it has been 10 years... The excellent user-contributed ppmlhdfe command fixes all those problems and it could essentially replace the very unreliable poisson command.
Leave a comment: