Hi Martin,
On 11 Jul., 23:22, Martin Albrecht
wrote:
> Hi Simon, I createdhttp://trac.sagemath.org/sage_trac/ticket/11589which
> has a patch attached.
Yep, I just noticed.
So, further discussion should take place there.
Cheers,
Simon
--
To post to this group, send an email to sage-devel@goog
Hi Simon, I created http://trac.sagemath.org/sage_trac/ticket/11589 which
has a patch attached.
Cheers,
Martin
On Jul 11, 2011 10:12 PM, "Simon King" wrote:
> On 11 Jul., 23:08, Simon King wrote:
>> I changed sage_malloc into sage_calloc when an empty matrix is to be
>> created. However, the las
First timing looks good.
This is the same example as above, which (in unpatched sage) was 25.8
µs per loop for the creation of a new zero matrix and 13 µs per loop
for copying an existing zero matrix.
With calloc instead of malloc, I obtain:
sage: from sage.matrix.matrix_modn_dense import Matrix
On 11 Jul., 23:08, Simon King wrote:
> I changed sage_malloc into sage_calloc when an empty matrix is to be
> created. However, the last matrix entry is then usually not
> initialized to zero. No idea why.
Sorry, my mistake. I misinterpreted the first argument of calloc. Now
it seems to work, an
Hi!
I changed sage_malloc into sage_calloc when an empty matrix is to be
created. However, the last matrix entry is then usually not
initialized to zero. No idea why.
Cheers,
Simon
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an em
On Mon, Jul 11, 2011 at 07:23:21PM +0100, Martin Albrecht wrote:
> > Would it be difficult to provide sage_calloc? Or would calloc itself
> > be just fine?
>
> No, all that is needed is that (c|m)alloc and free match, hence the
> definition of sage_malloc and sage_free. But one could just call
> s
Hi Martin,
On 11 Jul., 20:23, Martin Albrecht
wrote:
> > Would it be difficult to provide sage_calloc? Or would calloc itself
> > be just fine?
>
> No, all that is needed is that (c|m)alloc and free match, hence the definition
> of sage_malloc and sage_free. But one could just call sage_malloc()
> Would it be difficult to provide sage_calloc? Or would calloc itself
> be just fine?
No, all that is needed is that (c|m)alloc and free match, hence the definition
of sage_malloc and sage_free. But one could just call sage_malloc() +
memset(), there shouldn't be much overhead compared with cal
Hi Martin,
On 11 Jul., 12:58, Martin Albrecht
wrote:
> We are not doing anything special except for calling calloc which zeros the
> memory or we memset() the memory to zero which should still be faster than a
> memcpy().
Matrix_modn_dense does sage_malloc instead. If I understand correctly,
it
Hi Martin,
On 11 Jul., 12:58, Martin Albrecht
wrote:
> We are not doing anything special except for calling calloc which zeros the
> memory or we memset() the memory to zero which should still be faster than a
> memcpy().
I see. Perhaps one should check whether it would work for other
matrices a
On Monday 11 July 2011, Simon King wrote:
> Hi Martin,
Hi Simon,
> On 10 Jul., 20:38, Martin Albrecht
>
> wrote:
> > Which makes sense because we always return a zero matrix when we allocate
> > in M4RI, so copy() is alloc + memcpy while just creating it is just an
> > alloc.
>
> How does th
Hi Martin,
On 10 Jul., 20:38, Martin Albrecht
wrote:
> Which makes sense because we always return a zero matrix when we allocate in
> M4RI, so copy() is alloc + memcpy while just creating it is just an alloc.
How does that work? I learnt the hard way: Allocating memory does not
necessarily mean
Hi Simon,
You have 100x100 matrices in both cases, the same as in my example.
No unfortunately I ended up making a mistake when I was moving code
between sage and my email client.
But what you do here is to use a different number of loops in the
"timeit" function -- you only make 100 runs,
Hi Robert,
On 10 Jul., 21:20, "Robert Goss" wrote:
> I had a go at this and found that for larger matrices it doesnt seem to
> hold (well for me at least)
>
> sage: from sage.matrix.matrix_modn_dense import Matrix_modn_dense
> sage: MS = MatrixSpace(GF(3),100,100)
> sage: M = Matrix_modn_dense(
PS:
I just got an alternative idea, that might be a little faster and more
flexible.
Let MS be a matrix space.
Note that it only (or at least mainly) depends on MS.__matrix_class
whether it is faster to copy or faster to create from scratch.
Hence, why not have a static method of MS.__matrix_cl
Simon,
But it DOES hold for dense matrices over GF(3):
sage: from sage.matrix.matrix_modn_dense import Matrix_modn_dense
sage: MS = MatrixSpace(GF(3),100,100)
sage: M = Matrix_modn_dense(MS, None,True,True)
sage: timeit("M = Matrix_modn_dense(MS, None,True,True)",
number=1)
1 loops, be
Hi Martin,
On 10 Jul., 20:38, Martin Albrecht
wrote:
> Btw. the speed argument does not seem to hold true for dense over GF(2):
>
> sage: MS = MatrixSpace(GF(2),1,1)
> sage: %timeit A = Matrix_mod2_dense(MS,None,True,True)
> 125 loops, best of 3: 2.25 ms per loop
> sage: %timeit _ = copy(
Hi Simon,
> There are ways to create an empty matrix from scratch, whithout
> calling zero_matrix first (namely by calling the matrix class).
Well, it's not very straight-forward, but I agree there is a way (which I
didn't think of before)
sage: from sage.matrix.matrix_mod2_dense import Matrix
Hi Martin,
On 10 Jul., 16:21, Martin Albrecht
wrote:
> which means that whenever on calls matrix(K,m,n) for the first time, it
> creates two matrices which is a very very bad idea when working with big
> matrices (== RAM full)
I was searching the code of the "matrix" function, and the
"zero_matr
19 matches
Mail list logo
