#16296: Speed improvements for categories with axioms
-------------------------------------+-------------------------------------
       Reporter:  SimonKing          |        Owner:
           Type:  enhancement        |       Status:  new
       Priority:  major              |    Milestone:  sage-6.3
      Component:  categories         |   Resolution:
       Keywords:  cython             |    Merged in:
  performance categories             |    Reviewers:
        Authors:                     |  Work issues:
Report Upstream:  N/A                |       Commit:
         Branch:                     |  df486b82154013df70a9cdf31403fb142c307573
  u/SimonKing/ticket/16296           |     Stopgaps:
   Dependencies:  #10963, #15801,    |
  #16309                             |
-------------------------------------+-------------------------------------

Comment (by nthiery):

 Replying to [comment:42 SimonKing]:
 > Something more about the join:
 >
 > - The cache key is computed with _sort_uniq. Fine, this is cythonised
 already.
 > - There remains a new cython function to create the flattened,
 normalised etc. list of super categories of the to-be-created join.
 > - `Category.join` would be simply like this:
 >   {{{
 >     def join(...):
 >         T = _sort_uniq(...)
 >         try:
 >             if as_list:
 >                 return Category._join_cache[T]._super_categories
 >             return Category._join_cache[T]
 >         except KeyError:
 >             pass
 >         S = create_super_categories(T) # this will be a list!
 >         if as_list:
 >             return S # or do caching?
 >         J = JoinCategory(S)
 >         _join_cache[T] = J
 >         return J
 >   }}}
 > I think this would be a good compromise between cythonisation and
 > "keeping the function where it belongs". In particular, the
 > documentation would stay in `Categories.join`.

 So the core of the join algorithm would be in
 `create_super_categories`, right? Since it's non trivial, we should
 strive hard to keep it easy to find to read, and to debug. But yes,
 this can be an option if we believe the difference is important enough.

 > Since `_sort`, `_sort_uniq` and `_flatten_categories` are not part of
 the docs anyway (or am I mistaken?), I think there should be no problem to
 move these over to the helper module.

 I think I ended up adding them to the docs. But they are explicitly
 private methods, and thus susceptible to be moved at any time if this
 suits us.

 Now, since they are static methods, maybe you could do
 {{{
 from ... import _sort_uniq

 class Category:
     _sort_uniq = _sort_uniq
 }}}
 and then the code could keep using Category._sort_uniq as before, right?

 Cheers,

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