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.
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'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).
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.
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.
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")
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 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.
Clyde Schechter
Collapse and contract are highly inefficient when you need/want many permutations of simpler statistics that table can compute (including results which are somewhat comparable to using the ROLL UP and/or CUBE keywords in an SQL statement). There are also cases where an end user may want to dump all of the results into a log file to check intermediate results. If Stata were able to implement something comparable to using ROLL UP (produces specific sub-aggregations) or CUBE (produces all possible sub-aggregations over the set of factors and also does the same excluding the combination of the factors) that would be awesome. Regardless though, I’m not sure there is a need to restrict the number of cells given the majority of computers in use have 64 bit CPUs (32 bit processors in Windows only allow 4GB of RAM to be used by the system).
I would love to have longer global, local, and ado names. The existing 32 character limit is so restrictive and results in unclear abbreviations all over the place.
Comment