Discussion:
revision 195: More species
Ralf Hemmecke
2007-03-25 01:47:05 UTC
Permalink
I've just committed revision 195.

It AC provides now LinearOrder, Cycle, and Permutation.

I know that Permutation could have done via Compose(SetSpecies, Cycle),
but it seemed so overly important that I thought a more efficient
implementation is worth it.

And for Martin ... look at some first ideas for the isomorphism types of
Compose that produce representatives.

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
Martin Rubey
2007-03-25 09:15:32 UTC
Permalink
Dear Ralf,
Post by Ralf Hemmecke
And for Martin ... look at some first ideas for the isomorphism types of
Compose that produce representatives.
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.
Post by Ralf Hemmecke
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. If you like, we can duplicate (with svn cp) iso-experiment, and do
that there -- I think that would be very easy, in fact.

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.

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?

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
Ralf Hemmecke
2007-03-25 11:25:58 UTC
Permalink
Hi Martin,
Post by Martin Rubey
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.
Post by Martin Rubey
Post by Ralf Hemmecke
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.
Post by Martin Rubey
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.
Post by Martin Rubey
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.
Post by Martin Rubey
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
Martin Rubey
2007-03-25 12:02:23 UTC
Permalink
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}.
\begin{itemize}
\item generate a multiset partition $\pi$ of the input set $U$, written as
a multiset.
eg, for the example given in the doc, U={1^9}, pi={1, 2, 3^2}
\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]$.
eg, M_1 = o, M_2 = o M_3 = { o , o }
/ \ / \ / \
o o
/ \ / \

or N_1 = o, N_2 = o N_3 = { o , o }
/ \ / \ / \
o o
/ \ / \
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]$
eg. N1, N3.1, N3.2, N2
N1, N3.1, M2, N3.2

-- note that isotypes of Cycles will get as argument { N1, N2, (N3.1)^2 }

or M1, M3.1, N2, M3.2
M1, M3.2, N2, M3.1

-- note that isotypes of Cycles will get as argument { M1, M2, M3.1, M3.2 }

(I probably should delete the last line of the example given in the doc.)
\end{itemize}
-------------------
Yes. But if you look closer, you'll see that I also added transport condition,
an example, etc.
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.
Haeh? In what sense do you want me to be more precise? Does the example above
help? By the way, I do not understand

25-Mar-2007: My idea would rather be to replace the line
\begin{adsnippet}
isomorphismTypes(pi::SetSpecies(SetSpecies L))$F(SetSpecies L)
\end{adsnippet}%$
below by
\begin{adsnippet}
isomorphismTypes(pi)$F(L)
\end{adsnippet}%$
By that we basically consider the representative \adcode$pi$ as a
true partition structure and then let $F$ decide in how many
different ways \adcode$pi$ can contribute non-isomorphic
structures. Since the results are again representatives, we simply
ask for all the isomorphism types of $G$ in a similar was as we do
for structures.

