Hi Martin,
> Ralf, I suggest that you (or me, if you like) merge the docs I have written
> for
> Compose in iso-experiment, with trunk. THe outline of the algorithm for
> isotypes in trunk is outdated.
You certainly refer to the outline I have given in ToDo33(rhx22). And
your documentation for isomorphismTypes of Compose is the following?
-------------------
It is very unlikely that there is a good algorithm to unrank a
composition of
two species in general. See the email of Nicolas Thiery,
\url{http://www.mail-archive.com/aldor-combinat-devel%40lists.sourceforge.net/msg00133.html}.
However, it is possible to generate efficiently all
\adname{isomorphismTypes}:
\begin{itemize}
\item generate a multiset partition $\pi$ of the input set $U$, written as
a multiset.
\item for each block $p$ with multiplicity $n_p$ of $\pi$, generate a
multiset
$M_p$ of cardinality $n_p$ of isomorphismtypes of $G[p]$. Note that
$G$-isomorphismtypes corresponding to different blocks are necessarily
different.
\begin{ToDo}
\begin{mrx}
18-Mar-2007: is this really true? Is the wording correct? How
about the
cardinality species?
\end{mrx}
\end{ToDo}
For this step it would be useful to be able to generate isomorphismtypes
given a generator only.
\item generate an isomorphismtype of $F[M_1,M_2,\dots]$
\end{itemize}
-------------------
To be honest, I do not really understand why this is an algorithm to
generate the isomorphism types of Compose. If you want to convince me,
you have to be more precise.
Anyway, we seem to be in total disagreement with respect to the
representation of isomorphism types.
Martin's approach:
------------------
Introduce a new type that represents the isomorphism types.
Make all labels indistinguishable.
Ralf's approach:
----------------
Consider isomorphism types of F as elements of F[n]/~ where ~ is the
equivalence w.r.t the isomorphisms S[n]. Those elements are actually
sets and one (canonical) representative is chosen.
>>From a mathematical perspective, Partition L and MultiSet L are close
> relatives, as you have noticed. However, I do not want to see
> isomorphismTypes: Partition L -> Generator %
> in trunk.
Well, that is very constructive. :-( I don't claim that I have the best
signature. Partition L just was what came to my mind and should work
quite well. Multiset would probably be a better name and perhaps even
fit better, but that would be Multisets in the sense of BLL. I don't
want to remove the labels. So translating 'Partition L' to a multisort
environment, I would (approximately) want to have
isomorphismTypes: Multiset(SetSpecies L) -> Generator %
for some (unisort) species F. So just replace 'Partition L' in the above
signature. But all that is not well enough thought of.
As it seems that my ideas of Multisort species maybe generic enough, but
they also seem to introduce overhead for situations like Compose of
unisort species.
Sorry, that I have not opened up a multisort branch, but it is currently
a total mess. Maybe I should send you the file privately.
> If you like, we can duplicate (with svn cp) iso-experiment, and do
> that there -- I think that would be very easy, in fact.
Again, your documentation is not sufficiently understandable. So I
wouldn't even know if your implementation is correct.
> Much more sensible I think would be to express the same functionality with
> MultiSort species. Do not forget: we won't be able to generate Isotypes of
> FunctorialComposition, thus, to take them as an argument for the representing
> isotypes by representatives :-) is unfortunate.
What? "we won't be able to generate Isotypes of FunctorialComposition"
If you take that as an argument to deviate from the clear mathematical
analogue we have in AC now, then I simply don't agree. Just suppose next
week comes some brilliant guy and tells you how to generate such iso types.
> I think that Permutation, Cycles, etc. should be moved to an "examples" files,
> as I have started it in iso-experiment. species.as.nw should only contain the
> "natural transformations" and everything they depend on, don't you think?
Oh, since some time I wanted to clean up our stuff. In fact, what I
would like to have is a directories "species", "series", etc. and under
each of them implement each species in a different file. Maybe there are
some things that *have to be* in just one file (like
CombinatorialSpecies and SetSpecies), but that is another problem.
How we then include those file (basic species, basic constructors,
example species) is a meta task.
Should I split species.as.nw?
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
