It seems that this is exactly the same problem of something I fixed for
general matrix construction earlier on. See:
http://trac.sagemath.org/sage_trac/ticket/10628
The problem is that the complexity of: sum(some_list_of_lists,[]) is
something like n^2*m where n = len(some_list_of_lists) and m is the length
of all lists contained in some_list_of_lists . This is because when adding
two lists python creates a new copy to store the new result.
If you first flatten your list of entries (so that it doesn't happen in the
cyclotomic field initialization code) the slowness should go away.
I.e. do:
tmp=[]
for v in entries:
tmp.extend(v)
entries = tmp
M = MatrixSpace(F,100)(entries)
Maybe we should overwrite the sum() function such that it behaves different
for lists, since the command sum(entries,[]) looks much more clear and
intuitive then the for loop.
Le mercredi 5 décembre 2012 19:36:07 UTC+1, Nils Bruin a écrit :
>
>
>
> On Wednesday, December 5, 2012 9:08:13 AM UTC-8, Volker Braun wrote:
>>
>> Of course fixing the cyclotomic matrix constructor would be another
>> option ;-
>
> In fact, John, please do! As your own "loop assignment" shows, the problem
> you're experiencing is not inherent to Matrix_cyclo_dense, it's just
> overhead in creating all these intermediate lists. It's straightforward to
> refactor that bit of code and you have a motivation for it now.
>
> Representing a dense matrix as sparse will break you up later, even if
> initial construction doesn't run into the same pitfall.
>
--
You received this message because you are subscribed to the Google Groups
"sage-support" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
Visit this group at http://groups.google.com/group/sage-support?hl=en.
