Ralf Hemmecke <[EMAIL PROTECTED]> writes:
> Yes, now AC can compute cycle index series of simple graphs up to order
> 6. [...] And believe it or not AC is now more correct than my version of
> BLL. There is an obvious typo in Z_{Graph}. They give a term
>
> 64/9 x_1^3 x_2
>
> for in the "degree 6" polynomial. AC computes x_3 instead of x_2.
cute. Well, Hornegger and Pirastu confirm AC...
> > Ja, wenn man bei n=7, i.e., 1044 Graphen mit 7 Knoten aufhört.
>
> So that doesn't make me too happy. :-(
Maybe it is possible to speed things up. Although Hornegger and Pirastu can go
much further, one has to keep in mind that they only implemented the formula,
and cannot do the general case.
I think you should stop here, what concerns functorial composition. There are
too many other interesting projects out there. If you really want to speed
things up, a profiler would be very nice. It's a pity, Axiom has a wonderful
profiler, but it only works for spad code. It says:
>> System error:
|aldorTrace| is invalid as a function.
In any case, I would like to send you (and again, Christian Aistleitner &
AldorUnit, indispensible for debugging) a big THANK YOU! YOu did a wonderful
job!
> But we have
> | | failing, because an exception occurred in the test function !
> | | Type:
> | | RuntimeError()
> | | Presentation:
> | | (Aldor error) Reached a "never"
> | |
> | | ----------------------
> | | calling tearDown function
> | | tearDown function finished
> | +--- end of test : testFunctorialCompose( test [31m[1mfailed[0m )
> and that looks like ... oh... no, the iso-type generation is wrong. Well, that
> is as expected.
Yes. That is another *huge* project. It would be nice to have a brute force
approach here. But to this end, I guess, we need to settle isomorphismtypes in
general first.
In fact, I think that functorial composition might be a heavy argument for your
approach to isotypes as representatives...
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...
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!
-------------------------------------------------------------------------------
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?
Martin
-------------------------------------------------------------------------
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
