indicators

[John P. Morgan]

For some unknown reason, I did not receive Leonard's reply to my email about 
indicators, but have since read it on the list. This is a response using cut and 
paste from the webpage - it likely will not catalog correctly in the list.

>Are you suggesting an indicator for each possible t???

I did not suggest an indicator for each t. I suggested changing the indicator to 
drop the requirement of equiblocksize, which is contained in a separate 
indicator. Then the name would be changed to "t-wise balanced" in accordance 
with standard usage of that term (see, eg, chapter 49 of CRC Handbook of Comb 
Des). As currently formulated, the indicator also reports the maximal t. That 
would, in my suggestion, remain. Unless I have missed something, there is no 
mention in the ext rep of t-wise balance, only t-designs.  t-wise balance is a 
more general concept. 

>> Reasoning:  We have a separate indicator for
>> constant_blocksize.  Why combine information for several
>> properties in a single indicator when each property has
>> independent interest?  I would like to suggest in general
>> that indicators better carry the intent of reporting
>> fundamental information if they refer to single properties
>> rather than collections of properties.
>> 

>I agree with this principle, but believe we are handling 
>t-wise balance and the t-design property correctly in the 
>current ext-rep. 

I am not talking about the t-design property alone. This is about the more 
general concept of t-wise balance. Currently the former is indicated, but not 
the latter. Notationally, if I_A means indicator of property A, then we 
currently have I_A and I_{A&B}, where A=constant_blocksize and B=t-wise_balance. 
The problem is that we cannot recover I_B from this information. The suggestion 
is to instead use I_A and I_B, from which we *can* recover I_{A&B}. More 
generally, if we have I_{A&B&C}, we would prefer to have I_A, I_B, and I_C 
separately if each individual property is of interest, and so on for >3 
properties.

>> 2.  Add the indicator "affine":  true if and only if any two
>> nonparallel blocks meet in the same number \mu of points.
>> Analogous to the t-wise balance indicator, include the value
>> of \mu.
>> 

>We could do this, although this "affine" indicator information is already
>contained in the (pairwise) block_concurrences. 

The information to calculate this property is there, but that is not the point 
(the information to calculate what is needed for most of the indicators can be 
found elsewhere). The point of an indicator is to indicate whether or not a 
fundamental property holds. The value of this particular property is partially 
seen in the sketch of reasons below.

> Reasoning:  aside from intrinsic interest, this allows other
> important properties to be deduced from the set of
> indicators.  For example,
> affine+resolvable+constant_blocksize is equivalent to an
> orthogonal array of strength 2 and index \mu.  If 2-wise
> balance also holds and \mu=1, then the design is equivalent
> to a complete sets of MOLS, etc, etc.

These seem to me to be pretty strong reasons. Not only is affineness explicitly 
seen, but other indicators becomes more useful. Do you disagree?

>> 
>> 3.  Change the definition of "partially_balanced" to the
>> following:  true if and only if the diagonal of the
>> information matrix is constant, and the off-diagonal
>> elements have values that follow an association scheme.
>> This is equivalent to saying that the information matrix is
>> in the Bose-Mesner algebra.
>> 


>I would like feedback from RAB and PJC on this.

It would be great to hear their thoughts and your thoughts, too!

JP