"unknown" and "not_applicable"

[John P. Morgan]

>Date: Mon, 21 Jul 2003 15:34:49 +0100 (BST)
>From: Leonard Soicher <l.h.soicher at qmul.ac.uk>

>
>I suggest that we need to think more clearly about when we 
>can and should use "unkown" and "not_applicable" as attribute 
>values. 
>
>For example, consider the the indicator <resolvable>.  This has an
>attribute called `value' which may be boolean, "unkown" or
>"not_applicable".  By stating "unkown" are we making a specific point
>that we don't know (and need help)?  If so, we may also want to allow
>value="unknown" for the indicator <partially_balanced> or the
>automorphism group property <multiplicity_free>.  Or should we just
>leave out certain optional tags when we don't know the answer (which
>may be difficult to compute).

Both of the above suggestions for "unkown" are reasonable. The explicit 
"unkown" is more in line with our general philosophy of "explicitness whenever  
possible" than is leaving out optional tags (an "implicit unknown"). Still, the 
latter is not a breach over which anyone could legitimately cry - otherwise, why 
was the tag optional? 


>
>Now what does "not_applicable" mean for resolvable? Either a block
>design is resolvable or it isn't. A t-(v,k,lambda) with v not divisible
>by k is *not* resolvable; we should not use "not_applicable" in this
>case.  We should be precise mathematically *and* explain what we are
>doing and why we have made the choices we have. Similarly, with
>natural and appropriate definitions, an intransitive permutation group
>is *not* primitive, *not* generously transitive and *not*
>multiplicity-free. (I forget what stratifiable means.) Permutation rank
>is naturally defined only for transitive groups, so for this property,
>the option "not_aplicable" makes sense.
>

The "not_applicable" for resolvable was decided during one of our Spring 
meetings for situations where it was not necessary to ask the resolvable 
question. It is true that
> A t-(v,k,lambda) with v not divisible by k is *not* resolvable;
The "not_applicable" was intended to say "the simple necessary conditions are 
not met" which again is more explicit than "false". Either v not divisible by k, 
or bk not divisible by v, would trigger "not_applicable". If this decision is to 
be changed now, presumably it is because this is deemed too large a burden of 
information to place on the widely used tag "not_applicable" for a special case.

I have been using "not_applicable" quite a bit for statistical properties, 
specifically for disconnected designs. If disconnected, then some pairwise 
variances are not estimable; the value "not_applicable" is given for the 
variance of any disconnected pair. Likewise some canonical variances do not 
exist (value="not_applicable") and some optimality values blow up (these could 
be reported as "infinity" but currently as given as "not_applicable" - yet 
another context-specific meaning for this tag).


JP