Storing (E-)optimal designs

[Leonard Soicher]

Dear All,

One purpose of my proposals is so that we can make useful assertions about
the content of a directory in the "Readme.html" file of that directory
(see, for example, the assertions made about the files in the "v-b-k"
directory (the blurb before the table of files)).  If we decide later
that there is good reason to abandon one or more of the proposals for
that directory then the "Readme.html" file would have to be changed (not
the end of the world). However, if many people are contributing to a
directory it might become dangerous to trust assertions in a Readme.html.

I was also hoping that we could have some uniformity in the information
given across all the files in our database of designs.  It is specifically
because we have the software to determine many properties of designs and
to order the designs within a file that we should consider what we want to
do in general and what are the minimal requirements for files in each
specific directory.  Don't forget that many people will be using our
files who won't set up or want to bother with our software, and I want
the files on their own to be as usable as possible (i.e. contain as much
information as is reasonably possible).

I am not married to using the phi_1 criterion for ordering (or indeed
to specifying any ordering for files), but I had believed that phi_1
was a criterion of interest.

I do believe that we should adopt the `m' content indicator as proposed
earlier by JP.

So here is my revised proposal for the v-b-k-E directory: 

Each file in the v-b-k-E directory must have content indicator type
`s', and it is highly desirable also to have `i', `c', `g', and if
possible, `a', and if `a' is not possible then `m' if this is possible.
Moreover, it is desirable to determine whether each design is resolvable,
and if so, to give a representative from at least one equivalence class
of resolutions.

Regards,  Leonard

On Mon, Oct 11, 2004 at 11:31:01AM -0400, J P Morgan wrote:
> >
> >Proposals:
> 
> > Each file in the v-b-k-E directory should have content
> >types i, c, g and s, and if possible, a.
> > Moreover, at least one (or
> >preferably all) equivalence class(es) of resolutions of each design
> >(when it is resolvable) should be stored.
> > Finally, within each file,
> >I propose that the designs be ordered in non-decreasing order of
> >statistical_properties/optimality_criteria/phi_1/value.
> >
> 
> All of these seem fine as preferences, but not  necessarily as requirements. 
> Especially the ordering by phi_1 is arbitrary, so why bother? As a policy that 
> encourages contribution, files in a directory should of course be required to 
> contain the information that the directory is designed to report, but any 
> further requirements should be chosen with care, based either on a real 
> necessity to the problem at hand, or on a relevant philosophy guiding the 
> creation of the list. An example of the latter may be to require several basic 
> statistical properties for a list designed for a particular statistical 
> property. But even then, with a statistical expander available, constricting 
> and ordering files in a list seems to create work with no real addition of 
> value. For phi_1 in particular, it is worth noting that both statisticans 
> among the developers have stated in print that phi_1 plays a subsidiary role 
> to other considerations.
> 
> JP
> 
> 
> _______________________________________________
> Developers mailing list
> Developers at designtheory.org
> http://designtheory.org/cgi-bin/mailman/listinfo/developers