Announcement

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

  • Why Stata graphs have different margins?

    Dear Statalists,
    I am plotting my estimated coefficients and its confidence intervals. But I found that two graphs using the same code produce different margins in the graph. So when I combine them together using "gr combine" or "gr1leg2", the result is not so neat.

    The code for generating the graphs is :
    Code:
    twoway ///
    (scatter estimate parmid, mcolor(black)) /// dot for group 1
    (rcap min95 max95 parmid, vert color(black)), xtitle("") /// code for 95% CI
    graphregion(color(white))  yline(0,lp(dash) lcolor(black)) title("`title'") ///
      ylabel(, angle(horizontal))  ///
      legend(label(1 "Coefficient") label(2 "Lower / Upper 95% CI") size(small))
    As you can see from the following picture, the the right-hand-side graph has larger margin on the left.
    Click image for larger version

Name:	compare.png
Views:	1
Size:	55.1 KB
ID:	1554888




    The following is the result when I combine them together using code:
    Code:
    gr combine qpct.gph qpcg.gph
    Click image for larger version

Name:	compare2.png
Views:	1
Size:	28.3 KB
ID:	1554889


    It is clearer that the right-hand-side graph has smaller width. It is a bit ugly...
    When using "gr combine qpct.gph qpcg.gph ,ycommon", the graph does not have such problem. But I don't want to use the same y axis for all graphs because on some occasions, the magnitudes of the two graphs can be very different.

    Is there anything I can do to adjust the margin or fix it?
    Thanks a lot!
    Kailin



    Update: I found that not including "ylabel(, angle(horizontal))" command can also solve the problem. But I would like to have horizontal y labels and natural margins at the same time. So any suggestions would be appreciated!
    Last edited by Kailin Gao; 23 May 2020, 23:09.

  • #2
    State need to improve their graphs...that's for sure..like Matlab or R

    Comment


    • #3
      Mario: please elaborate your statement, giving specific examples. Matlab and R are each fine software; so is Stata. Are you making a claim about "default" graphs produced for specific chart types, or the production of specialised types of chart? (Speaking personally, all the sophisticated graphs that I have seen produced in R use code that is at least as long and 'complicated' as the corresponding statements in Stata. I know nothing about Matlab.)

      Comment


      • #4
        I strongly endorse the general remarks of @Stephen Jenkins., but most of what follows is directed at the specific grumble raised.

        #1 is incomplete as there is no data example and in any case the same code could not produce different graphs unless the variables were changed as well.

        That aside, here is a positive tip, given evident problems:

        1. graph combine can indeed be awkward because crucial details on different graphs can be -- well, different -- even if the overall design idea is similar, if not identical. That can easily lead to problems of alignment or spacing. The job is hard!

        2. You don't really want graph combine here as you don't want, presumably, the same legend repeated. That, I guess, explains the allusion to gr1leg2 -- itself yet another allusion to grc1leg from
        Code:
        net describe grc1leg, from(http://www.stata.com/users/vwiggins)


        There is a solution to both, so Don't do that, then! http://www.catb.org/~esr/jargon/html...hat-then-.html

        Often you will get better graphs than are produced by graph combine by moving to a different data structure and using a by() option to produce different panels.

        Concretely, here is a detailed example, including various other small tricks. The most striking points for this thread are that a single legend will be produced (although I chose to suppress it, as will usually be a good idea) and that yla(,ang(h)) -- which I tend to favour too -- works fine even with different kinds of numbers on the axis in question.

        Code:
        tokenize "price mpg weight length" 
        
        forval k = 1/4 { 
        
            sysuse auto, clear 
            if "``k''" == "price" label var price "Price (USD)"
            local which : variable label ``k''
            if "`which'" == "" local which "``k''"
            local labels `labels' `k' "`which'"
            
            statsby, by(foreign) clear: ci mean ``k''
            gen which = `k'  
            save g`k', replace 
        } 
        
        append using g1 g2 g3 
        
        label def which `labels'
        label val which which 
        
        list , sepby(which)
        
        set scheme s1color 
        twoway rcap lb ub foreign || scatter mean foreign, by(which, yrescale note("") legend(off)) yla(, ang(h)) xsc(r(-0.2 1.2)) xla(0 1, tlc(none) valuelabel)
        Click image for larger version

Name:	betterthancombine.png
Views:	1
Size:	22.7 KB
ID:	1554943

        Comment


        • #5
          State need to improve their graphs...that's for sure..like Matlab or R
          FWIW you can use the plottig scheme (ssc install blindschemes) to mimic R's ggplot2.

          Comment


          • #6
            Originally posted by Nick Cox View Post
            I strongly endorse the general remarks of @Stephen Jenkins., but most of what follows is directed at the specific grumble raised.

            #1 is incomplete as there is no data example and in any case the same code could not produce different graphs unless the variables were changed as well.

            That aside, here is a positive tip, given evident problems:

            1. graph combine can indeed be awkward because crucial details on different graphs can be -- well, different -- even if the overall design idea is similar, if not identical. That can easily lead to problems of alignment or spacing. The job is hard!

            2. You don't really want graph combine here as you don't want, presumably, the same legend repeated. That, I guess, explains the allusion to gr1leg2 -- itself yet another allusion to grc1leg from
            Code:
            net describe grc1leg, from(http://www.stata.com/users/vwiggins)


            There is a solution to both, so Don't do that, then! http://www.catb.org/~esr/jargon/html...hat-then-.html

            Often you will get better graphs than are produced by graph combine by moving to a different data structure and using a by() option to produce different panels.

            Concretely, here is a detailed example, including various other small tricks. The most striking points for this thread are that a single legend will be produced (although I chose to suppress it, as will usually be a good idea) and that yla(,ang(h)) -- which I tend to favour too -- works fine even with different kinds of numbers on the axis in question.

            Code:
            tokenize "price mpg weight length"
            
            forval k = 1/4 {
            
            sysuse auto, clear
            if "``k''" == "price" label var price "Price (USD)"
            local which : variable label ``k''
            if "`which'" == "" local which "``k''"
            local labels `labels' `k' "`which'"
            
            statsby, by(foreign) clear: ci mean ``k''
            gen which = `k'
            save g`k', replace
            }
            
            append using g1 g2 g3
            
            label def which `labels'
            label val which which
            
            list , sepby(which)
            
            set scheme s1color
            twoway rcap lb ub foreign || scatter mean foreign, by(which, yrescale note("") legend(off)) yla(, ang(h)) xsc(r(-0.2 1.2)) xla(0 1, tlc(none) valuelabel)
            [ATTACH=CONFIG]n1554943[/ATTACH]
            Thank you very much Mario, Stephen, Nick and Justin! Very helpful comments.

            Replies to Nick:
            Sorry I did not upload the data. I need to be clearer on my description: I use different y variables with the same code, but it generates too different graphs. I later found that it may be due to the horizontal setting as I specified in the update session at the end of #1. What is interesting is that the same horizontal setting will generate different margins on the left for different estimators. I have not sorted it out why. In addition to what is proposed above, one solution is to simply drop the "ylabel(, angle(horizontal))" command in my code.

            Thanks again for your suggestions!
            Best,
            Kailin

            Comment

            Working...
            X