[sage-combinat-devel] bug in Weyl groups?
Hi! Is this a bug? sage: WA = WeylGroup(['A',2,1]) sage: WB = WeylGroup(['B',2,1]) sage: wa = WA.an_element() sage: wa in WA True sage: wa in WB True Best, Anne -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-combinat-devel] bug in Weyl groups?
On Tue, Jul 16, 2013 at 11:23:05AM -0700, Anne Schilling wrote: Is this a bug? sage: WA = WeylGroup(['A',2,1]) sage: WB = WeylGroup(['B',2,1]) sage: wa = WA.an_element() sage: wa in WA True sage: wa in WB True A potential explanation about what happens: WA and WB are groups of matrices. So `in` tries to convert wa by making it into a matrix, and checking if this matrix is in the group WB, which it is. I personally put this in the bag of ugly side effects we get for using too often conversions in containment tests. Especially since this containment test can be quite expensive. So I'd be happy to qualify this as a bug. If you want a safe and fast way to test that the parent of w is WB, you can use: WB.is_parent_of(w) Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-combinat-devel] bug in Weyl groups?
On 7/16/13 2:03 PM, Nicolas M. Thiery wrote: On Tue, Jul 16, 2013 at 11:23:05AM -0700, Anne Schilling wrote: Is this a bug? sage: WA = WeylGroup(['A',2,1]) sage: WB = WeylGroup(['B',2,1]) sage: wa = WA.an_element() sage: wa in WA True sage: wa in WB True A potential explanation about what happens: WA and WB are groups of matrices. So `in` tries to convert wa by making it into a matrix, and checking if this matrix is in the group WB, which it is. I personally put this in the bag of ugly side effects we get for using too often conversions in containment tests. Especially since this containment test can be quite expensive. So I'd be happy to qualify this as a bug. If you want a safe and fast way to test that the parent of w is WB, you can use: WB.is_parent_of(w) Ok, thank you! On a similar note, should containment only hold if the objects are typed? Currently we have sage: [[1,2,3],[2]] in Tableaux() True Should I do the same for weak tableaux? Currently sage: T = WeakTableaux(3, [1], [1]) sage: [[1]] in T False sage: T([[1]]) in T True which I think is a better behavior, but would not be consistent with the tableaux behavior! Best, Anne -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Products of permutations use nonstandard order of operation
Hi, I also strongly support both left and right actions, with the syntax Left action: s1(s2(x)) == (s1*s2)(x) Right action: (x^s1)^s2 == x^(s1*s2) Currently the left (functional) notation is implemented in Sage with the right order of application: s1(s2(x)) == (s2*s1)(x) is True. This needs to be either accepted or deprecated in preference to a new right operator. Magma implements only the right action with ^ notation, and GAP also (only?) implements the same. Attention: Unless I'm mistaken, Magma does something bad with operator precedence in order to have x^s1^s2 evaluate to (x^s1)^s2 rather than x^(s1^s2) -- the latter is defined but not equal. The significant change is that a left acting symmetric group will have its multiplication reversed. Implementing the right action involves some thought, since it must be a method on the domain class. Either the domain must be a designated class of G-sets, which knows about its acting group G, or for each object with a natural permutation action, one needs to implement or overload ^ on a case-by-case basis (e.g. integers, free modules, polynomial rings and other free objects [action on the generators], etc.). Please correct me if there is another way to drop through and pick up an action operation on the right-hand argument. Defining the (left or right) action by * would probably be a nightmare with the coercion model, since it is handled as a symmetric operator. Some thought needs to be given to the extension from a group action to a group algebra action. The ZZ-module structure of an abelian group with left G-action would give an argument to admitting * as a possible (left) notation for this operation, despite the obvious headaches. The ^ notation would give a compatible extension of the natural ZZ-module structure acting on the right on a multiplicatively represented abelian group. As an example, in number theory, when G is a Galois group Gal(L/K), it is typical to left K[G] act on the left on L by *, and ZZ[G] act on the right on multiplicative group L^*. Although G is not a permutation group in this example, we want to set up the framework for G-sets to admit these natural actions. The left action is problematic, since the coercion model is susceptible to building L[G] and carry out * with the trivial G-action on L. To avoid this, L needs to be identified as an object in the category of K-modules (with G-action) rather than a K-algebra. Until someone comes up with a well-developed and coherent model for treating the operator * in general G-actions, I would avoid any implementations using this operator with permutation actions. --David -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: change_ring and affine patches for toric varieties
Unfortunately, it is still necessary in 5.11.beta3: sage: R = PolynomialRing(QQ, 3, x).fraction_field() sage: R Fraction Field of Multivariate Polynomial Ring in x0, x1, x2 over Rational Field sage: R(SR(x0/x1)) x0/x1 sage: R(x0/x1) Traceback (most recent call last): ... TypeError: no canonical coercion from Fraction Field of Multivariate Polynomial Ring in x0, x1, x2 over Rational Field to Rational Field And I certainly used fractional coefficients like that, so let's not just remove SR - I'll think about alternatives. Perhaps we can try to use SR only when not using it fails. On Monday, 15 July 2013 20:08:30 UTC-6, Volker Braun wrote: Yes that line looks suspicious... On Monday, July 15, 2013 7:40:36 PM UTC-4, Ursula wrote: # Direct conversion a/b to F does not work in Sage-4.6.alpha3, # so we go through SR, even though it is quite slow. coefficients = (F(SR(coef)) for coef in coefficients) -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: change_ring and affine patches for toric varieties
Patch is up, will be waiting for the next problem! http://trac.sagemath.org/sage_trac/ticket/14899 On Tuesday, 16 July 2013 09:14:01 UTC-6, Andrey Novoseltsev wrote: Unfortunately, it is still necessary in 5.11.beta3: sage: R = PolynomialRing(QQ, 3, x).fraction_field() sage: R Fraction Field of Multivariate Polynomial Ring in x0, x1, x2 over Rational Field sage: R(SR(x0/x1)) x0/x1 sage: R(x0/x1) Traceback (most recent call last): ... TypeError: no canonical coercion from Fraction Field of Multivariate Polynomial Ring in x0, x1, x2 over Rational Field to Rational Field And I certainly used fractional coefficients like that, so let's not just remove SR - I'll think about alternatives. Perhaps we can try to use SR only when not using it fails. On Monday, 15 July 2013 20:08:30 UTC-6, Volker Braun wrote: Yes that line looks suspicious... On Monday, July 15, 2013 7:40:36 PM UTC-4, Ursula wrote: # Direct conversion a/b to F does not work in Sage-4.6.alpha3, # so we go through SR, even though it is quite slow. coefficients = (F(SR(coef)) for coef in coefficients) -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Products of permutations use nonstandard order of operation
Hi David,
On 2013-07-16, David Kohel drko...@gmail.com wrote:
Defining the (left or right) action by * would probably be a
nightmare with the coercion model, since it is handled as
a symmetric operator.
Is this really so?
There is stuff in sage.structure.coerce, for example methods
R.get_action(S,operator.mul),
which can be overloaded using R._get_action_, where you can also decide on the
side from which S acts.
Hence, if you want to let S act on R from the left by multiplication, you could
simply let S._get_action_(R, operator.mul, True) return an action, and
if you want to let S act on R from the right by multiplication, you
could let S._get_action_(R, operator.mul, False) return an action.
Here, action means something like the stuff in
sage.structure.coerce_acitons.
Let's try an example:
sage: from sage.structure.coerce_actions import GenericAction
sage: class MyAction(GenericAction):
: def _call_(self, x, y):
: if self.is_left():
: return x.left_action(y)
: return y.right_action(x)
:
sage: from sage.structure.element import Element
sage: class MyElement(Element):
: def __init__(self, s, parent=None):
: self.s = s
: Element.__init__(self, parent)
: def left_action(self, n):
: return self.__class__(self.s+repr(n), self.parent())
: def right_action(self, n):
: return self.__class__(self.s*n, self.parent())
:
sage: class MyParent(Parent):
: Element = MyElement
: def _get_action_(self, S, op, self_is_left):
: if op is operator.mul:
: return MyAction(self, S, self_is_left, check=False)
: def _element_constructor_(self, s):
: return self.element_class(s, self)
:
sage: P = MyParent(category=Objects())
sage: a = P('hi')
sage: a.s
'hi'
sage: b = a*5
sage: b.s
'hi5'
sage: c = 3*a
sage: c.s
'hihihi'
So, this should show how to implement left and right actions.
Of course, the mathematical property of being an action must be ensured
by a correct implementation of the action.
In particular, note that technically I have implemented an action of
MyParent on ZZ, but in fact I did so in order to get two different
actions of ZZ on MyParent.
Best regards,
Simon
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Is there a reason for g_algebras not working over rings with parameters?
Ok, i investigated a little bit, and found one source of problems. But it revealed a deeper problem: plural interface does not allow fields with parameters. I opened ticket #14886. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
