On Feb 6, 2009, at 7:18 PM, kcrisman wrote:
>
>>
>> Depending on what you're doing with the permutations, all your time
>> may be spent elsewhere, and compiling your snippet may not help.
>> Specifically, if you don't "cdef" anything I'd be surprised to see a
>> big speedup, but if you cimport permutation group elements directly
>> you could probably be 100x faster.
>
> Could you be more specific (e.g. give a toy example of how to
> "cimport" Permutations(n) and then use it to do something trivial, for
> someone who is still very new at using Cython)? I assume this is the
> sort of thing that could be %cython'ed in the notebook.
Permutations is not a Cython class, so you can't cimport it. It's
also using generic Python code, so no matter how quick you are with
the permutations you get, the bottleneck might be just listing them.
However, here's another example:
%cython
from sage.groups.perm_gps.permgroup_element cimport
PermutationGroupElement
def apply_perm(PermutationGroupElement a, list L):
assert len(L) == a.n
cdef list permuted = [None] * len(L)
cdef int i
for i in range(a.n):
permuted[a.perm[i]] = L[i]
return permuted
------------------------------
sage: a = SymmetricGroup(10).random_element(); a
(1,5,8)(2,10)(3,6,9,4)
sage: apply_perm(a, range(1, 11))
[8, 10, 4, 9, 1, 3, 7, 5, 6, 2]
> As to the iterators, I essentially used exactly the same ideas for my
> summer research student in enumerating some combinatorial data, and it
> was *painfully* slow - but I assumed it just had to be that slow. I
> will try rewriting it with this iterator construction.
Ideally, the obvious way should be the fast way. I'm sure this
specific problem can be done much faster.
> So my question: Unlike the OP, I constructed a Python generator object
> for my stuff, rather than a list comprehension, thinking it wouldn't
> have to iterate all the way to the last point each time, and so my
> poor little computer would be spared having to create the whole list I
> needed ahead of time. Was I incorrect about that - do generators not
> "cache the last value", as William says? I guess I would rather not
> use generators (yield) if they don't actually save any computation
> time or memory, since lists are so much easier to write.
Generators save memory, sometimes at the expense of a little time
(depending on the relative overhead of a function call).
>> for i in range(factorial(n)):
>> vp=v.next(vp)
is potentially very slow, as you are not using a generator at all.
This function is meant to be used for "random access" rather than
"sequential access" (to use a computer memory analogy). Here's the code:
v.next??
File: /Users/robert/sage/sage-3.1.3/local/lib/python2.5/site-packages/
sage/combinat/combinat.py
Source Code (starting at line 1146):
def __next_from_iterator(self, obj):
"""
Default implementation for next which uses iterator.
EXAMPLES:
sage: C = CombinatorialClass()
sage: C.list = lambda: [1,2,3]
sage: C.next(2) # indirect doctest
3
"""
found = False
for i in self.iterator():
if found:
return i
if i == obj:
found = True
return None
- Robert
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to
sage-support-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sage-support
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
