Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Joao Santos Silva
    replied
    Motivated by recent posts, I would like to suggest two changes related to FE estimators:

    - Disable the margins command after clogit and after xtlogit and xtpoisson when the fe option is used. The results of the margins command in these cases are meaningless and misleading.

    - After clogit and after xtlogit and xtpoisson when the fe option is used, Stata should report the full sample size rather than the sample size after dropping uninformative observations. The current practice leads to much confusion and to unfounded fears of sample selection bias.

    Leave a comment:


  • Leonardo Guizzetti
    replied
    Another idea. Set operations for vectors within Mata, analogous to the macro list directives. In particular, intersection, union, difference , ===, and -in-.

    Leave a comment:


  • Leonardo Guizzetti
    replied
    I think small change in consistent to frame commands would be reasonable. StataCorp has taken the approach (where possible) to use verbs to make commands more recognizable and improve readability. To this end, we have

    Code:
    frames dir
    frame create
    frame change
    frame copy
    frame put
    frame post
    frame drop
    frame reset
    frame rename
    But then we have

    Code:
    frget
    frlink
    I'm not sure why the need to make the get/link commands slightly obfuscated. Especially as -frlink- is intended as a (partial) replacement for -merge- when working with frames, it would be nice to have the same consistency in naming conventions of these commands.
    Last edited by Leonardo Guizzetti; 07 Apr 2021, 10:01.

    Leave a comment:


  • Niels Henrik Bruun
    replied
    Bjarte Aagnes Thank you

    Leave a comment:


  • Bjarte Aagnes
    replied
    ref #502 #503
    Code:
    . statsby ll=(r(table)["ll","weight"]) , by(foreign) : regress price weight
    (running regress on estimation sample)
    
          command:  regress price weight
               ll:  r(table)["ll","weight"]
               by:  foreign
    Last edited by Bjarte Aagnes; 05 Apr 2021, 14:19.

    Leave a comment:


  • William Lisowski
    replied
    Niels Henrik Bruun in #502 -

    I suspect you are being stung by statsby.ado, which specifies version control for version 9, which does not allow subscripting r(table). Consider the following maximally inelegant workaround.
    Code:
    . sysuse auto, clear
    (1978 Automobile Data)
    
    . statsby b=el(r(table),rownumb(r(table),"b"),colnumb(r(table),"weight")), by(foreign): regress 
    > price weight
    (running regress on estimation sample)
    
          command:  regress price weight
                b:  el(r(table),rownumb(r(table),"b"),colnumb(r(table),"weight"))
               by:  foreign
    
    Statsby groups
    ----+--- 1 ---+--- 2 ---+--- 3 ---+--- 4 ---+--- 5 
    ..
    
    . list
    
         +---------------------+
         |  foreign          b |
         |---------------------|
      1. | Domestic   2.994813 |
      2. |  Foreign    5.36204 |
         +---------------------+

    Leave a comment:


  • Niels Henrik Bruun
    replied
    Bjarte Aagnes in #501: But does not seem to be working in
    Code:
    statsby b=r(table)["b", "died00:1.aar2020"], by(icd10chap) clear: poisson died00 i.aar2020, vce(robust) nolog
    Or am I missing something

    Leave a comment:


  • Bjarte Aagnes
    replied
    #499 Two commands should not be required:
    Code:
    r(table)["ll","varname"]

    Leave a comment:


  • FernandoRios
    replied
    wbuchanan
    Actually, as long as the community-contributed command produces e(b) and e(V), It is possible to get r(table) output if you use "ereturn display".

    Leave a comment:


  • wbuchanan
    replied
    Clyde Schechter
    I’m not sure if all estimation commands return results in r(table), but do know that community contributed commands are not likely to report results in r(table).

    Leave a comment:


  • Clyde Schechter
    replied
    I agree with #498--it would be an enormous convenience. But I will just point out that you can pull the confidence bounds from r(table). It's more typographically cumbersome and requires two commands instead of 1, but it's doable.

    Leave a comment:


  • Niels Henrik Bruun
    replied
    Regarding System variables (_variables) we can easily retrieve estimates by _b[] and standard error by _se[].
    However, in many cases it is the confidence interval that needs to be reported.
    So, I propose two new functions/variables _lb[] and _ub[] for lower and upper bound for the confidence interval.
    I know, it can't be seen what the level is directly and hence can lead to wrong reporting.
    But still I think that _lb[] and _ub[] are more than nice-to-have

    Leave a comment:


  • Leonardo Guizzetti
    replied
    Similar to the -merge- command, -frget- could use a -replace- or -update- option which would overwrite/update values for existing variables when the user requests it. A strong warning should be issued to the user, but I think the behaviour deserves implementation.

    Leave a comment:


  • Nicholas Winter
    replied
    Add the export excel option firstrow(variables|varlabels) to export delimited, so the first row of the exported file has the variable labels rather than the variable names. As it stands I'm using this ridiculous work-around: https://www.statalist.org/forums/for...01#post1537701

    Seems like this should be relatively easy to implement....

    Leave a comment:


  • Erik Ruzek
    replied
    Originally posted by Mark Davis View Post
    Please Stata Corp, don't make stata 17 great. I just bought a Stata 16 MP8 license to be able to use apple silicone and and I can't afford for you to come out with any must have features.
    Back in 2017 when they released Stata 15, I had purchased Stata 14 a couple of months prior. After they announced Stata 15 I got an email from the sales team saying that because I had recently purchased 14, I was eligible for a free update to 15. I was blown away and happy to accept that upgrade. This was when you paid more money up front to get the full version, which is my preferred option. I don't know if that is still their practice as they seem to want everyone to go to a subscription model, but there's at least hope!

    Leave a comment:

Working...
X