Block designs: duality etc.
Peter Dobcsanyi
p.dobcsanyi at qmul.ac.uk
Fri Apr 25 18:38:00 BST 2003
On Wed, Apr 16, 2003 at 09:58:01AM +0100, Peter Cameron wrote:
> Here are three representations of a block design. The elements of the block
> design are treatments (or points), blocks, and plots (or flags).
...
> The third model is most convenient for storage, and is the one most commonly
> used by mathematicians. But the first model is closest to the use in
> experimental design (where the set of experimental units often comes
> partitioned into blocks, and the experimenter introduces another partition by
> applying treatments to the blocks.
I propose to call them "stats", "graph" and "maths" model respectively.
> I propose that questions about what to permit in a block design can best be
> answered by going back to the first model. Let us look at a few.
...
Although the external representation for blockdesigns are based on the
maths model, Peter's post has made me think that we should include some
support for the other models too. In particular, I can imagine that a
statistician would prefer to express a query in terms close to the stats
model then receive the system's reply in similar form. While the
automatic conversion is not difficult, it is complex enough that I would
not like to implement it in a Web interface.
Another example for the graph model. I am adapting my pynauty/noniso
package to the new external representation. What happens internally in
the program before calling nauty's subroutines is a conversion from
maths model to stats model. Now if I want/need to decouple completely
the pynauty process from noniso then the communication should, of
course, use the external representation. Then it would be nice to
interchange information about the design expressed in the graph model so
pynauty would not need to know anything about designs.
I am not suggesting to bloat the current ext. repr. out of proportion,
just to provide something in terms of the stats and graph model for the
"core" that is 'v' and 'blocks'.
---
,
Peter Dobcsanyi
More information about the Developers
mailing list