#16836: __neg__ fails in CartesianProduct of CombinatorialFreeModule
-------------------------------------------------+-------------------------
Reporter: cnassau | Owner:
Type: defect | Status: closed
Priority: major | Milestone: sage-6.4
Component: categories | Resolution: fixed
Keywords: | Merged in:
Authors: Christian Nassau | Reviewers: Vincent
Report Upstream: N/A | Delecroix
Branch: | Work issues:
6e9cf9e72ced0969fd920eca5437f2e3c1d33009 | Commit:
Dependencies: | Stopgaps:
-------------------------------------------------+-------------------------
Changes (by vdelecroix):
* commit: 6e9cf9e72ced0969fd920eca5437f2e3c1d33009 =>
Comment:
Salut Nicolas,
Replying to [comment:22 nthiery]:
> Replying to [comment:21 vdelecroix]:
> > It was completely wrong with several respects that were discussed
here... (the least being not working).
>
> It was indeed broken for cartesian products of free modules, but
> working smoothly and with a well defined behaviour for the other
> cartesian products.
>
> Note by the way that `_neg_` was working smoothly:
> {{{
> sage: X=CombinatorialFreeModule(ZZ,ZZ)
> sage: Y=cartesian_product((X,X))
> sage: x = Y.an_element()
> sage: x._neg_()
> -3*B[(0, -1)] - 2*B[(0, 0)] - 2*B[(0, 1)]
> }}}
This is indeed a bug! `_neg_` should be called but it wasn't!
> Probably we should be consistent, and either use `__neg__` in all
> cases or `_neg_` (which one does not really matter since anyway there
> is no real reason to involve coercion here).
I would just use `__neg__` everywhere. It is faster and consistent with
Python.
> > It is! Concrete examples: #18239. After modifying the `.list()` of the
`PermutationGroup` and the `__hash__` of `PermutationGroupElement` it gets
changed in a lot of places (`algebras/group_algebra.py`,
`categories/enumerated_sets.py`, `categories/modules_with_basis.py`, ...).
But I agree with you that it would have been simpler if they did not.
Perhaps by not random you meant that it depends on the hash or on a
particular order of something that does not have to be ordered.
>
> So, apparently `an_element` was not implemented properly in
> `PermutationGroup`.
It was. The problems were in `modules_with_basis`, `group_algebras`, etc
> By not random, I mean that the result of
> `an_element` is supposed to be reasonably stable over time, in
> particular so that we can use it in tests. Maybe this should be made
> more explicit in the specs of `an_element`. And progressively fixed
> where it not stable enough.
I am not sure I like example looking like
{{{
sage: F = MyBeautifulParent()
sage: e = F.an_element()
sage: ... play with e ...
}}}
It is much more useful to document how to create elements! Nobody want to
play with `.an_element`. It is useful in doctests but I would say only in
the section `TESTS`.
Vincent
--
Ticket URL: <http://trac.sagemath.org/ticket/16836#comment:24>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
