indicators of statistical properties
John P. Morgan
jpmorgan at chef.stat.vt.edu
Sun Aug 3 22:31:59 BST 2003
Dear All,
Summary of this posting:
1. vote to place robustness_properties under statistical_properties
2. proposal to place partial_balance_properties as a branch of block_design at
the same level as both combinatorial_properties and statistical_properties
Discussion follows ....
On Wed, 30 Jul 2003 10:20:17 +0100
Peter Cameron <p.j.cameron at qmul.ac.uk> wrote:
>
>Yes, and pairwise balance (assuming we put it in), and partial balance. I
>take JP's point that statisticians invented (and still use) partial
>balance, but I think the majority of people interested in association
>schemes now are combinatorialists.
>
I agree with Peter's statement about association schemes, but not as the concept
of partial balance specifically applies to block designs.
I did a search on MathSciNet for all papers with the phrase "partially balanced"
for the years 1998-2003. This resulted in 20 citations, of which I classified 13
as stat (based on each paper's focus; statisticians like myself continue to
publish what we consider to be stat papers in math journal) and 7 as math. The
same search for the phrase "association scheme" produced >150 citations, too
much to classify, but it was easy to see the math predomination here. Much of
this is because association schemes are studied independently of block designs,
and because of the ties with codes, so that partially balanced block designs do
not directly come into the picture.
The ext-rep we are developing is about block designs. Our partial balance is for
partially balanced block designs, and so too the corresponding association
schemes. In our current context I suggest that the focus is on the partial
balance, and not independently on association schemes. Each partially balanced
block design has a specific variance pattern in the statistical analysis that
speaks directly to the structure of the treatments when considered as
experimental conditions. There are other combinatorial interpretations/uses of
PBIBDs, not necessarily falling under the heading "block design," but these may
better be reported elsewhere in a separate branch of a larger tree that we are
not yet developing.
On Wed, 30 Jul 2003 13:24:01 +0100
Peter Dobcsanyi <p.dobcsanyi at designtheory.org> wrote:
>Here is the new structure of <block_design>:
>
> block_design = element block_design {
> attribute id { xsd:ID } ,
> attribute v { xsd:positiveInteger } ,
> attribute b { xsd:positiveInteger } ,
> blocks ,
> point_labels ? ,
> indicators ? ,
> combinatorial_properties ? ,
> automorphism_group ? ,
> resolutions ? ,
> statistical_properties ? ,
> info ?
> }
>
>where the new <combinatorial_properties> is defined as:
>
> combinatorial_properties = element combinatorial_properties {
> point_concurrences ? ,
> block_concurrences ? ,
> partial_balance_properties ? ,
> t_design_properties ? ,
> alpha_resolvable ? ,
> t_wise_balanced ?
> }
This is a really nice reworking of the block_design structure, with a sensical,
non-disjoint set of primary branches. Leonard suggested in the posted
discussions of the past week that robustness_properties be placed under
statistical_properties. This has not yet been done, so here is a vote in favor.
For reasons given in the comments above, I disagree with the placement of
partial_balance_properties under combinatorial_properties. Placement should also
depend on what info, as yet unspecified, is to be reported under
partial_balance_properties. This needs to be specified, but the minimal
information should include the association matrices (or a pointer thereto) and a
description of the treatment structure the scheme respects (as RAB would show
via a Hasse diagram). This information is both combinatorial and statistical. In
concordance with the arguments (both ways) above, this supports the following
compromise: place partial_balance_properties as a branch of block_design at the
same level as both combinatorial_properties and statistical_properties. Final
placement may change depending on the public discussion, but my guess is that
this option will be attractive to many regardless of their perspective.
JP
More information about the Developers
mailing list