> In fact, I think that functorial composition might be a heavy argument for
> your
> approach to isotypes as representatives...
Ah. Finally, you begin to agree with me. ;-)
> Consider Graphs:
>
> P[P2 [1,2,3,4]] =
>
> P[12, 13, 14, 23, 24, 34] =
>
> ()
>
> (12) (13) (14) (23) (24) (34)
>
> (12 13) (12 14) (12 23) (12 24) (12 34) (13 14) (13 23) (13 24) (13 34)
> (14 23) (14 24) (14 34) (23 24) (23 34) (24 34)
> Now, how are we going to represent isotypes of graphs? We raised that
> question
> already once: simply replacing labels with dots does not work...
Yep. If people draw unlabelled graphs they take some "positions" and
then draw the edges that belong to the graph. But, hey, "positions" must
be distinguishable. So they are labelled in some sense although you
don't actually see a label. One can think of the (x,y) coordinates as
their labels.
> So, maybe we could have
>
> structures: (Tuple SetSpecies L, Tuple Boolean) -> Generator %
>
> where the second - optional - argument indicates which variables should be
> generated "unlabelled". I must admit that I don't like that either. But at
> least it takes away the burden to generate labels!
I don't understand what you mean by "generate labels" if you look at the
current signature of isomorphismTypes you find
SetSpecies L -> Generator %
the same as for "structures". There is no need to generate (extra)
labels. But you probably rather want
Integer -> Generator %.
Then you would need a function "elements: Integer -> Generator L" which
generates exactly the number of labels you need.
> -------------------------------------------------------------------------------
>
> In a private mail you suggested to define
>
> CombinatorialSpecies: L: LabelType -> T: Tuple(L) ->
> CombinatorialSpeciesCategory(L)(T)
>
> I do not understand: a CombinatorialSpecies takes a LabelType and produces a
> function from Tuple L to CombinatorialSpeciesCategory(L)(T)? Maybe you could
> give a possible signature for structures and a type for generatingSeries?
Forget about that. I rather meant
MultisortSpecies: (L: Tuple LabelType) -> MultiSortSpeciesCategory L.
Or maybe replace Tuple by Array.
The reason for this structure is that I want functorial composition to
be simple. Look at the definition of functorial composition as we have
it now. You find
FunctorialCompose(
F: SPECIES,
G: SPECIES
)(L: LabelType): CombinatorialSpecies(L) == add {
Rep == F G L;
import from Rep;
<<implementation: FunctorialCompose>>
}
Now my vision for multisort functorial compose is
macro MSPECIES==(L: Tuple LabelType)->MultisortSpeciesCategory L;
FunctorialCompose(
F: MSPECIES,
G: Tuple MSPECIES
)(L: Tuple LabelType): MultisortSpeciesCategory L == add {
Rep == F(G1(L), G2(L), ..., Gn(L));
...
}
Of course, it does not exactly work as above, but it should be *very*
close to it. In order to resolve the (G1,...,Gn), it would be perhaps
worthwhile to think of a function
Integer -> MSPECIES
instead of
Tuple MSPECIES
So perhaps
macro MSPECIES==(L: Integer->LabelType)->MultisortSpeciesCategory L;
FunctorialCompose(
F: MSPECIES,
G: Integer -> MSPECIES
)(L: Integer -> LabelType): MultisortSpeciesCategory L == add {
Rep == F((n: Integer) +-> G(L n));
...
}
could be extended to some working code. (All modulo the hope that the
Aldor compiler doesn't produce trash from that really heavy definition.)
Ralf
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Aldor-combinat-devel mailing list
Aldor-combinat-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/aldor-combinat-devel
