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.
Stata's data types (help data_types) support 32 bit integers (long). But Stata does not support variables containing 64 bit integers (which are often called bigint in other software).
This seems like a vestige from when Stata was designed for 32 bit systems.
Fahad Mirza speaking only as one of several folks who’ve done some work in that vein, I’ve not been actively investing in maintaining some of the older stuff (e.g., D3mata) purely because it would be too time consuming to keep up with changes to the JavaScript library. That said, I have thought about throwing together a wrapper around Bokeh and/or Altair, but haven’t made the time for it. If anything, I would say that would probably be the best route at this point versus trying to build something Stata native.
Have folks at Stata considered adding in interactive visualization features to the program? Or is that a far fetched wish? I remember some Stata user makde an attempt to design a code that made visualizations interactive. Not sure if that project is still in progress.
Agree with Julian Reif in #403. The margins command has the nose option, for example. One consideration would be that some or much of the computation time involved in obtaining standard errors has already been invested in obtaining the point estimates themselves (e.g. computing (X'X)-1 for linear regression). But as a general matter allowing vce(none) seems a good idea.
I'd like to see none be added as a vcetype option, at least for the regress command. This option would speed up estimation in situations where standard errors are not necessary. For example, when doing a non-parametric power analysis, a researcher simulates a large number of regressions to obtain a distribution of coefficients, and does not need their standard errors.
Originally posted by Chinh Nguyen (StataCorp)View Post
There's a setting to restore the old behavior of selecting the topmost Do-file Editor in the Do-file Editor's advanced preferences named Keyboard shortcut selects top editor. Support for this setting was also added to Stata for Windows and Stata for Unix.
While we're talking about Mac keyboard shortcuts: cmd-9 used to take you to the active do file, but now duplicates the Windows behavior of opening a new do file. The old behavior was **much** more useful. While you can cycle through windows with cmd-`, depending on what's open, it can take many iterations to get to the do file. With the old behavior, if you really wanted a new do file, you could navigate to the do file window and do cmd-n
There's a setting to restore the old behavior of selecting the topmost Do-file Editor in the Do-file Editor's advanced preferences named Keyboard shortcut selects top editor. Support for this setting was also added to Stata for Windows and Stata for Unix.
While we're talking about Mac keyboard shortcuts: cmd-9 used to take you to the active do file, but now duplicates the Windows behavior of opening a new do file. The old behavior was **much** more useful. While you can cycle through windows with cmd-`, depending on what's open, it can take many iterations to get to the do file. With the old behavior, if you really wanted a new do file, you could navigate to the do file window and do cmd-n
When using a browser on a Mac COMMAND-minus and COMMAND-plus decrease and increase the page's text size, while COMMAND-zero returns the text size to its default.
In Stata COMMAND-minus and COMMAND-plus function the same way in the selected window but there is no corresponding COMMAND-zero to return the window's text to its default size.
Might V18 developers consider adding this feature?
Here's a tiny convenience that could probably be implemented easily. The -gen- option already allows you to assign a value label to the variable you are creating (postfixing :var_label_name to the name of the variable) and to specify its location in the data set with the -before()- or -after()- options. How about a -format()- option that lets you also apply a display format?
It would be better if STATA command: collect export, as(docx) accept the append option so that one can export multiple tables in one word document file. would also be better if one could be able to specify which page of the word document to export a table from STATA.
Indeed, most user-written programs provide little or no version control (e.g. you can't tell them to use the same syntax as the 2013 version of the program did), nor do they notify you a newer version is available. I had someone write me a year or two ago about a bug in my gologit2 program. They were right -- but I had fixed the bug in 2007, and their version was older than that.
I try to avoid calling other user-written programs in my own programs. I'm always afraid an author might make some change and unintentionally zap my program. Sometimes, with permission, I copy part of the code from another program into my own. But that isn't feasible with a big program like esttab.
User-written programs are great, but they don't have all the niceties that programs written by people who get paid for this stuff do,
Can we have version checks for user-written or SSC programs please especially when programming ados. For example, if a program calls another program, then, it should flag the user if he/she is using an older version of an already installed program and should upgrade it.
I sometimes get queries that packages have broken down. But this is usually because users have not upgraded Ben Jann's palettes package, etc.
"ado update" already does this checking, so the underlying functionality is there.
I have suggested once or twice at Stata Conference Wishes&Grumbles sessions that Stata should automatically check for the availability of such updates at the same time when it checks for updates of the Stata software itself. Many users probably do not even know that ado update exists, and they just keep using the version of community-contributed packages from when they first installed it. If I remember correctly, Alan Riley's response was that they do not want to impose such updates on the users because community-contributed packages usually do not have any version control and some users might not want to get the updates by choice.
I still believe that automatically informing users about the availability of updates to community-contributed packages, but leaving them the choice whether they want to update or not, would have more advantages than disadvantages. If a user does not like that, they could then still opt out of automatic update checks somewhere in the settings (similar to updates for the software itself).
Leave a comment: