#16836: __neg__ fails in CartesianProduct of CombinatorialFreeModule
-------------------------+-------------------------------------------------
Reporter: | Owner:
cnassau | Status: positive_review
Type: | Milestone: sage-6.4
defect | Resolution:
Priority: major | Merged in:
Component: | Reviewers: Vincent Delecroix
categories | Work issues:
Keywords: | Commit:
Authors: | 6e9cf9e72ced0969fd920eca5437f2e3c1d33009
Christian Nassau | Stopgaps:
Report Upstream: N/A |
Branch: |
public/16836.2 |
Dependencies: |
-------------------------+-------------------------------------------------
Comment (by 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: 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)]
}}}
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).
> 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`. 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.
> > - About `F((xxx,xxx))`: converting from indices of the basis is a nice
> > syntactic sugar indeed. It can't be defined in full generality,
> > because in certain cases there can be ambiguity with coercion from
> > the base ring. For cartesian products, I guess there is no such
> > risk, so that's ok. In any cases that's for user interaction only;
> > in code, one should always use F.term((...)) for genericity and
> > speed.
>
> What is this `term` feature? What is the difference with
`_cartesian_product_of_elements`? Why not using `P.element_class(...)` for
speed?
Sorry, I should have been specific: I was speaking about [comment:7],
with `F` being a free module, not the cartesian product indexing its
basis.
Amitiés,
Nicolas
--
Ticket URL: <http://trac.sagemath.org/ticket/16836#comment:22>
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.
