Hi
> I think the design problem comes from the fact the "category of
> enumerated sets" is not real "category" from the mathematical point of
> view, although you can embed it inside the category of totally ordered
> sets with the "enumeration order", that point of view might solve some
> of your design questions.
Yes it is ! If you decide that maps are one to one bijection which are
compatible with the enumeration order. That's the base of the theory of
Linear-Species (defined as Functor : EnumSet -> Set).
> Concerning the union of sets, in general you have to canonical way of
> assigning an enumeration, one can decide to enumerate first all the
> elements of A and then all the elements of B. This works without much
> trouble for finite sets.
It's clear if sets are disjoints. That's already implemented in
DisjointUnionEnumeratedSet... You can even play with infinite union:
sage: S = DisjointUnionEnumeratedSets(Family(NonNegativeIntegers(),
Permutations))
sage: S
Disjoint union of Lazy family (Permutations(i))_{i in Non negative integers}
sage: S = DisjointUnionEnumeratedSets(Family(NonNegativeIntegers(),
Permutations))
sage: S
Disjoint union of Lazy family (Permutations(i))_{i in Non negative integers}
sage: import itertools
sage: itertools.islice(S, 0, 10)
<itertools.islice object at 0x4793208>
sage: list(itertools.islice(S, 0, 10))
[[],
[1],
[1, 2],
[2, 1],
[1, 2, 3],
[1, 3, 2],
[2, 1, 3],
[2, 3, 1],
[3, 1, 2],
[3, 2, 1]]
sage: S.cardinality()
+Infinity
sage: Permutation([3,1,2]) in S
/usr/local/sage/sage-4.1.2/local/lib/python2.6/site-packages/sage/sets/disjoint_union_enumerated_sets.py:246:
UserWarning: Disjoint union of Lazy family (Permutations(i))_{i in Non
negative integers} is an infinite union
The default implementation of __contains__ can loop forever. Please overload it.
True
It's less clear if A and B are not disjoint.
> All these methods have the issue that as enumerated sets A.union(B)
> would be different from B.union(A). Plus the fact that the enumeration
> choice is arbitrary.
That's the problem... The question was more if someone has some practical
application.
> Another direction could be to allow to specify an "ambient" enumerated
> set X that contains both A and B, and endow the union with the
> enumeration inherited from the ambient set (this would work well with
> things such as conjugacy classes of groups, where all elements belong
> to a common set). For this to make any (mathematical) sense, it would
> be necessary that the enumeration of A and B also come from the
> enumeration of X, which bring us to the problem of the intersection.
> If A={a1,a2,a3,a4,a5} and B={a2,a3,a5,a7,a11} (as enumerated sets) it
> makes sense to consider the intersection as the enumerated set
> {a2,a3,a5}, but if B={a11,a7,a5,a3,a2} then no enumeration will make
> sense. So my proposal would be to enumerate only when one has a common
> parent of A and B that is enumerated.
That's a good idea... I'll try it.
> > Here is a much more complicated one:
> >
> > - If a parent is in a sub category of EnumeratedSets or Sets (say e.g.:
> > FiniteGroup), Currently the forgetful functor is implemented by Set
> > sage: S = Set(SymmetricGroup(3))
> > sage: S
> > {(2,3), (1,3), (1,2), (1,3,2), (), (1,2,3)}
> > Compare with:
> > sage: list(SymmetricGroup(3))
> > [(), (2,3), (1,2), (1,2,3), (1,3,2), (1,3)]
> > sage: FiniteEnumeratedSet(SymmetricGroup(3))
> > {(), (2,3), (1,2), (1,2,3), (1,3,2), (1,3)}
> > But SymmetricGroup(3) is already in the category Sets
> > sage: SymmetricGroup(3) in Sets()
> > True
> > So there should be no need to call explicitely the forgetful functor.
> > In particular I don't see the point of creating another sage object for
> > those
> > case. Otherwise said, I only see the reason to create a new sage object for
> > building a Set, when the object is not a sage Parent in the category Sets,
> > eg:
> > python list, set, frozenset ...
>
> As far as I know "Set" is not (yet) a functor (unless we can apply it
> to group homomorphisms), but just the "underlying set" of a group.
That the point. As far As I know in sage + Nicolas category implantation any
group
homomorphism is accepted as a Set homomorphism. So there it no need to apply
any function to compute the functor: Here is an example from the doc:
sage: from sage.categories.morphism import SetMorphism
sage: X.<x> = ZZ[]
sage: Y = ZZ
sage: Z = QQ
sage: phi_xy = SetMorphism(Hom(X, Y, Rings()), lambda p: p[0])
sage: phi_yz = SetMorphism(Hom(Y, Z, CommutativeAdditiveMonoids()),
lambda
y: QQ(y)/2)
sage: bla = phi_yz._composition(phi_xy); bla
Composite map:
From: Univariate Polynomial Ring in x over Integer Ring
To: Rational Field
Defn: Generic morphism:
From: Univariate Polynomial Ring in x over Integer Ring
To: Integer Ring
then
Generic morphism:
From: Integer Ring
To: Rational Field
sage: bla.category_for()
Category of commutative additive monoids
So if you compose a Rings()-morphism and a CommutativeAdditiveMonoids()-morphism
you get a CommutativeAdditiveMonoids()-morphism.
> As
> of why we might need to call it, one can think of the same underlying
> set {a,b,c,d} having two different group structures (isomorphic to ZZ/
> 2ZZ x ZZ/2ZZ or Dihedral(4)) as groups, these would be different (even
> non-isomorphic), but as sets they are the same (i.e. the forgetful
> functor is not injective on objects).
That a mathematical way to *think* about it. It is not at all implementable in
sage, since a,b,c,d can't have both Z2Z2 := ZZ/2ZZ x ZZ/2ZZ and Dihedral(4) as
parent. So you must have different objects for a,b,c,d in Z2Z2 and a,b,c,d in
Dihedral(4). You can trick equal to answer that the first a is equal to the
second one but it's to me just a trick.
The usual way (at least to people coming from MuPAD-Combinat) to deal with
this kind of problem is to have two different parents ZZ/2ZZ x ZZ/2ZZ and
Dihedral(4) with different elements together with an isomorphism in the
category of Sets. That's the usual problem that very often in mathematical we
use to call equal things that actually are only isomorphic.
> This, mathematically. As of the
> implementation within sage, I agree one would think that the quickest
> way to apply it is just not to use the extra structure that has been
> previously defined, but I don't know the details on the implementation
> well enough to say anything intelligent about this.
So I'm waiting if someone else has an idea.
Cheers,
Florent
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
