#20445: Iteration through finite Coxeter groups
-------------------------+-------------------------------------------------
Reporter: | Owner:
stumpc5 | Status: new
Type: | Milestone: sage-7.2
enhancement | Resolution:
Priority: major | Merged in:
Component: | Reviewers:
combinatorics | Work issues:
Keywords: | Commit:
Authors: | abfff5ffdf5e3d7a90bdaa542ecca3ba2691bffe
Report Upstream: N/A | Stopgaps:
Branch: |
u/stumpc5/20445 |
Dependencies: |
-------------------------+-------------------------------------------------
Comment (by tscrim):
Replying to [comment:29 nthiery]:
> Replying to [comment:27 tscrim]:
> > I'm really starting to consider that what we should do is create our
own separate project where we write all of this independently (in, say,
C/C++). At this stage, I'm somewhat concerned with the additional overhead
that Cython could impose and the lack of complete memory control. Although
I cannot commit serious time to working on this for then next two weeks (I
will be in grading and math mode). Over the summer starting in June, I
should be able to do so.
>
> We can discuss this in Meudon.
Sounds good.
> > I think we can avoid a bit of overhead of maintaining the GAP and
category information. Although it is hard to tell how much of an impact
this will have on things.
>
> For the record: I just checked, and the data structure for permutation
> group elements is just a reference to the parent and a C-list of ints;
> plus a few slots which are unused by default (e.g. a reference to a
> gap element). So the only overhead is copying over the reference to
> the parent, and a bit of extra memory allocation
>
> Of course, the parent itself has stuff about GAP and categories, but
> that's initialized once for all, and does not influence arithmetic on
> elements.
I am partially worried about how much these extra copy operations cost on
the E,,8,, iteration scale, as well as the inherent overhead of the
generated code from Cython. Plus I like having code where we completely
control the memory allocations. It might end up that we really don't see
much of an improvement, but I think it is worth trying.
--
Ticket URL: <http://trac.sagemath.org/ticket/20445#comment:30>
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.
