order

Peter Dobcsanyi p.dobcsanyi at designtheory.org
Mon Jul 28 17:02:58 BST 2003


On Mon, Jul 28, 2003 at 01:57:50PM +0100, Leonard Soicher wrote:
> As regards ordering, I believe we should adopt Peter D's option 2/a):
...
> I also believe that we should order when and only when there is a good
> reason to.  One good reason is to have a canonical form for an object.
> This is why we order a list of blocks, and should always order a
> function (but not a pseudo-function) via its list of preimages.  It
> makes little sense to order lists of designs or lists of resolutions
> since we are not choosing canonical representatives of isomorphism
> classes of designs or of resolutions. Thus an ordered list of pairwise

I agree with all said above.

> I list below some places where ordering is easy and might be of use.
> However, my inclination is *not* to force order in these cases

I feel the same way.

> other places) we should specify that no object be repeated.

Indeed such a specification is important regardless the particular
subtree is ordered or not.
I have placed a comment in the RNC file to remind us that this should
be consistently addressed case by case in the ext-rep documentation.

> (1) <cycle_type_representatives> could be ordered by 
>    the <cycle_type> of a <cycle_type_representative>
>    (so the list of cycle types is canonical, if not the 
>    representing permutations).
> 
> (2) <point_concurrences> is a list of 
>     <function_on_ksubsets_of_indices n= k= ...>s.  
>     We could order by "k".  Similarly with
>     <block_concurrences>.  Note that since we order only by "k" this 
>     does not imply that the <function_on_ksubsets>s themselves are ordered, 
>     and indeed need they may be collapsed and *not* be ordered.
> 
> (3) Whatever we end up calling <flag_entry>, we could order lists
>     of flag-entries via the <index> entries. This would include 
>     <alpha_resolvable> (ordered by alpha), and 
>     <t_wise_balanced> (ordered by t).

I suggest no to require ordering of any of these therefore using no
"ordered" attributes here.

--             ,
    Peter Dobcsanyi




More information about the Developers mailing list