How should representations of symmetric groups be compared?
Simon King
Currently, if two representations of a symmetric group are compared,
it is essentially a test of their __dict__. Obviously this is no
mathematically meaningful way of comparison: If you have to equal
representations and then cache some info in one of them, then suddenly
they compare different:
sage: spc = SymmetricGroupRepresentation([3])
sage: spc == SymmetricGroupRepresentation([3])
True
sage: spc._cache_some_info = 'sage rules'
sage: spc == SymmetricGroupRepresentation([3])
False
So, how should comparison be done instead?
Cheers,
Simon
Nicolas M. Thiery
A candidate for UniqueRepresentation?
Cheers,
Nicolas
--
Nicolas M. Thi�ry "Isil" <nth...@users.sf.net>
http://Nicolas.Thiery.name/
Simon King
On 8 Jan., 22:32, "Nicolas M. Thiery" <Nicolas.Thi...@u-psud.fr>
wrote:
>
> A candidate for UniqueRepresentation?
representations to be unique.
If they prefer them to be equal but non-identical:
It seems to me that the comparison in fact only relies on
* the type of the representation (Specht's representation, Young's
seminormal representation, Young's orthogonal representation)
* the attribute _ring
* the attribute _partition
But before I implement a comparison relying on these or a unique
representation, I need to know what users/experts want.
Cheers,
Simon
Nicolas M. Thiery
> > A candidate for UniqueRepresentation?
>
> Possibly. But I don't know if the experts in the field want
> representations to be unique.
I am not sure either.
> If they prefer them to be equal but non-identical:
> It seems to me that the comparison in fact only relies on
> * the type of the representation (Specht's representation, Young's
> seminormal representation, Young's orthogonal representation)
> * the attribute _ring
> * the attribute _partition
>
> But before I implement a comparison relying on these or a unique
> representation, I need to know what users/experts want.
This sounds reasonable to me. I have just bounced your e-mail to
sage-combinat-devel since I am not sure, e.g., Franco is reading
sage-algebra.
Franco Saliola
<Nicolas...@u-psud.fr> wrote:
> On Sat, Jan 08, 2011 at 01:54:42PM -0800, Simon King wrote:
>> > A candidate for UniqueRepresentation?
>>
>> Possibly. But I don't know if the experts in the field want
>> representations to be unique.
>
> I am not sure either.
>
>> If they prefer them to be equal but non-identical:
>> It seems to me that the comparison in fact only relies on
>> * the type of the representation (Specht's representation, Young's
>> seminormal representation, Young's orthogonal representation)
>> * the attribute _ring
>> * the attribute _partition
>>
>> But before I implement a comparison relying on these or a unique
>> representation, I need to know what users/experts want.
>
> This sounds reasonable to me. I have just bounced your e-mail to
> sage-combinat-devel since I am not sure, e.g., Franco is reading
> sage-algebra.
I do not remember why I implemented it the way I did, but I also agree
with the suggested change.
Take care,
Franco
--
Dima Pasechnik
nature of morphism to be applied
(1) trivial morphism
(1 1/2) a permutation of the basis
(2) orthogonal
(3) Hermitian
....
(coarsest) arbitrary (i.e. the characters are the same for both
representations)
I suppose the design should allow for user-defined/extendible
equivalences.
Best,
Dmitrii
>
> Cheers,
> Simon
Simon King
On 9 Jan., 18:10, Dima Pasechnik <dimp...@gmail.com> wrote:
> On Jan 8, 1:54 pm, Simon King <simon.k...@uni-jena.de> wrote:
> nature of morphism to be applied
> (1) trivial morphism
> (1 1/2) a permutation of the basis
> (2) orthogonal
> (3) Hermitian
> ....
> (coarsest) arbitrary (i.e. the characters are the same for both
> representations)
>
> I suppose the design should allow for user-defined/extendible
> equivalences.
current way of comparison so that it is essentially the same to what
happens now, but is invariant against adding attributes (so that the
bug in the example above won't occur).
By the way, I've hit that bug when I worked on speeding up
cached_method decorators. Namely, one part of the speed-up comes from
using an additional attribute - and since the representations have
some cached_method, the comparison broke. I just realize that I had
forgotten to mention it on the ticket.
It is #8611 and ready for review (if you care about making
cached_method a lot faster).
Cheers,
Simon
Nicolas M. Thiery
> On 9 Jan., 18:10, Dima Pasechnik <dimp...@gmail.com> wrote:
> > On Jan 8, 1:54�pm, Simon King <simon.k...@uni-jena.de> wrote:
> > ...
> > IMHO there should be several levels of equivalence, depending upon the
> > nature of morphism to be applied
> > (1) � � �trivial morphism
> > (1 1/2) a permutation of the basis
> > (2) � � �orthogonal
> > (3) � � �Hermitian
> > ....
> > (coarsest) arbitrary (i.e. the characters are the same for both
> > representations)
> >
> > I suppose the design should allow for user-defined/extendible
> > equivalences.
>
> OK, but as a short-term solution, I'd prefer to re-implement the
> current way of comparison so that it is essentially the same to what
> happens now, but is invariant against adding attributes (so that the
> bug in the example above won't occur).
Semantically, I would choose to have equality mean (1), and leave the
others to specific method(s) like "is_isomorphic". This turns out to
coincide with what Simon is implementing :-)
> By the way, I've hit that bug when I worked on speeding up
> cached_method decorators. Namely, one part of the speed-up comes from
> using an additional attribute - and since the representations have
> some cached_method, the comparison broke. I just realize that I had
> forgotten to mention it on the ticket.
>
> It is #8611 and ready for review (if you care about making
> cached_method a lot faster).
I do!!!!!! I'll have a look. Thanks!