Re: st: issues using the user-written program tabout

[Eric Booth <ebooth@ppri.tamu.edu>]

<>


My guess is that the variable list in -tabout- is limited to the string char limit of 244 characters, though I can't tell where this occurs from the source of tabout.ado.  

I've tested it with increasingly longer varlists (in terms of characters, not variables) and -tabout- always breaks when I hit the 244 barrier (sample code below) -- so, I've always just assumed the macro varlist in -tabout- is, at some point, converted to a string (and therefore truncated) as it's passed through the program.

My solution has always been to just break it up into numerous -tabout- commands and append them together.   So, you could change your second command to:

************
tabout  side_indicator-MidpointVariableHere   paid_total_cat using tabletest.txt, ///
 ... <all your options> ....   ///
npos(tufte)   replace

tabout  NextVariableAfterMidpoint-skin_indicator   paid_total_cat using tabletest.txt, ///
... <all your options> ...   ///
npos(tufte)    append
************

and this will stack the tables together in one file (though it will add a new header row). 
 If you want to avoid the new header row, you could also shorten (-rename-) your variable names to stay under the 244 character limit.  

Test the length of your varlist with:
**********
unab varlist: side_indicator-skin_indicator
di "`varlist'"
local length:length local varlist
di "`length'"
*********




Finally, here's some code (mentioned above) to show an example of -tabout- breaking once your pass the 244 char barrier:

************************!
sysuse auto, clear

unab varlist: mpg-for
di "`varlist'"
local length:length local varlist
di "`length'"

qui {
tabout  `varlist' using "tabletest.txt", ///
sum c(mean for) ///
npos(tufte) replace
}


**longer varlists**
forval n = 1/16 {
g newvariable`n'  = 1
	
unab varlist: mpg-newvariable`n'
di in yellow "`varlist'"
local length:length local varlist
di in red "Length:  `length'"

qui {
tabout  `varlist' using "tabletest.txt", ///
sum c(mean for) ///
npos(tufte) append
}
	}
************************!

- Eric
__
Eric A. Booth
Public Policy Research Institute
Texas A&M University
ebooth@ppri.tamu.edu
Office: +979.845.6754


On Oct 7, 2010, at 5:10 PM, Jordan H wrote:

> Dear all,
> 
> I am trying to create a two way table with the levels of  binary
> outcome variable (paid_total_cat) as the columns and the levels of
> numerous of predictor variables as the rows.  I have used the
> following command to produce such a table for the predictor variables
> "thigh_upperleg_indicator" through "rib_indicator."
> 
> tabout  thigh_upperleg_indicator-rib_indicator paid_total_cat using
> tabletest.txt, ///
> sum c(mean paid_total_adjusted sd paid_total_adjusted min
> paid_total_adjusted p25 paid_total_adjusted p50 paid_total_adjusted
> p75 paid_total_adjusted max paid_total_adjusted) ///
> style(tex) font(bold) h3(nil) body f(2cm 2cm 2cm 2cm 2cm 2cm 2cm)
> npos(tufte) replace
> 
> The above command works perfectly and gives me what I want.  I also
> want to make an identical table using a different list of variables so
> I use the following command:
> 
> tabout  side_indicator-skin_indicator paid_total_cat using tabletest.txt, ///
> sum c(mean paid_total_adjusted sd paid_total_adjusted min
> paid_total_adjusted p25 paid_total_adjusted p50 paid_total_adjusted
> p75 paid_total_adjusted max paid_total_adjusted) ///
> style(tex) font(bold) h3(nil) body f(2cm 2cm 2cm 2cm 2cm 2cm 2cm)
> npos(tufte) replace
> 
> The two commands are identical (aside from the predictor variables
> that are included in the list) but the second command gives me the
> error message:  "paid_total_ ambiguous abbreviation
> r(111);"
> 
> Since the predictor variables are what changes between the two
> commands, I'm assuming the new variables must be causing the issue.
> That being said, I've even gone so far as to manually write out all
> the variables that are referenced by the statement
> "side_indicator-skin_indicator" but that doesn't fix the problem.  I
> have also used "set trace on" to try to pinpoint the issue but the
> programming used within tabout is far too complicated for my skill
> level.  Here is the snippet of the trace output where the error
> occurs...perhaps you have a better grasp of what is going on within
> the program.
> 
>   ------------------------------------------------------------------------------------------------
> end tabout.sum_write ---
>  - }
>  - }
>  - else if $do_svy==1 {
>  = else if 0==1 {
>    if $oneway==1 local hvar = "_xx_ph_xx_"
>    if ($do_sum==0) svy_mat `v' `hvar' `svycat' `svylevel' `svyporp' `touse'
>    else svy_sum `svy_sumvar' `v' `hvar' `svylevel' `colmat' `touse'
>    do_write `v' `hvar' "`format'"
>    }
>  - global fpass = 0
>  - }
>  - local vvarname : variable label `v'
>  = local vvarname : variable label paid_total_
> paid_total_ ambiguous abbreviation
> <------------------- here is the error
>    if ("`vvarname'"=="") label var `v' "`v'"
>    local vtype : type `v'
>    if (substr("`vtype'",1,3)=="str") {
>    capture encode `v', gen(_`v'_x)
>    local v = "_`v'_x"
>    global dropv = "$dropv `v'"
>    }
>    if ("`v'"=="`lastvar'") global lpass = 1
>    if $do_svy==0 {
>    if $oneway==1 local hvar = "_xx_ph_xx_"
>    if ($do_sum==0) {
>    do_mat `v' `hvar' `weightstr1' `weightstr2' `colmat' `touse'
>    do_write `v' `hvar' "`format'"
>    }
>    else {
>    if ($oneway==0) sum_twoway `v' `hvar' `weightstr1' `weightstr2'
> `colmat' `statkind' `statvar' `touse'
>    else sum_oneway "`cells'" `v' `weightstr1' `weightstr2' `touse'
>    sum_write `v' `hvar' "`format'" "`cells'"
>    }
>    }
>    else if $do_svy==1 {
>    if $oneway==1 local hvar = "_xx_ph_xx_"
>    if ($do_sum==0) svy_mat `v' `hvar' `svycat' `svylevel' `svyporp' `touse'
>    else svy_sum `svy_sumvar' `v' `hvar' `svylevel' `colmat' `touse'
>    do_write `v' `hvar' "`format'"
>    }
>    global fpass = 0
>    }
>  ------------------------------------------------------------------------------------------------------------
> end tabout ---
> r(111);
> 
> 
> 
> Does anyone have any insight into this issue?
> 
> Thanks for the consideration,
> Jordan
> 
> *
> *   For searches and help try:
> *   http://www.stata.com/help.cgi?search
> *   http://www.stata.com/support/statalist/faq
> *   http://www.ats.ucla.edu/stat/stata/



*
*   For searches and help try:
*   http://www.stata.com/help.cgi?search
*   http://www.stata.com/support/statalist/faq
*   http://www.ats.ucla.edu/stat/stata/