#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):

 Hi!

 Sorry for dropping in so late; this issue dropped out of my mailbox.

 Thanks for the fix and for the type-checking-free version for
 cartesian products of inverse additive magmas.

 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.

 Also, whenever possible:

 - Please keep existing doctests.
 - Please keep existing TODO's.

 Given that it's late in the process, reinstating those can be in a
 follow up ticket if you prefer. But before next release.

 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.

 - I am usually not a big fan of "coercing silently to a larger
   universe". But don't have a strong opinion either. Anyway, this is
   not directly related to this ticket.

 - 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.

 Thanks again!
                              Nicolas

--
Ticket URL: <http://trac.sagemath.org/ticket/16836#comment:20>
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.

Reply via email to