at all... It is tempting to believe that what I understand is easily understood
by everybody, but it is not true. Similarly, docs that I find iluminating may
be completely mysterious to somebody else...
Anyway, we seem to be in total disagreement with respect to the
representation of isomorphism types.
No, we are not in total disagreement. Disagreement is only partial.
------------------
Introduce a new type that represents the isomorphism types. Make all labels
indistinguishable.
----------------
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.
How often do I have to repeat that I do agree with your approach, as a "working
hypothesis". I did say that I do not like it, but I also said that I do not
like my stuff either.
Post by Martin Rubey
Post by Ralf Hemmecke
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. :-(
Did you read the two words: "in trunk"?
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.
exactly. That's why I said: open a new branch.
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.
So you have an algorithm for Compose without using multisets, multisort species
or something equivalent? I doubt that.
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.
Why are you so afraid of having a branch which does not work? It does not
matter at all that it is a mess!
Post by Martin Rubey
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.
So please tell me more precisely what parts you do not understand. Then I can
update the docs. I hope you do not believe that I can understand all of your
docs either. If I'd have to, I could quit combinatorics immediately, because I
would end up only reading documentation.
Post by Martin Rubey
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"
yes.
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 tried to express that it is unfortunate to take FunctorialCompose as the
*only* argument for representatives. But if we do multisort species, and
thereby get a second argument for representatives, everything's fine again.
Should I split species.as.nw?
No, you should put your messy stuff on multisort species into a branch called

multisort-experiment.

I'm going to take a walk now, and after that I'm going to look at your
multisort stuff.

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
Ralf Hemmecke
2007-03-26 10:40:19 UTC
Permalink
Post by Martin Rubey
No, you should put your messy stuff on multisort species into a branch called
multisort-experiment.
I'm going to take a walk now, and after that I'm going to look at your
multisort stuff.
I hope you are back from your walk.

Revision 197 now has branches/multisort-experiment.

As you see the stuff in mspecies.as.nw is in some sense trivial and on
the other hand it drives Aldor to its limits. I don't even know yet
whether the code produced by Aldor actually works. At least I made it
compile now.

Unfortunately, I had to introduce ugly 'pretend's. Before this code ever
makes it into trunk the 'pretend's should be hidden in just *one*
domain. Maybe that can be done, I have no clear picture yet.

Don't expect too much documentation or explanation since I am experimenting.

This branch is open for writing to everyone with the restriction that
every change that is not done by myself must be *sufficiently*
explained, otherwise I will simply switch to work in private. I don't
want to waste time in deciphering code snippets.

Have fun

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
Martin Rubey
2007-03-26 11:13:05 UTC
Permalink
Post by Ralf Hemmecke
Post by Martin Rubey
No, you should put your messy stuff on multisort species into a branch called
multisort-experiment.
I'm going to take a walk now, and after that I'm going to look at your
multisort stuff.
I hope you are back from your walk.
Yes. Just arrived :-;
Post by Ralf Hemmecke
Revision 197 now has branches/multisort-experiment.
SUPER!
Post by Ralf Hemmecke
As you see the stuff in mspecies.as.nw is in some sense trivial and on the
other hand it drives Aldor to its limits. I don't even know yet whether the
code produced by Aldor actually works. At least I made it compile now.
WOW!
Post by Ralf Hemmecke
Unfortunately, I had to introduce ugly 'pretend's. Before this code ever makes
it into trunk the 'pretend's should be hidden in just *one* domain. Maybe that
can be done, I have no clear picture yet.
Don't expect too much documentation or explanation since I am experimenting.
That's the point!
Post by Ralf Hemmecke
This branch is open for writing to everyone with the restriction that every
change that is not done by myself must be *sufficiently* explained, otherwise I
will simply switch to work in private. I don't want to waste time in
deciphering code snippets.
Ok, I'll give my best...

Again, many many thanks!

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
Nicolas M. Thiery
2007-03-28 20:17:45 UTC
Permalink
Post by Ralf Hemmecke
I know that Permutation could have done via Compose(SetSpecies, Cycle),
but it seemed so overly important that I thought a more efficient
implementation is worth it.
Yes. Furthermore, Compose(SetSpecies, Cycle) and Permutation are *not*
the same species: there of course is a bijection between the two, but
this bijection is not compatible with the group actions.

Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" <nthiery-iA+***@public.gmane.org>
http://Nicolas.Thiery.name/

-------------------------------------------------------------------------
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
Martin Rubey
2007-03-28 20:25:22 UTC
Permalink
Furthermore, Compose(SetSpecies, Cycle) and Permutation are *not* the same
species: there of course is a bijection between the two, but this bijection
is not compatible with the group actions.
Are you sure? Could you give an example? Let b: S -> E o C take a permutation
of U and produce the cycle decomposition of the permutation.

If s is a relabeling, i.e., a permutation of U, b(s) should produce the
corresponding relabeling on E o C [U].

I'd have thought that S and E o C are naturally isomorphic ?

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
Nicolas M. Thiery
2007-03-28 20:51:30 UTC
Permalink
Post by Martin Rubey
Are you sure?
This was explained to me by François Bergeron, so pretty much yes :-)
(up to the point that we are speaking about the same thing). Actually,
I think he told me this example was in the Book.

The point is that relabeling a permutation in cycle notation
corresponds to the action of S_n on itself by *conjugation*, and not
*on the right* as when you relabel a permutation in array notation.

Example, relabeling by the transposition (1,2):

(1,2) (3) = 213

|| ||
\/ \/

(1,2) (3) <> 123

Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" <nthiery-iA+***@public.gmane.org>
http://Nicolas.Thiery.name/

