indicators of statistical properties

[Leonard Soicher]

Dear All,

JP wrote:

>
>Before addressing this, why don't we have an indicator for "pairwise balanced" 
>(true if all the 2-concurrences for distinct treatments are equal)? Is this 
>because of "t-design properties"? 
>

The pairwise balanced property is covered in the t-wise balanced "flag entry":

t_wise_balanced = element t_wise_balanced {
    flag_entry +
}

Perhaps <pairwise_balanced> should be an indicator as well if it is
considered important enough (but I am starting to worry that the rnc
will get bloated). Indeed, where is the indicator for BIBD?  A t_design
(with t>=2) is not exactly the same as a BIBD since the blocks may be
complete in a t-design.  Maybe what we really (only) need is an
indicator <complete> (true iff all blocks are complete).  We may never
get the balance (ha ha) completely right, but we really must decide.

[...]

>The two above, plus the indicator     
> "element partially_balanced" 
>all stand on more or less the same footing. VB and PB are entirely properties of 
>the information matrix, and EB of the weighted information matrix (being 
>essentially different only for unequally replicated designs). VB and EB are 
>easier to determine, and the information required to do so is already in 
>"statistical properties." PB is a tougher nut: we have no general method to 
>determine this. 

Peter Cameron and I have discussed an algorithm for determining the PB property.

>I am reluctant to separate the three, but believe that some 
>others may be reluctant to place PB in "statistical properties." 

We have in fact already made a reservation for partial balance properties 
to go on their own:
   partial_balance_properties = element partial_balance_properties { empty }

And also robustness properties:
   robustness_properties = element robustness_properties { empty }
which presumably should go under statistical properties.  

>Stepping back a bit, this issue makes me wonder why we have "statistical 
>properties" but not "combinatorial properties." The entire tree would be more 
>sensical if the latter was included. This also highlights the nature of the 
>separation problem in the previous paragraph: is PB a statistical or a 
>combinatorial property? In my mind (maybe not all others') the answer is clear: 
>PB was invented for a statistical purpose, and even though oft studied  without 
>reference to the original purpose, still has no real other reason for being. 
>Thus it is a statistical property.
>

Why not keep PB properties on their own? (I know this doesn't solve 
the problem of where the PB indicator should go).

>My recommendations:
>1. Add "combinatorial properties" as a high-level branch
>2. Place VB, EB, and PB in "statistical properties"  
>3. Add "pairwise_balanced" in "combinatorial properties"
>

Should we then have an "indicators" section for each main branch 
of properties? Or remove the concept of indicators? Or just have
indicators at the highest level for a summary of all the main 
(boolean) properties of a design? I am reluctant to 
change the present setup too much or too quickly. Some properties
(like PB I suggest) cut across boundaries, and what category do "cyclic" 
and "one_rotational" fall into? 

Regards,  Leonard