[sage-support] Re: slow matrix creation
On 12/6/12 11:40 AM, Nils Bruin wrote: On Thursday, December 6, 2012 2:18:45 AM UTC-8, Volker Braun wrote: I haven't checked this, but I suspect that the naive approach of making a copy of the zero matrix and then filling in the entries with set_unsafe in a loop will be faster. Yes, whoever rewrites that should by all means try that first. Usually, having no intermediate data structures beats constructing them efficiently. Since we're looking at list concatenation anyway: I would have thought the list comprehension and the itertools solution would be in the same ballpark. The itertools solution turns out to be quite a bit faster! Interesting. I would have thought the list comprehension would be faster too. If entries isn't actually used as a list, but just iterated through, there's also no reason to explicitly make R. When the assignment into the matrix is done, you could just iterate through itertools.chain. Thanks, Jason -- You received this message because you are subscribed to the Google Groups "sage-support" group. 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. Visit this group at http://groups.google.com/group/sage-support?hl=en.
[sage-support] Re: slow matrix creation
On Thursday, December 6, 2012 2:18:45 AM UTC-8, Volker Braun wrote: > > I haven't checked this, but I suspect that the naive approach of making a > copy of the zero matrix and then filling in the entries with set_unsafe in > a loop will be faster. > Yes, whoever rewrites that should by all means try that first. Usually, having no intermediate data structures beats constructing them efficiently. Since we're looking at list concatenation anyway: I would have thought the list comprehension and the itertools solution would be in the same ballpark. The itertools solution turns out to be quite a bit faster! L=[[j for j in range(100*i,100*(i+1))] for i in range(100)] def a(L): return [x for y in L for x in y] import itertools def b(L): R=[] R.extend(itertools.chain(*L)) return R def c(L): return sum(L,[]) sage: %timeit a(L) 625 loops, best of 3: 479 µs per loop sage: %timeit b(L) 625 loops, best of 3: 172 µs per loop sage: %timeit c(L) 125 loops, best of 3: 1.73 ms per loop If we take instead sage: L=[[j for j in range(1000*i,1000*(i+1))] for i in range(1000)] sage: %timeit a(L) 25 loops, best of 3: 36.5 ms per loop sage: %timeit b(L) 25 loops, best of 3: 22.5 ms per loop sage: %timeit c(L) 5 loops, best of 3: 7.02 s per loop -- You received this message because you are subscribed to the Google Groups "sage-support" group. 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. Visit this group at http://groups.google.com/group/sage-support?hl=en.
[sage-support] Re: slow matrix creation
I haven't checked this, but I suspect that the naive approach of making a copy of the zero matrix and then filling in the entries with set_unsafe in a loop will be faster. On Wednesday, December 5, 2012 11:24:44 PM UTC, Nils Bruin wrote: > > No, list concatenation does not benefit from balanced trees. > sum(entries,[]) should simply be spelled > L=[] > L.extend(itertools.chain(*entries)) > -- You received this message because you are subscribed to the Google Groups "sage-support" group. 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. Visit this group at http://groups.google.com/group/sage-support?hl=en.
[sage-support] Re: slow matrix creation
PS the slow behaviour also happens with mat.change_ring() since the key line there is mat = M(self.list(), coerce=True, copy=False) where M is the newly created matrix space. Though here, self.list() is a flat list of entries. On Thursday, December 6, 2012 9:08:40 AM UTC, John Cremona wrote: > > > > On Wednesday, December 5, 2012 11:24:44 PM UTC, Nils Bruin wrote: >> >> >> >> On Wednesday, December 5, 2012 2:59:59 PM UTC-8, Maarten Derickx wrote: >>> >>> >>> 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. >>> >>> It seems like the top level sum in sage is already optimized by doing >>> some binary tree balances sum stuff, so maybe just importing that sum in >>> the cyclotomic field code should also fix this performance issue. >>> >> >> No, list concatenation does not benefit from balanced trees. >> sum(entries,[]) should simply be spelled >> L=[] >> L.extend(itertools.chain(*entries)) >> >> You could put that as a special case in sum, but I'd hesitate to do that. >> Most python docs warn against using '+' on lists. >> >> Sometimes it sucks that python has an aversion to being a properly >> functional language. >> >> However, since at this point the expected lengths of all objects involved >> are known anyway, I don't think it should be necessary to construct any of >> these intermediate data structures. Just create the matrices to be >> initialized, loop through the list and write the entries into the right >> spots. >> > > > This has been a very interesting discussion. In my code I have many lists > of lists and often use sum(...,[]) to concatenate them. Now I know not to > do that (at least when the lists are long ot complicated). > > In fact most of the time I first do sum(list-of-lists) and then get the > error message about not being able to add a list to 0, at which point I > insert ",[]", but in future that will serve as a reminder to me to use > something else (I like Nils's itertools solution!) > > John > > -- You received this message because you are subscribed to the Google Groups "sage-support" group. 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. Visit this group at http://groups.google.com/group/sage-support?hl=en.
[sage-support] Re: slow matrix creation
On Wednesday, December 5, 2012 11:24:44 PM UTC, Nils Bruin wrote: > > > > On Wednesday, December 5, 2012 2:59:59 PM UTC-8, Maarten Derickx wrote: >> >> >> 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. >>> >> >> It seems like the top level sum in sage is already optimized by doing >> some binary tree balances sum stuff, so maybe just importing that sum in >> the cyclotomic field code should also fix this performance issue. >> > > No, list concatenation does not benefit from balanced trees. > sum(entries,[]) should simply be spelled > L=[] > L.extend(itertools.chain(*entries)) > > You could put that as a special case in sum, but I'd hesitate to do that. > Most python docs warn against using '+' on lists. > > Sometimes it sucks that python has an aversion to being a properly > functional language. > > However, since at this point the expected lengths of all objects involved > are known anyway, I don't think it should be necessary to construct any of > these intermediate data structures. Just create the matrices to be > initialized, loop through the list and write the entries into the right > spots. > This has been a very interesting discussion. In my code I have many lists of lists and often use sum(...,[]) to concatenate them. Now I know not to do that (at least when the lists are long ot complicated). In fact most of the time I first do sum(list-of-lists) and then get the error message about not being able to add a list to 0, at which point I insert ",[]", but in future that will serve as a reminder to me to use something else (I like Nils's itertools solution!) John -- You received this message because you are subscribed to the Google Groups "sage-support" group. 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. Visit this group at http://groups.google.com/group/sage-support?hl=en.
[sage-support] Re: slow matrix creation
On Wednesday, December 5, 2012 2:59:59 PM UTC-8, Maarten Derickx wrote: > > > 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. >> > > It seems like the top level sum in sage is already optimized by doing some > binary tree balances sum stuff, so maybe just importing that sum in the > cyclotomic field code should also fix this performance issue. > No, list concatenation does not benefit from balanced trees. sum(entries,[]) should simply be spelled L=[] L.extend(itertools.chain(*entries)) You could put that as a special case in sum, but I'd hesitate to do that. Most python docs warn against using '+' on lists. Sometimes it sucks that python has an aversion to being a properly functional language. However, since at this point the expected lengths of all objects involved are known anyway, I don't think it should be necessary to construct any of these intermediate data structures. Just create the matrices to be initialized, loop through the list and write the entries into the right spots. -- You received this message because you are subscribed to the Google Groups "sage-support" group. 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. Visit this group at http://groups.google.com/group/sage-support?hl=en.
[sage-support] Re: slow matrix creation
On 12/5/12 4:54 PM, Maarten Derickx wrote: 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) In a single list comprehension: entries = [item for sublist in entries for item in sublist] (from http://stackoverflow.com/questions/952914/making-a-flat-list-out-of-list-of-lists-in-python) This will most likely be faster than the balanced tree sums in Sage's sum, since even that will create log n new lists. Thanks, Jason -- You received this message because you are subscribed to the Google Groups "sage-support" group. 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. Visit this group at http://groups.google.com/group/sage-support?hl=en.
[sage-support] Re: slow matrix creation
Le mercredi 5 décembre 2012 23:54:24 UTC+1, Maarten Derickx a écrit : > > 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. > It seems like the top level sum in sage is already optimized by doing some binary tree balances sum stuff, so maybe just importing that sum in the cyclotomic field code should also fix this performance issue. > > > 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 sage-support@googlegroups.com. To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-support?hl=en.
[sage-support] Re: slow matrix creation
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 sage-support@googlegroups.com. To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-support?hl=en.
[sage-support] Re: slow matrix creation
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 sage-support@googlegroups.com. To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-support?hl=en.
[sage-support] Re: slow matrix creation
On 2012-12-05, John Cremona wrote:
> --=_Part_659_23379607.1354727026909
> Content-Type: text/plain; charset=ISO-8859-1
>
>
>
> On Wednesday, December 5, 2012 5:00:00 PM UTC, Dima Pasechnik wrote:
>>
>> On 2012-12-05, John Cremona > wrote:
>> > --=_Part_32_14834482.1354721238473
>> > Content-Type: text/plain; charset=ISO-8859-1
>> >
>> >
>> >
>> > On Wednesday, December 5, 2012 1:56:55 PM UTC, Jason Grout wrote:
>> >>
>> >> On 12/5/12 7:46 AM, John Cremona wrote:
>> >> > I don't know why this takes so long:
>> >> >
>> >> > I have a field F (a snumber field of high degree, 288 in fact) and
>> >> > want to create a 100x100 matrix over F from a list of 100 lists of
>> 100
>> >> > elements of F, while I will call "entries". If I do
>> >> >
>> >> > M = Matrix(entries)
>> >> >
>> >> > which certainly works fine with smaller examples, then I get tired of
>> >> > waiting (after 10 or 15 minutes) and cannot even interrupt with
>> >> > Ctrl-C. But if I do
>> >> >
>> >> > M = copy(MatrixSpace(F,100).zero_matrix())
>> >> > for i in range(100):
>> >> > for j in range(100):
>> >> >M[i,j] = entries[i,j]
>> >> >
>> >> > it works in a few seconds. So what is going wrong with the first
>> >> (simpler) way?
>> >>
>> >> If you just do Matrix(entries), it tries to guess the right base ring
>> >> (using the Sequence() command, IIRC). In the second example, you are
>> >> explicitly telling Sage the base ring. I wonder if that is what is
>> >> going on. To check, can you try doing:
>> >>
>> >> matrix(F, entries)
>> >>
>> >>
>> > That is slow too. Try
>> >
>> >
>> > Q1092.=CyclotomicField(1092)
>> > entries = [[Q1092.zero_element() for i in range(100)] for j in
>> range(100)]
>> > M=Matrix(Q1092,entries)
>> >
>> > which takes a long time (*) and cannot be interrupted with Ctrl-C.
>>
>> from what Volker wrote, it can be gathered that
>> M=Matrix(Q1092,entries,sparse=True)
>> might work much faster.
without sparse=True during initialization
you are creating a *dense* representation of 0 of your field, for
each matrix entry, and this hurts...
I just tried the following (note that I relaced 0's by 1's, so I am not
creating an empty sparse matrix, but actually a fully dense sparse
matrix):
sage: Q1092.=CyclotomicField(1092)
sage: entries = [[Q1092.one() for i in range(100)] for j in range(100)]
sage: timeit('M=Matrix(Q1092,entries,sparse=True)')
5 loops, best of 3: 572 ms per loop
So this is quite quick, isn't it?
>>
>
> But Dima, the actual matrix I want to create has almost no zero entries;
> the zero matrix example was just a simplification to illustrate the issue.
> Or you you actually mean that tagging the matrix as sparse would be worth
> trying even if it is not?
>
> John
>
>
>> Dima
>>
>>
>>
>
--
You received this message because you are subscribed to the Google Groups
"sage-support" group.
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.
Visit this group at http://groups.google.com/group/sage-support?hl=en.
[sage-support] Re: slow matrix creation
On Wednesday, December 5, 2012 5:01:52 PM UTC, John Cremona wrote: > Thanks for the diagnosis! I had forgotten that there was special code > for matrices over cyclotomic fields, but it seems strange that the special > code makes creating such a matrix a lot slower. Perhaps I would be better > off defining my field *not* as a cyclotomic field! Of course fixing the cyclotomic matrix constructor would be another option ;-) -- You received this message because you are subscribed to the Google Groups "sage-support" group. 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. Visit this group at http://groups.google.com/group/sage-support?hl=en.
[sage-support] Re: slow matrix creation
On Wednesday, December 5, 2012 5:00:00 PM UTC, Dima Pasechnik wrote: > > On 2012-12-05, John Cremona > wrote: > > --=_Part_32_14834482.1354721238473 > > Content-Type: text/plain; charset=ISO-8859-1 > > > > > > > > On Wednesday, December 5, 2012 1:56:55 PM UTC, Jason Grout wrote: > >> > >> On 12/5/12 7:46 AM, John Cremona wrote: > >> > I don't know why this takes so long: > >> > > >> > I have a field F (a snumber field of high degree, 288 in fact) and > >> > want to create a 100x100 matrix over F from a list of 100 lists of > 100 > >> > elements of F, while I will call "entries". If I do > >> > > >> > M = Matrix(entries) > >> > > >> > which certainly works fine with smaller examples, then I get tired of > >> > waiting (after 10 or 15 minutes) and cannot even interrupt with > >> > Ctrl-C. But if I do > >> > > >> > M = copy(MatrixSpace(F,100).zero_matrix()) > >> > for i in range(100): > >> > for j in range(100): > >> >M[i,j] = entries[i,j] > >> > > >> > it works in a few seconds. So what is going wrong with the first > >> (simpler) way? > >> > >> If you just do Matrix(entries), it tries to guess the right base ring > >> (using the Sequence() command, IIRC). In the second example, you are > >> explicitly telling Sage the base ring. I wonder if that is what is > >> going on. To check, can you try doing: > >> > >> matrix(F, entries) > >> > >> > > That is slow too. Try > > > > > > Q1092.=CyclotomicField(1092) > > entries = [[Q1092.zero_element() for i in range(100)] for j in > range(100)] > > M=Matrix(Q1092,entries) > > > > which takes a long time (*) and cannot be interrupted with Ctrl-C. > > from what Volker wrote, it can be gathered that > M=Matrix(Q1092,entries,sparse=True) > might work much faster. > But Dima, the actual matrix I want to create has almost no zero entries; the zero matrix example was just a simplification to illustrate the issue. Or you you actually mean that tagging the matrix as sparse would be worth trying even if it is not? John > Dima > > > -- You received this message because you are subscribed to the Google Groups "sage-support" group. 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. Visit this group at http://groups.google.com/group/sage-support?hl=en.
[sage-support] Re: slow matrix creation
On Wednesday, December 5, 2012 4:37:35 PM UTC, Volker Braun wrote: > > All the time is spent in Matrix_cyclo_dense.__init__ where a (nrows*ncols, > Q1092.degree()) rational matrix is constructed by first creating a list of > all nrows*ncols*Q1092.degree() entries: > > elif isinstance(entries, list): > # This code could be made much faster using Cython, etc. > if coerce: > K = parent.base_ring() > entries = [K(a) for a in entries] > entries = sum([a.list() for a in entries], []) > < all the time spent here > self._n = int(self._base_ring._n()) > self._matrix = Matrix_rational_dense(MatrixSpace(QQ, > self._nrows*self._ncols, self._degree), > entries, copy=False, > coerce=False).transpose() > > Thanks for the diagnosis! I had forgotten that there was special code for matrices over cyclotomic fields, but it seems strange that the special code makes creating such a matrix a lot slower. Perhaps I would be better off defining my field *not* as a cyclotomic field! John > > On Wednesday, December 5, 2012 3:27:18 PM UTC, John Cremona wrote: >> >> >> >> On Wednesday, December 5, 2012 1:56:55 PM UTC, Jason Grout wrote: >>> >>> On 12/5/12 7:46 AM, John Cremona wrote: >>> > I don't know why this takes so long: >>> > >>> > I have a field F (a snumber field of high degree, 288 in fact) and >>> > want to create a 100x100 matrix over F from a list of 100 lists of 100 >>> > elements of F, while I will call "entries". If I do >>> > >>> > M = Matrix(entries) >>> > >>> > which certainly works fine with smaller examples, then I get tired of >>> > waiting (after 10 or 15 minutes) and cannot even interrupt with >>> > Ctrl-C. But if I do >>> > >>> > M = copy(MatrixSpace(F,100).zero_matrix()) >>> > for i in range(100): >>> > for j in range(100): >>> >M[i,j] = entries[i,j] >>> > >>> > it works in a few seconds. So what is going wrong with the first >>> (simpler) way? >>> >>> If you just do Matrix(entries), it tries to guess the right base ring >>> (using the Sequence() command, IIRC). In the second example, you are >>> explicitly telling Sage the base ring. I wonder if that is what is >>> going on. To check, can you try doing: >>> >>> matrix(F, entries) >>> >>> >> That is slow too. Try >> >> >> Q1092.=CyclotomicField(1092) >> entries = [[Q1092.zero_element() for i in range(100)] for j in range(100)] >> M=Matrix(Q1092,entries) >> >> which takes a long time (*) and cannot be interrupted with Ctrl-C. >> >> John >> >> (*) I have not yet had the patience to wait until it completes! >> >> >> >>> Thanks, >>> >>> Jason >>> >>> >>> -- You received this message because you are subscribed to the Google Groups "sage-support" group. 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. Visit this group at http://groups.google.com/group/sage-support?hl=en.
[sage-support] Re: slow matrix creation
On 2012-12-05, John Cremona wrote: > --=_Part_32_14834482.1354721238473 > Content-Type: text/plain; charset=ISO-8859-1 > > > > On Wednesday, December 5, 2012 1:56:55 PM UTC, Jason Grout wrote: >> >> On 12/5/12 7:46 AM, John Cremona wrote: >> > I don't know why this takes so long: >> > >> > I have a field F (a snumber field of high degree, 288 in fact) and >> > want to create a 100x100 matrix over F from a list of 100 lists of 100 >> > elements of F, while I will call "entries". If I do >> > >> > M = Matrix(entries) >> > >> > which certainly works fine with smaller examples, then I get tired of >> > waiting (after 10 or 15 minutes) and cannot even interrupt with >> > Ctrl-C. But if I do >> > >> > M = copy(MatrixSpace(F,100).zero_matrix()) >> > for i in range(100): >> > for j in range(100): >> >M[i,j] = entries[i,j] >> > >> > it works in a few seconds. So what is going wrong with the first >> (simpler) way? >> >> If you just do Matrix(entries), it tries to guess the right base ring >> (using the Sequence() command, IIRC). In the second example, you are >> explicitly telling Sage the base ring. I wonder if that is what is >> going on. To check, can you try doing: >> >> matrix(F, entries) >> >> > That is slow too. Try > > > Q1092.=CyclotomicField(1092) > entries = [[Q1092.zero_element() for i in range(100)] for j in range(100)] > M=Matrix(Q1092,entries) > > which takes a long time (*) and cannot be interrupted with Ctrl-C. from what Volker wrote, it can be gathered that M=Matrix(Q1092,entries,sparse=True) might work much faster. Dima -- You received this message because you are subscribed to the Google Groups "sage-support" group. 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. Visit this group at http://groups.google.com/group/sage-support?hl=en.
[sage-support] Re: slow matrix creation
All the time is spent in Matrix_cyclo_dense.__init__ where a (nrows*ncols, Q1092.degree()) rational matrix is constructed by first creating a list of all nrows*ncols*Q1092.degree() entries: elif isinstance(entries, list): # This code could be made much faster using Cython, etc. if coerce: K = parent.base_ring() entries = [K(a) for a in entries] entries = sum([a.list() for a in entries], []) < all the time spent here self._n = int(self._base_ring._n()) self._matrix = Matrix_rational_dense(MatrixSpace(QQ, self._nrows*self._ncols, self._degree), entries, copy=False, coerce=False).transpose() On Wednesday, December 5, 2012 3:27:18 PM UTC, John Cremona wrote: > > > > On Wednesday, December 5, 2012 1:56:55 PM UTC, Jason Grout wrote: >> >> On 12/5/12 7:46 AM, John Cremona wrote: >> > I don't know why this takes so long: >> > >> > I have a field F (a snumber field of high degree, 288 in fact) and >> > want to create a 100x100 matrix over F from a list of 100 lists of 100 >> > elements of F, while I will call "entries". If I do >> > >> > M = Matrix(entries) >> > >> > which certainly works fine with smaller examples, then I get tired of >> > waiting (after 10 or 15 minutes) and cannot even interrupt with >> > Ctrl-C. But if I do >> > >> > M = copy(MatrixSpace(F,100).zero_matrix()) >> > for i in range(100): >> > for j in range(100): >> >M[i,j] = entries[i,j] >> > >> > it works in a few seconds. So what is going wrong with the first >> (simpler) way? >> >> If you just do Matrix(entries), it tries to guess the right base ring >> (using the Sequence() command, IIRC). In the second example, you are >> explicitly telling Sage the base ring. I wonder if that is what is >> going on. To check, can you try doing: >> >> matrix(F, entries) >> >> > That is slow too. Try > > > Q1092.=CyclotomicField(1092) > entries = [[Q1092.zero_element() for i in range(100)] for j in range(100)] > M=Matrix(Q1092,entries) > > which takes a long time (*) and cannot be interrupted with Ctrl-C. > > John > > (*) I have not yet had the patience to wait until it completes! > > > >> Thanks, >> >> Jason >> >> >> -- You received this message because you are subscribed to the Google Groups "sage-support" group. 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. Visit this group at http://groups.google.com/group/sage-support?hl=en.
[sage-support] Re: slow matrix creation
On Wednesday, December 5, 2012 1:56:55 PM UTC, Jason Grout wrote: > > On 12/5/12 7:46 AM, John Cremona wrote: > > I don't know why this takes so long: > > > > I have a field F (a snumber field of high degree, 288 in fact) and > > want to create a 100x100 matrix over F from a list of 100 lists of 100 > > elements of F, while I will call "entries". If I do > > > > M = Matrix(entries) > > > > which certainly works fine with smaller examples, then I get tired of > > waiting (after 10 or 15 minutes) and cannot even interrupt with > > Ctrl-C. But if I do > > > > M = copy(MatrixSpace(F,100).zero_matrix()) > > for i in range(100): > > for j in range(100): > >M[i,j] = entries[i,j] > > > > it works in a few seconds. So what is going wrong with the first > (simpler) way? > > If you just do Matrix(entries), it tries to guess the right base ring > (using the Sequence() command, IIRC). In the second example, you are > explicitly telling Sage the base ring. I wonder if that is what is > going on. To check, can you try doing: > > matrix(F, entries) > > That is slow too. Try Q1092.=CyclotomicField(1092) entries = [[Q1092.zero_element() for i in range(100)] for j in range(100)] M=Matrix(Q1092,entries) which takes a long time (*) and cannot be interrupted with Ctrl-C. John (*) I have not yet had the patience to wait until it completes! > Thanks, > > Jason > > > -- You received this message because you are subscribed to the Google Groups "sage-support" group. 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. Visit this group at http://groups.google.com/group/sage-support?hl=en.
[sage-support] Re: slow matrix creation
On 12/5/12 7:46 AM, John Cremona wrote: I don't know why this takes so long: I have a field F (a snumber field of high degree, 288 in fact) and want to create a 100x100 matrix over F from a list of 100 lists of 100 elements of F, while I will call "entries". If I do M = Matrix(entries) which certainly works fine with smaller examples, then I get tired of waiting (after 10 or 15 minutes) and cannot even interrupt with Ctrl-C. But if I do M = copy(MatrixSpace(F,100).zero_matrix()) for i in range(100): for j in range(100): M[i,j] = entries[i,j] it works in a few seconds. So what is going wrong with the first (simpler) way? If you just do Matrix(entries), it tries to guess the right base ring (using the Sequence() command, IIRC). In the second example, you are explicitly telling Sage the base ring. I wonder if that is what is going on. To check, can you try doing: matrix(F, entries) Thanks, Jason -- You received this message because you are subscribed to the Google Groups "sage-support" group. 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. Visit this group at http://groups.google.com/group/sage-support?hl=en.