-------------------------------------------------------------------------
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
Martin Rubey
2007-03-28 21:00:17 UTC
Permalink
Post by Martin Rubey
Are you sure?
This was explained to me by François Bergeron, so pretty much yes :-) (up to
the point that we are speaking about the same thing). Actually, I think he
told me this example was in the Book.
The point is that relabeling a permutation in cycle notation corresponds to
the action of S_n on itself by *conjugation*, and not *on the right* as when
you relabel a permutation in array notation.
(1,2) (3) = 213
|| ||
\/ \/
(1,2) (3) <> 123
Hm, I don't think that's correct. It seems that the objects on the right are
linear orders, not permutations. (and that would indeed be in the book).

By the way, using species, you cannot represent a permutation as 213, since you
don't have an ordering on the input set. Thus, you really have

123
213

For clarity, let's rather write

abc
bac

Now, how is the relabeling going to work, if you relabel a->1, b->2, c->3 ? It
must be

123
213

By analogy, relabeling 1->2, 2->1, 3->3, you obtain

213
123

which does agree with (1 2) (3).

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
Nicolas M. Thiery
2007-03-29 21:38:16 UTC
Permalink
Post by Martin Rubey
Hm, I don't think that's correct. It seems that the objects on the right are
linear orders, not permutations. (and that would indeed be in the book).
Ach so! Sure, in that case I agree; with this point of view this the
action is also by conjugation. Just make sure to point this out
precisely in your documentation, as many users will have what you call
linear orders in mind when they will see "permutation".

Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" <nthiery-iA+***@public.gmane.org>
http://Nicolas.Thiery.name/

-------------------------------------------------------------------------
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
Ralf Hemmecke
2007-03-29 22:49:12 UTC
Permalink
Post by Nicolas M. Thiery
Post by Martin Rubey
Hm, I don't think that's correct. It seems that the objects on the right are
linear orders, not permutations. (and that would indeed be in the book).
Ach so! Sure, in that case I agree; with this point of view this the
action is also by conjugation. Just make sure to point this out
precisely in your documentation, as many users will have what you call
linear orders in mind when they will see "permutation".
I've included the definition of the Permutation species including the
fact that the transport is via conjugation.

And I had from the beginning:

The \useterm{species of permutations} is closely related to the
\useterm{species of linear orders}. However, their isomorphism types
are different and, therefore, we cannot use \adtype{List} as the
representation but rather have to use the following in accordance with
the representation of \adtype{Partition}. For the generation of
isomorphism types we can easily borrow from the code for
\adtype{Partition}.
%
In fact, each list in the array presents a cycle in the cycle
decomposition of a given permutation.
%CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
<<representation: Permutation>>=
Rep == Array List L;
@
%TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT

I hope you can relax now. :-)

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
Ralf Hemmecke
2007-03-28 21:31:26 UTC
Permalink
Hello,
Post by Nicolas M. Thiery
Post by Martin Rubey
Are you sure?
This was explained to me by François Bergeron, so pretty much yes :-)
Since I am a notorious non-believer, I have still have my doubts. Let me
explain.

1) Section 1.4 equation (14) states the
"..., we have the combinatorial equation S = E \circ C".
2) Section 1.2 "Combinatorial Equality" states 3 types of equality.
a) identity (written =)
b) equipotency (written \equiv)
c) combinatorial equality (written =)

Clearly, under 1) it is not written \equiv. And since we don't have
identity, it can only mean 2c).
Post by Nicolas M. Thiery
(up to the point that we are speaking about the same thing). Actually,
I think he told me this example was in the Book.
The point is that relabeling a permutation in cycle notation
corresponds to the action of S_n on itself by *conjugation*, and not
*on the right* as when you relabel a permutation in array notation.
(1,2) (3) = 213
|| ||
\/ \/
(1,2) (3) <> 123
In fact, I started to implement permutations as being in an array
representation. When I wanted to implement the generation of isomorphism
types, I realized that I had not enough bits to represent a
representative of an isomorphism type of a permutation. So the
representation became

Array List L

for Permutation and

List L

for Cycle and LinearOrder. That is the fun if one implements labelled
and unlabelled structures at the same time. One realises quickly that
something doesn't work.

I am pretty sure that S = E \circ C stands for an equality of functors
(i.e there is a "natural" isomorphism between the two functors).

Of course LinearOrder \ne Permutation = Compose(SetSpecies, Cycle)
(where the latter is only an isomorphism in AC).

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
Continue reading on narkive:
Loading...