Compute replicate weights from a survey design. These functions are
usually called from as.svrepdesign
rather than directly
by the user.
1 2 3 4 5 6 7 8 9 10 11 12  brrweights(strata, psu, match = NULL,
small = c("fail","split","merge"),
large = c("split", "merge", "fail"),
fay.rho=0, only.weights=FALSE,
compress=TRUE, hadamard.matrix=NULL)
jk1weights(psu,fpc=NULL,
fpctype=c("population","fraction","correction"),
compress=TRUE)
jknweights(strata,psu, fpc=NULL,
fpctype=c("population","fraction","correction"),
compress=TRUE,
lonely.psu=getOption("survey.lonely.psu"))

strata 
Stratum identifiers 
psu 
PSU (cluster) identifier 
match 
Optional variable to use in matching. 
small 
How to handle strata with only one PSU 
large 
How to handle strata with more than two PSUs 
fpc 
Optional population (stratum) size or finite population correction 
fpctype 
How 
fay.rho 
Parameter for Fay's extended BRR method 
only.weights 
If 
compress 
If 
hadamard.matrix 
Optional usersupplied Hadamard matrix for

lonely.psu 
Handling of noncertainty singlePSU strata 
JK1 and JKn are jackknife schemes for unstratified and stratified
designs respectively. The finite population correction may be
specified as a single number, a vector with one entry per stratum, or
a vector with one entry per observation (constant within strata).
When fpc
is a vector with one entry per stratum it may not have
names that differ from the stratum identifiers (it may have no names,
in which case it must be in the same order as
unique(strata)
). To specify population stratum sizes use
fpctype="population"
, to specify sampling fractions use
fpctype="fraction"
and to specify the correction directly use
fpctype="correction"
The only reason not to use compress=TRUE
is that it is new and
there is a greater possibility of bugs. It reduces the number of
rows of the replicate weights matrix from the number of observations
to the number of PSUs.
In BRR variance estimation each stratum is split in two to give halfsamples. Balanced replicated weights are needed, where observations in two different strata end up in the same half stratum as often as in different halfstrata.BRR, strictly speaking, is defined only when each stratum has exactly two PSUs. A stratum with one PSU can be merged with another such stratum, or can be split to appear in both half samples with half weight. The latter approach is appropriate for a PSU that was deterministically sampled.
A stratum with more than two PSUs can be split into multiple smaller strata each with two PSUs or the PSUs can be merged to give two superclusters within the stratum.
When merging small strata or grouping PSUs in large strata the
match
variable is used to sort PSUs before merging, to give
approximate matching on this variable.
If you want more control than this you should probably construct your
own weights using the Hadamard matrices produced by hadamard
For brrweights
with only.weights=FALSE
a list with elements
weights 
twocolumn matrix indicating the weight for each halfstratum in one particular set of split samples 
wstrata 
New stratum variable incorporating merged or split strata 
strata 
Original strata for distinct PSUs 
psu 
Distinct PSUs 
npairs 
Dimension of Hadamard matrix used in BRR construction 
sampler 
function returning replicate weights 
compress 
Indicates whether the 
For jk1weights
and jknweights
a data frame of replicate
weights and the scale
and rscale
arguments to svrVar
.
Levy and Lemeshow "Sampling of Populations". Wiley.
Shao and Tu "The Jackknife and Bootstrap". Springer.
hadamard
, as.svrepdesign
,
svrVar
, surveyoptions
1 2 3 4 5 6 7 8 9 10 11 12 13  data(scd)
scdnofpc<svydesign(data=scd, prob=~1, id=~ambulance, strata=~ESA,
nest=TRUE)
## convert to BRR replicate weights
scd2brr < as.svrepdesign(scdnofpc, type="BRR")
svymean(~alive, scd2brr)
svyratio(~alive, ~arrests, scd2brr)
## with usersupplied hadamard matrix
scd2brr1 < as.svrepdesign(scdnofpc, type="BRR", hadamard.matrix=paley(11))
svymean(~alive, scd2brr1)
svyratio(~alive, ~arrests, scd2brr1)

Questions? Problems? Suggestions? Tweet to @rdrrHQ or email at ian@mutexlabs.com.
All documentation is copyright its authors; we didn't write any of that.