Bookmark and Share

Notice: On April 23, 2014, Statalist moved from an email list to a forum, based at statalist.org.


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From   Eric Booth <[email protected]>
To   "[email protected]" <[email protected]>
Subject   Re: st: issues using the user-written program tabout
Date   Fri, 8 Oct 2010 19:10:42 +0000

<>


Nick Cox provided me a tip on how to diagnose the problem in -tabout- that was limiting the varlist length to 244 chars.  
Using this information, I think the problem (bug?)  lies in this section of tabout.ado where the varlist is passed to local vvar like this:
***
    tokenize `varlist'
    local n = `nvars'-1
    forval i = 1/`n' {
        local vvar = "`vvar' ``i''"
    }
***

My guess is that this is where the varlist is truncated because the local vvars is stored using the equal sign (so, it's stored as an exp).  
To test this idea, here's this section of code run with and without the equal sign:


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

**add more vars**
forval n = 1/20 {
	g newvariable`n' = 1
	}


**run same way as in tabout.ado**

unab varlist:make-newvariable20
    local nvars : word count `varlist'
    local n = `nvars'-1
        tokenize `varlist'
    forval i = 1/`n' {
        local vvar = "`vvar' ``i''"
        local length:length local vvar
        di in red "`vvar'"
        di in yello "`length'"
    }
		
        di "`vvar'"


**this time without the equal sign in local vvar**
    forval i = 1/`n' {
        local vvar  "`vvar' ``i''"
        local length:length local vvar
        di in red "`vvar'"
        di in yello "`length'"
    }
		
        di "`vvar'"
	**this works**
***********************!

I'm not sure if changing the way `vvar' is stored would change anything else in Ian Watson's programming, but if this is all that's holding -tabout- back from running a full varlist (which is a persistent irritation -- at least for me), would it be appropriate to contact him about making a change to -tabout-?     -which tabout- indicates that it hasn't been updated since 2007, so I don't know if he's still maintaining it or not?

- Eric

__
Eric A. Booth
Public Policy Research Institute
Texas A&M University
[email protected]
Office: +979.845.6754
Fax: +979.845.0249
http://ppri.tamu.edu



On Oct 8, 2010, at 12:54 PM, Nick Cox wrote:

> Look at statements like 
> 
> local vvar = 
> 
> Nick 
> [email protected] 
> 
> 
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of Eric Booth
> Sent: 08 October 2010 15:29
> To: <[email protected]>
> Subject: Re: st: issues using the user-written program tabout
> 
> <>
> 
> 
> 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
> [email protected]
> 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/


© Copyright 1996–2018 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   Site index