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