[sage-support] Re: pyOpenSSL installed web server version still won't run
Thank you for answering. Yes I will do the update once I have a log in. Unfortunately I am having a few issues getting VB to launch the sage appliance without whinging. My audience requires a launch from VBox with no error messages, (even if the messages do not matter!). I am getting the fast tsc error and also the upgrade BIOS addre= blah blah errors. I will fix the wiki so the published appliance will work but wondered whether it might be a good idea to update the appliance that is on the sage site? I am doing a vanilla build with Fedora and will post back whether I manage to achieve a clean build with no errors on launch. Brian On Wednesday, December 5, 2012 1:36:56 AM UTC, Volker Braun wrote: I indeed made some changes to the VM to fix the automatic login issue (or lack thereof). I haven't updated the wiki page. It would be great if you could make the changes, since you seem to have figured out what to do ;-) On Wednesday, December 5, 2012 12:45:10 AM UTC, nerak99 wrote: Also, anyone know whether the VBox VM maintainer is till around? -- 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: sage disagrees with a paper about strong product of graphs
Hellooo !!! Don't know if this is a bug, but sage numerically disagrees with a paper about strong product of graphs. I would trust Sage in that case :-D I implemented |strong_product| and don't get the same products as sage (C_4 bound passed, the Kneser one didn't pass with my code). What is the drama? (Didn't audit sage's strong_product). Well, did you try Sage's strong_product method, or did you write your own ? Anyway, Sage can compute chromatic numbers in many different ways (see g.chromatic_number? ). I would say that if they all answer the same result then the problem lies in the product, otherwise it (obviously) lies in the coloring functions :-) Good luck ! Nathann -- 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: sage disagrees with a paper about strong product of graphs
On Wed, Dec 05, 2012 at 10:45:28AM +0100, Nathann Cohen wrote: Hellooo !!! Don't know if this is a bug, but sage numerically disagrees with a paper about strong product of graphs. I would trust Sage in that case :-D I implemented |strong_product| and don't get the same products as sage (C_4 bound passed, the Kneser one didn't pass with my code). What is the drama? (Didn't audit sage's strong_product). Well, did you try Sage's strong_product method, or did you write your own ? The sage session i gave was on vanilla sage, didn't include results from my implementation. sage is contradicting at least one more paper on strong products FYI. Anyway, Sage can compute chromatic numbers in many different ways (see g.chromatic_number? ). I would say that if they all answer the same result then the problem lies in the product, otherwise it (obviously) lies in the coloring functions :-) Good luck ! Nathann -- 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: sage disagrees with a paper about strong product of graphs
The sage session i gave was on vanilla sage, didn't include results from my implementation. Good. There's been a patch on this function very recently : http://trac.sagemath.org/sage_trac/ticket/13699 Is your version of Sage more recent than that ? If so, as it looks like there's still a bug, could you attempt to identify what exactly the bug is (and possibly write the patch too) ? :-P Have fn !!! Nathann -- 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: pyOpenSSL installed web server version still won't run
The build script is here if you want to look into the tsc error message: https://bitbucket.org/vbraun/sage-virtual-appliance-buildscript Though it seems this error message is bogous and will be downgraded to devel-level in the kernel soon. So just doing nothing will eventually solve it ;-) On Wednesday, December 5, 2012 8:43:16 AM UTC, nerak99 wrote: I am getting the fast tsc error and also the upgrade BIOS addre= blah blah errors. -- 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.
Re: [sage-support] Re: sage disagrees with a paper about strong product of graphs
On Wed, Dec 05, 2012 at 11:27:21AM +0100, Nathann Cohen wrote: The sage session i gave was on vanilla sage, didn't include results from my implementation. Good. There's been a patch on this function very recently : http://trac.sagemath.org/sage_trac/ticket/13699 Is your version of Sage more recent than that ? I am using sage 5.4 binary download so i suppose I don't have this patch. If so, as it looks like there's still a bug, could you attempt to identify what exactly the bug is (and possibly write the patch too) ? :-P Have fn !!! Nathann -- 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. -- 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.
Re: [sage-support] Re: sage disagrees with a paper about strong product of graphs
Hellooo !! I now have my own cherished computed in front of my hands : sage: C4=graphs.CycleGraph(4);K=graphs.CompleteGraph(3) sage: G=C4.strong_product(K) sage: G.chromatic_number() 6 sage: F=K.strong_product(C4) sage: F.chromatic_number() 6 God, I love those bugfixes The bugfixes which are already written :-P Nathann On 5 December 2012 11:58, Georgi Guninski gunin...@guninski.com wrote: On Wed, Dec 05, 2012 at 11:27:21AM +0100, Nathann Cohen wrote: The sage session i gave was on vanilla sage, didn't include results from my implementation. Good. There's been a patch on this function very recently : http://trac.sagemath.org/sage_trac/ticket/13699 Is your version of Sage more recent than that ? I am using sage 5.4 binary download so i suppose I don't have this patch. If so, as it looks like there's still a bug, could you attempt to identify what exactly the bug is (and possibly write the patch too) ? :-P Have fn !!! Nathann -- 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. -- 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: pyOpenSSL installed web server version still won't run
Thanks for that, I have got to the bit where I am downloading the source into a VMDK based FC17, which is the build of my current Sage server. I will hijack your scripts if that is OK, I am not a cli expert and the scripts will help enormously. On Wednesday, 5 December 2012 10:50:16 UTC, Volker Braun wrote: The build script is here if you want to look into the tsc error message: https://bitbucket.org/vbraun/sage-virtual-appliance-buildscript Though it seems this error message is bogous and will be downgraded to devel-level in the kernel soon. So just doing nothing will eventually solve it ;-) On Wednesday, December 5, 2012 8:43:16 AM UTC, nerak99 wrote: I am getting the fast tsc error and also the upgrade BIOS addre= blah blah errors. -- 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] slow matrix creation
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? 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 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.
[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.z=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
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.z=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 john.crem...@gmail.com 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.z=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
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.z=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 5:00:00 PM UTC, Dima Pasechnik wrote: On 2012-12-05, John Cremona john.c...@gmail.com javascript: 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.z=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 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 2012-12-05, John Cremona john.crem...@gmail.com 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 john.c...@gmail.com javascript: 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.z=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.z=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 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
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
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
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.
