#20103: Some clean up in simplicial complexes
-------------------------------------+-------------------------------------
       Reporter:  jhpalmieri         |        Owner:
           Type:  enhancement        |       Status:  needs_review
       Priority:  minor              |    Milestone:  sage-7.1
      Component:  algebraic          |   Resolution:
  topology                           |    Merged in:
       Keywords:                     |    Reviewers:
        Authors:  John Palmieri      |  Work issues:
Report Upstream:  N/A                |       Commit:
         Branch:  u/jhpalmieri       |  6fb881a4de6cfa94cad0481120cbd2c48d3ee077
  /complex-cleanup                   |     Stopgaps:
   Dependencies:                     |
-------------------------------------+-------------------------------------

Comment (by jhpalmieri):

 Replying to [comment:6 tscrim]:
 > Replying to [comment:5 jhpalmieri]:
 > > Replying to [comment:4 tscrim]:
 > > > Some quick comments:
 >
 > > > - I think this would benefit from using `@total_ordering` (in
 reality, we probably should implement a generic `__ne__` for `Element`...)
 so we don't have so many little methods for all of the comparison
 operators.
 > >
 > > I think I tried this for one of the classes and ran into problems.
 I'll try again and see what happens. (Actually, this may have been for a
 draft of a simplex class for use with simplicial sets, and it might have
 been a conflict with `UniqueRepresentation` or `EqualityById` or something
 like that.)
 >
 > It shouldn't have any problems because it is used for the elements,
 which are not subclasses of `EqualityById` (plus implementing an `__eq__`
 nullifies the use of that class). `@total_ordering` does modify the class,
 but this should be done at initialization of the module. Thus it is done
 before category framework gets its hands on it (via `Element`) when an
 instance of the parent class is created.

 I tried it and it looks okay. I'll make that change.

 >
 > > > - I'm actually not sure if the output of a (python) `set` is
 (attempted to be) sorted as for a `dict`. So I'm not sure if we need to
 explicitly call `sorted`.
 > >
 > > Python sets are by definition unordered, so it seems safest to
 explicitly call sort.
 >
 > Right, but the doctesting framework sorts the output of (some) things
 automatically when running tests on a file to avoid having to do machine-
 independent/memory-independent tests. I'm not opposed to doing the sort,
 but just a note.

 It is completely opaque to me how this is done. Maybe by the code in
 `repl/display/pretty_print.py` and `fancy_repr.py`? I only see references
 to dictionaries being sorted by keys, not for other data types.

 > > > - Should we cythonize `algebraic_topological_model` now? It probably
 won't be too hard and we could get some speedup from that.
 > >
 > > I am probably not the person to do that. It could safely go on another
 ticket, since it seems independent of the changes here.
 >
 > I can cythonize it on a separate ticket then.

 CC me on it and I will review it.

--
Ticket URL: <http://trac.sagemath.org/ticket/20103#comment:7>
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 https://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.

Reply via email to