Hi Christian,
I agree that this probably is a bug, but looking at the class a little more
closely I think that it needs some TLC. In particular, it seems to me that
the object that Core returns does not really know that it is a core.
Consider:
sage: Core([2],4) is Partition([2]).core(4)
False
Hi Christian,
do you consider the following a bug?
|sage: A = Core([2],4)
sage: B = Core([2],5)
sage: hash(A) == hash(B)
True|
The hash of a core only depends on the list and not on the core. Since the
same list considered as an x- and as a y-core are fundamentally different
sage: (Partition([2]).to_core(4)).parent()
5-Cores of length 2
Okay, I get from the documentation of to_core that this returns what it is
supposed to.
But anyway, let me mention that for me as someone not very familiar with
the topic, I would expect that Partition([2]).to_core(k) checks if
I wouldn't necessarily call that a bug, as it is necessary since A == B.
four people, two options, five opinions...
Let me ask this, is being a k-core a property of a partition or is it a
*distinct* combinatorial object?
As mathematical concepts, that doesn't make much of a difference, I'd
The reason why we need(ed) a separate core class is that for example
otherwise
it would not be possible or easy to implement the action of the affine
symmetric group
on (k+1)-cores.
Of course, one can ask whether a given partition is an n-core and that
method
should live in
Yes, I agree. I noticed this after I posted but I GG doesn't allow me to
edit:)
A.
On Monday, 16 December 2013 14:22:50 UTC+1, Christian Stump wrote:
Thanks, Andrew!
sage: Core([2],4) is Partition([2]).core(4)
False
I agree with all what you write, except that I would not expect this
