incidence matrix

[Leonard Soicher]

On Wed, Sep 24, 2003 at 12:56:33PM +0100, Peter Dobcsanyi wrote:
> Hi,
> 
> It is likely to have transactions where the incidence matrix of a block
> design is requested. At the moment, we don't have definition for
> incidence matrices in the ext-rep, although "matrix" is defined but not
> used anywhere yet.
> 
> Q1: Should we define an incidence matrix structure in version 1.0?

Probably, yes, although incidence matrices (and other important matrices
and structures related to designs) are the sorts of things which can
be added quite straightforwardly in later versions.  

> 
> Here is a possible format:
> 
>     incidence_matrix = element incidence_matrix {
> 	attribute shape	{ "points_by_blocks" }
> 	matrix
>     }
> 
> Where matrix is the structure we already defined with its 'no_rows' and
> 'no_columns' attributes are set to 'v' and 'b' respectively.
> (Other matrices could be defined in a similar way when/if there is a
> need.)
> 
> Q2: Where should the <incidence_matrix> subtree go?
> 
> The incidence matrix, is also a representation of the design so when we
> have an incidence matrix in an ext-rep document we may not want the
> <blocks> subtree to be present. However, <incidence_matrix> should not
> be an alternative representation in equal rank to <blocks> since there
> are many other subtrees whose definitions are based on indexing or
> operating on <blocks>. Because of this consideration, <incidence_matrix>
> should not be in the same level as <blocks>.
> 

Agreed.

> There are other alternative representations of block designs we may want
> to include at some (probably later) stage. For example, incidence graph
> or orbit representatives. The introduction of these would raise the same
> question (Q2) and the related argument above.
> 
> To solve this problem, I suggest introducing a new subtree on the top
> level to accommodate <incidence_matrix> and likes. Here are a few
> possibilities for naming this subtree:
> 
>     <extensions>  - short, very general, could contain alternative reps.
>                     and also other stuff.
> 
>     <alternative_representations>
>                   - long, take cares of only alternative reps.
>     
>     <related_structures>
>                   - general, but many of the already existing top level
> 		    subtrees fall in this category.
> 

<alternative_representations> gets my vote.

> Going with <extensions> for the time being, the RNC schema for
> <block_design> would look like:
> 
[...]
> 
> Note, <blocks> has been made optional.
> 

I don't know about that! We want to be able to index the 
blocks, and at present we would require that the blocks be 
explicitly given. If the blocks are optional then there *must* 
be a canonical way of specifying the block list from any 
alternative representation (and at least one such representation
must be given if the blocks are not).
Whatever alternative representation might be used, we should
still think of the block design as being specified by a (specific, 
but possibly virtual) list of blocks. 
I vote against making <blocks> optional, at least in version 1.0.

> Q3: Is there anything else we should introduce now (version 1.0) under
>     the umbrella of <extensions>?
> 

No.

> My answers to the above questions are:
> 
>     Q1:	yes for incidence_matrix
>     Q2: in the format outlined above with <extensions>
>     Q3: for now, have only incidence_matrix
> 
> Could you, please, share your view on this,
> 
> --             ,
>     Peter Dobcsanyi
> 

Leonard