higher moments

[benthestatistician]

Calculate higher moments of covariate imbalances, for use in balT() to improve/enhance the omnibus test.

• alt version of alignedToInferentials() to figuring second moments by calculating an S by K by K array of within-stratum covariances as well as S stratum-wise multipliers, then multiplying and taking sums.
• cross-check the above against existing version
• tidy up the code to figure the stratum-wise multipliers. Compare against Finucan, and insert parallel code for stratum-wise multipliers of 3rd and 4th moments.
• Is a Sattherwaite-type chi-square approx possible for any combination of positive means and variance, or are there conditions?
• Code up the d.f. calculation as a function of the 1st and 2nd moment; code basic tests.
• Basic vs corrected p-vals for the Hansen-Bowers statistic (as opposed to the new variants we've been discussing)
• ...

[benthestatistician]

Two suggestions about the StratifiedDesign class definition, as it presently stands:

1. Rename "Treated" slot as "Condition".
2. To accommodate multilevel treatments, define class extensions in which this Condition slot to be a k by c -1 integer matrix, where k is the number of strata and c is the number of conditions.

Rationale for no 1: Treatment vs control metaphor applies better to some studies than others; even when it does apply, in cases with noncompliance "treated" suggests the subgroup of a treatment group who complied.

Comment on no 2: With ordinal treatments, the columns of the k by s condition matrix might encode stratum-wise numbers of assignment units at or above treatment levels 1, 2, etc. With nominal treatments, they might encode numbers of assignment units within each of these levels. In both cases these would presumably be class extensions.

(Not sure where we are w.r.t. sequence of tasks laid out in the issue statement. If Mark has been following a different path then the issue statement can be updated.)

[jwbowers]

I like this suggestion. Jake Bowers http://jakebowers.org

…

On Wed, Oct 7, 2020 at 6:21 AM Ben ***@***.***> wrote: Two suggestions about the StratifiedDesign class definition, as it presently stands: 1. Rename "Treated" slot as "Condition". 2. To accommodate multilevel treatments, define class extensions in which this Condition slot to be a *k* by *c -1* integer matrix, where *k* is the number of strata and *c* is the number of conditions. Rationale for no 1: Treatment vs control metaphor applies better to some studies than others; even when it does apply, in cases with noncompliance "treated" suggests the subgroup of a treatment group who complied. Comment on no 2: With ordinal treatments, the columns of the *k* by *s* condition matrix might encode stratum-wise numbers of assignment units at or above treatment levels *1*, *2*, etc. With nominal treatments, they might encode numbers of assignment units within each of these levels. In both cases these would presumably be class extensions. (Not sure where we are w.r.t. sequence of tasks laid out in the issue statement. If Mark has been following a different path then the issue statement can be updated.) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#113 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAELETF4Y6GV4WWQZYMD4ITSJRFJ5ANCNFSM4J4FGLVQ> .

[markmfredrickson]

1. Makes perfect sense.
2. I agree with the basic idea. It might be better to merge the current Treated and Count into a k by c matrix.

[benthestatistician]

Thanks, Jake and Mark. I quite like the idea of combining Treated and Count into the a k by c matrix. Modifying my earlier suggestion a bit, particularly as regards ordinal treatments, we might just have this be the two-way, strata-by-condition crosstab. So that for binary, nominal and ordinal designs alike, stratum countss are recoverable as row sums.

Or perhaps it's a little better to have it be a c by k matrix, recovering stratum totals as column sums. Since k can be 1, but c is always at least 2. The name "Condition" also fits a little better.

As a separate matter, don't these classes, RandomizedDesign and classes extending it, call for cluster identifiers of some type? Seems to me the tidy and modern approach would be to have a Keys slot consisting of a data frame providing one or more key variables, as opposed to insisting on baking this information into the names of a vector or row names of a data frame.

[markmfredrickson]

My thinking on clusters is that we would have a ClusteredDesign object. This would have have a units to clusters look up table to do aggregation, and then dispatch the actual methods to the relevant RandomizedDesign object.

[benthestatistician]

Thanks. Is there a unit/cluster ID of some kind in the StratifiedDesign class, or were you thinking of doing without in this class?

[markmfredrickson]

I've been treating it as implicit in the `Units` slot (which maps a unit to its stratum), so just using matrix/data.frame row order.

…

On Thu, Oct 8, 2020 at 2:54 PM Ben ***@***.***> wrote: Thanks. Is there a unit/cluster ID of some kind in the StratifiedDesign class, or were you thinking of doing without in this class? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#113 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAX7AT2VBDVMHI4Q3FA2VLSJYDFPANCNFSM4J4FGLVQ> .