#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 vdelecroix):
Hi,
Replying to [comment:20 nthiery]:
> That being said, I'd like to keep the previous implementation (with
> the fix) for unital magmas. There are cases where this feature can be
> useful! This ticket is about a fix, not an API change.
It was completely wrong with several respects that were discussed here...
(the least being not working).
> Also, whenever possible:
>
> - Please keep existing doctests.
> - Please keep existing TODO's.
True. I was a bit fast on that #18263.
> Two notes:
>
> - `an_element` is *not* random. I don't know why the test was marked
> as such. But in any cases, using `an_element` is usually a nice
> concise idiom to construct an element on which to do tests.
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.
> - 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?
Vincent
--
Ticket URL: <http://trac.sagemath.org/ticket/16836#comment:21>
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.
