[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]
Re: st: svy regress Stata 9 vs Stata 8
Robert Duval <email@example.com> asks about speed and decimal precision of the
old -svy- commands and the new -svy- prefix introduced in Stata 9:
> I recently started working with Stata9 and while using svy: regress I
> noticed it runned slower than it's counterpart (svyregress) in Stata8.
> Also the decimals reported in the standard errors differ slightly
> across versions.
> Could anybody explain to me what's going on?
> The speed issue is not related to the hardware i'm working on. The
> machine i'm using is highly efficient (school's property) and when I
> do the analysis with version control (8.2) the output is generated
> much faster (45 secs on Stata9 vs. 7 secs. on Stata8).
> Also why should there be any change in the reported se's? I mean, is
> this an upgrade in accuracy? Shouldn't the linearized s.e. reported
> under Stata9 be the same as the one reported on previous versions?
The only difference between the older -svyregress- and -svy: regress- is the
engine used to compute the linearized variance estimates.
The old -svyregress- can only handle survey design information from the first
stage. -svyregress- uses -_robust-, an internal command written in C and
optimized for the single stage linearized variance calculation.
The new -svy: regress- can handle multiple stages of clustered sampling, among
many other new features such as poststratification. -svy: regress- uses
-_robust2-, a command written using Mata that perform linearized variance
calculations for any number of stages.
There are two reasons for the difference in speed between -svyregress- and
1. Compiled code written in C is faster than Mata, although compiled Mata
code is very fast compared to interpreted Stata code.
2. General purpose code tends to be slower than code written to take
advantage of a special case.
As for the difference in precision of the standard errors, they should be
negligible. I believe -_robust- and -_robust2- are using different matrix
inversion routines; this could explain the slight difference in numerical
* For searches and help try: