[sage-combinat-devel] rebasing to sage-5.3.beta1
Hi All! Andrew Mathas and I had to import the patches from ticket 11310 to the queue as they touched /combinat/tableaux.py and conflicted with 9265. As a result the following patches did not apply any longer trac_5512-species_equality.patch alphabet-vd.patch species_labels-mr.patch concrete_combinatorial_statistics_and_maps-cs.patch I temporarily disabled them! If any of them belong to you, please rebase them! Best, Anne -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] (With)Realizations
Hello Nicolas! On Thu, Aug 16, 2012 at 5:50 AM, Nicolas M. Thiery wrote: > Hi Franco! > > On Tue, Aug 14, 2012 at 01:41:28PM -0400, Franco Saliola wrote: >> I'm having trouble with (With)Realizations. >> >> If I understand correctly, then we have the following. >> >> - The methods in Category.WithRealizations.ParentMethods are >> methods that are "inherited" by any object in the Category that >> has realizations. >> >> - The methods in Category.Realizations.ParentMethods are methods >> that are "inherited" by realizations of an object in the >> Category. > > Correct! > >> I want to add a new method for a realization of an algebra. But >> my method only makes sense if the realization has a basis, so it >> doesn't apply to all realizations of algebras. So I shouldn't put >> it in Algebras.Realizations.ParentMethods. >> >> Where should I put this method? > > It should go in: > > Algebras.Realizations.WithBasis.ParentMethods Ah, yes. > But being able to do so requires the ``more functorial construction > patch''. I am glad to see another application of this patch :-) > Speaking of which, I have been working on it recently, and hope to get > it finished or so next week. Great! I added myself to the CC on the ticket. Take care, Franco -- -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Re: int and Integers
PS: On 2012-08-16, Simon King wrote: >>In other words "3 in Zmod(5)(3)" should >> returns True but it returns an error. > > Zmod(5)(3) is by default considered as an element of a ring, not as a coset. > Hence, of cource "3 in Zmod(5)(3)" returns an error. If you want a > coset, i.e., if you want a non-default behaviour, then you need to do so > explicitly. ... Or you could implement a `__contains__` method for sage.rings.finite_rings.integer_mod.IntegerMod_int. Then, "3 in Zmod(5)(3)" would work. -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Re: int and Integers
Hi Vincent, I'm sorry for my long answer. I am not a native speaker, so, it is difficult for me to be concise in English. On 2012-08-16, Vincent Delecroix <20100.delecr...@gmail.com> wrote: > This default behavior is very badly suited. In parallel to my second > mail, I found the more striking example ... I disagree. In mathematics, == is transitive. But I believe it is impossible to keep == transitive in a complex computer algebra system. Of course one must make sure that "a==b and b==c implies a==c", provided that a, b and c belong to the same parent. However, we talk here about comparing elements in *different* parents. If a and b belong to different parents, I believe that "a==b" is not a mathematically rigid statement any more. In particular, you can't expect transitivity. Nevertheless "a==b" must still give an answer (raising an error is no option, by Python convention), and of course the answer should still be as useful as possible. In order to be useful, it must still be reflexive and symmetric, but transitivity only needs to hold "to a reasonable extent". And I believe that basing "a==b" on coercion *is* reasonable. > I definitely think that "Zmod(5)(3) in ZZ" should return False. > Remarks that it is true as a subset as Zmod(5)(3) is the set of > integers equal to 3 mod 5. The first ingredient for "Zmod(5)(3) in ZZ" being true is that there is a *canonical* ring homomorphism (used for coercion) from ZZ to Zmod(5). The second ingredient is that someone has decided that a conversion (which is not a coercion!!!) from Zmod(5) to ZZ is very useful and should be available. Let phi:ZZ->Zmod(5) the coercion homomorphism and psi:Zmod(5)->ZZ the conversion map. psi is not a homomorphism and can thus not be a coercion. But it is a section for phi, and I think it *is* reasonable to use it for conversion. Let a be in ZZ and b be in Zmod(5). If you ask a==b, even though a and b belong to different mathematical structures, then I think the best one can do is to map a and b to a canonical mathematical structure by homomorphisms. In general, the "canonical mathematical structure" will be determined by a pushout construction. Here, it is easier: There is a canonical homomorphism from ZZ to Zmod(5). Hence, Sage will compare a and b there, via the coercion homomorphism: a==b is the same as phi(a)==b. Since psi is a section, psi(b)==b holds for all b in Zmod(5). If one accepts psi as a conversion map, I think it is reasonable to accept "b in ZZ" for all b in Zmod(5) -- as long as one is aware that the embedding of Zmod(5) in ZZ is not structure preserving! Of course, there will be applications in which that kind of comparison is too coarse. But if you want to compare elements of distinct parents then it is your own risk that your notion of "reasonable" is different from Sages implementation of "reasonable". >In other words "3 in Zmod(5)(3)" should > returns True but it returns an error. Zmod(5)(3) is by default considered as an element of a ring, not as a coset. Hence, of cource "3 in Zmod(5)(3)" returns an error. If you want a coset, i.e., if you want a non-default behaviour, then you need to do so explicitly. > It is easy to create an embedding into ZZ and modify the __contains__ > method. Then many things work well. > > Note that P is a facade and hence it is normal that its elements have > a parent different from P. But is there a canonical way to tell that a > Parent is a subset of another Parent? During initialisation of a parent, one can use the method register_embedding (defined for sage.structure.parent.Parent) to declare a canonical embedding. That embedding will be used as a coercion map. Best regards, Simon -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: int and Integers
Thanks Simon.
> The default behaviour of "x in P" for any parent P in Sage is:
> x in P
> <=>
> P(x)==x is True (and does not raise an error)
This default behavior is very badly suited. In parallel to my second
mail, I found the more striking example
{{{
sage: R = Zmod(5)
sage: i = ZZ(3)
sage: j = R(3)
sage: i in R and j in ZZ
True
sage: i == j
True
sage: 1/i in R
False
sage: 1/i == 1/j
False
}}}
I definitely think that "Zmod(5)(3) in ZZ" should return False.
Remarks that it is true as a subset as Zmod(5)(3) is the set of
integers equal to 3 mod 5. In other words "3 in Zmod(5)(3)" should
returns True but it returns an error.
> I think that's a mess. P should at least know that it is a subset of ZZ.
> Hence, its embedding into ZZ should be registered as a coercion. And it
> should be able to convert a positive python int.
It is easy to create an embedding into ZZ and modify the __contains__
method. Then many things work well.
Note that P is a facade and hence it is normal that its elements have
a parent different from P. But is there a canonical way to tell that a
Parent is a subset of another Parent?
Best,
Vincent
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
To unsubscribe from this group, send email to
sage-combinat-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Re: int and Integers
Dear Vincent,
On 2012-08-16, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
> It breaks many test in sage.combinat.*. Note that if we adopt the
> strict convention (ie int(2) not in Integers/IntegerRange/...) then it
> will be impossible to do the following
> {{{
> sage: W = Words("positive integers")
> sage: W([int(1), int(2)])
> word: 12
> }}}
>
> I have two options
> * modify all files in sage.combinat.* in order to fit the new implementation
> * make PositiveIntegers and IntegerRange accepts silently Python int
The default behaviour of "x in P" for any parent P in Sage is:
x in P
<=>
P(x)==x is True (and does not raise an error)
Hence, according to the default, if P=PositiveIntegers(), then we want
the following:
1) P(int(1)) works
2) Coercion between P and int works (this is implicitly used in "==")
But currently, we have:
* P(int(1)) raises an error (hence, "int(1) in P" is false by default)
* P(1).parent() is ZZ, not P
* sage.categories.pushout.pushout(P,ZZ) raises an error.
* The coercion model finds that there is a multiplication action of
P on ZZ, but it is not able to tell about addition.
I think that's a mess. P should at least know that it is a subset of ZZ.
Hence, its embedding into ZZ should be registered as a coercion. And it
should be able to convert a positive python int.
Cheers,
Simon
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
To unsubscribe from this group, send email to
sage-combinat-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Re: int and Integers
Quick update : I really don't like the following (which comes from the
default sage.structure.parent.__contains__)
{{{
sage: Zmod(12)(5) in ZZ
True
}}}
2012/8/16, Vincent Delecroix <20100.delecr...@gmail.com>:
> Hi,
>
> I'm working on #8920 about factorization of codes between alphabets
> and sets. I got problems with the following behavior::
> {{{
> sage: int(2) in IntegerRange(1,3)
> False
> sage: int(2) in Integers()
> True
> sage: int(2) in NonNegativeIntegers()
> True
> sage: int(2) in PositiveIntegers()
> False
> }}}
> It breaks many test in sage.combinat.*. Note that if we adopt the
> strict convention (ie int(2) not in Integers/IntegerRange/...) then it
> will be impossible to do the following
> {{{
> sage: W = Words("positive integers")
> sage: W([int(1), int(2)])
> word: 12
> }}}
>
> I have two options
> * modify all files in sage.combinat.* in order to fit the new
> implementation
> * make PositiveIntegers and IntegerRange accepts silently Python int
>
> Cheers,
> Vincent
>
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
To unsubscribe from this group, send email to
sage-combinat-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] int and Integers
Hi,
I'm working on #8920 about factorization of codes between alphabets
and sets. I got problems with the following behavior::
{{{
sage: int(2) in IntegerRange(1,3)
False
sage: int(2) in Integers()
True
sage: int(2) in NonNegativeIntegers()
True
sage: int(2) in PositiveIntegers()
False
}}}
It breaks many test in sage.combinat.*. Note that if we adopt the
strict convention (ie int(2) not in Integers/IntegerRange/...) then it
will be impossible to do the following
{{{
sage: W = Words("positive integers")
sage: W([int(1), int(2)])
word: 12
}}}
I have two options
* modify all files in sage.combinat.* in order to fit the new implementation
* make PositiveIntegers and IntegerRange accepts silently Python int
Cheers,
Vincent
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
To unsubscribe from this group, send email to
sage-combinat-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] (With)Realizations
Hi Franco! On Tue, Aug 14, 2012 at 01:41:28PM -0400, Franco Saliola wrote: > I'm having trouble with (With)Realizations. > > If I understand correctly, then we have the following. > > - The methods in Category.WithRealizations.ParentMethods are > methods that are "inherited" by any object in the Category that > has realizations. > > - The methods in Category.Realizations.ParentMethods are methods > that are "inherited" by realizations of an object in the > Category. Correct! > I want to add a new method for a realization of an algebra. But > my method only makes sense if the realization has a basis, so it > doesn't apply to all realizations of algebras. So I shouldn't put > it in Algebras.Realizations.ParentMethods. > > Where should I put this method? It should go in: Algebras.Realizations.WithBasis.ParentMethods But being able to do so requires the ``more functorial construction patch''. I am glad to see another application of this patch :-) Speaking of which, I have been working on it recently, and hope to get it finished or so next week. Cheers, Nicolas -- Nicolas M. Thiéry "Isil" http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
