Hi Travis,
Thanks for your suggestion! I'll experiment with it later today.
Also, if you're not really using matrices, such as doing a significant
> number of multiplications/using category model/etc., but instead as a nice
> data structure, I'd be more inclined to say to strip out the non
> s
Hey Stefan,
From just looking at the function, there is only one case in the for
loop that is non-trivial, so I'm thinking the function could be
restructured as:
cdef bint __exchange(self, long x, long y):
"""
Put element indexed by ``x`` into basis, taking out element ``y
I'm under the following impression, somebody correct me if I'm wrong: Their
only real application for matrices are as a container of row vectors. And
Sage's add_multiple_of_row is just the generic implementation for most
(all?) backends.
On Sunday, May 26, 2013 11:33:08 AM UTC+1, Martin Albr
Overall timings aren't really that useful, without profiling there is no
way to tell what part is slow. Can you at least give your own matrix class
the same interface as Sage matrices? It should only be a matter of
switching from ... import ... as MyMatrix. If they are not interchangeable
then
Hi all,
I didn't follow the thread but for me it would be helpful to get a self
contained description of what the performance issue is with current Sage
matrices:
What operations at what dimensions are slow?
> P.S. It looks like GF(4)-matrices had a speed regression between 5.9 and
> 5.10?!
Hi Volker, and everyone else on sage-devel,
I did some speed tests with an old version of the code that still used Sage
matrices (commit 6d9e689 on bitbucket, with a few tweaks to make it run on Sage
5.10.beta4). Each of these tests performs a matroid computation through
extensive pivoting.
I
If that is actually the bottleneck then the relevant matrices just need to
override add_multiple_of_row_c with a specialized version instead of using
the generic one from matrix0.
It seems that renaming Sage's add_multiple_of_row() into row_add() etc. in
your code is just making it unnecessaril
On Saturday, May 25, 2013 11:22:38 AM UTC-4, Volker Braun wrote:
> On Saturday, May 25, 2013 3:51:06 PM UTC+1, Stefan wrote:
>
>> There's likely to be some performance loss even when all obvious
>> bottlenecks are accounted for, because for our special classes
>> BinaryMatrix, TernaryMatrix, Qua
On Saturday, May 25, 2013 3:51:06 PM UTC+1, Stefan wrote:
> There's likely to be some performance loss even when all obvious
> bottlenecks are accounted for, because for our special classes
> BinaryMatrix, TernaryMatrix, QuaternaryMatrix we use inline get() and set()
> methods that bypass the S
> I'd have to check carefully. There's likely to be some performance loss
> even when all obvious bottlenecks are accounted for, because for our
> special classes BinaryMatrix, TernaryMatrix, QuaternaryMatrix we use inline
> get() and set() methods that bypass the Sage finite field elements. W
On Saturday, May 25, 2013 6:38:00 AM UTC-4, Volker Braun wrote:
> On Saturday, May 25, 2013 2:39:36 AM UTC+1, Travis Scrimshaw wrote:
>
>> * either replace the private reimplementation of matrices or give a
>>> good reason for why it is necessary
>>>
>> Wasn't the second point addressed in htt
On Saturday, May 25, 2013 2:39:36 AM UTC+1, Travis Scrimshaw wrote:
> * either replace the private reimplementation of matrices or give a good
>> reason for why it is necessary
>>
> Wasn't the second point addressed in http://trac.sagemath.org/14627, so
>> shouldn't the matrices be replaced?
Hey,
I'm for accepting en masse since it is (mostly) self-contained, provided
the doc builds cleanly too. From a skim-through of the patch, it seems like
there is some documentation formatting I'd like to see changed (and some
things that might be misformatted). However we can fix this up over
On 25/05/2013, at 1:09 AM, William Stein wrote:
>
> And it has 100% doctest coverage. (It does, right?)
Yes, it does. We made sure of that before submitting.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and st
On May 24, 2013 3:24 AM, "David Joyner" wrote:
>
> On Thu, May 23, 2013 at 4:31 PM, Rob Beezer
wrote:
> > Dear sage-devel,
> >
>
> ...
>
> >
> > So I would be in favor of accepting this en masse if it had a
knowledgeable
> > review for fitting into Sage, as Nathann and Volcker propose. I also
ho
On Thu, May 23, 2013 at 4:31 PM, Rob Beezer wrote:
> Dear sage-devel,
>
...
>
> So I would be in favor of accepting this en masse if it had a knowledgeable
> review for fitting into Sage, as Nathann and Volcker propose. I also hope
+1
..
>
> Rob
>
>
--
You received this message because you
I think the following needs to be addressed:
* segmentation faults due to recent changes in Sage
* either replace the private reimplementation of matrices or give a good
reason for why it is necessary
Then it is imho ready for inclusion.
On Friday, May 24, 2013 9:52:49 AM UTC+1, Nathann Cohe
> I agree with everything except the spelling of my name ;-)
Sooo how do we do ? We check that the ticket is up to date,
does not break doctests, and we set it to "positive review" with as
reviewer "The Sage Team" ? :-P
Otherwise they may have to rebase their patch every second day.
Nath
On Thursday, May 23, 2013 9:31:46 PM UTC+1, Rob Beezer wrote:
> So I would be in favor of accepting this en masse if it had a
> knowledgeable review for fitting into Sage, as Nathann and Volcker propose.
I agree with everything except the spelling of my name ;-)
--
You received this messag
On 2013-05-24, Dima Pasechnik wrote:
> On Friday, 24 May 2013 04:31:46 UTC+8, Rob Beezer wrote:
>>
>>
>> So I would be in favor of accepting this en masse if it had a
>> knowledgeable review for fitting into Sage, as Nathann and Volcker
>> propose.
>
> I second this, too.
I third this, three
On Friday, 24 May 2013 04:31:46 UTC+8, Rob Beezer wrote:
>
>
> So I would be in favor of accepting this en masse if it had a
> knowledgeable review for fitting into Sage, as Nathann and Volcker
> propose.
I second this, too.
Dima
>
>>
--
You received this message because you are subscr
>
>
> Finally, thanks to the sage-matroid group for all their hard work on
> this. It is going to be another jewel in Sage's crown.
>
Hear, hear! As long as it's not a Silmaril...
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscri
Dear sage-devel,
Late to the party, as usual. I've been following the sage-matroid list
since its inception, helping out where I can. Stefan, Rudi and others,
have been *very* responsive to bug reports on their work-in-progress. The
current users are a very knowledgeable bunch (both in mat
> It is a possibility, and would be pretty feasible, but an inferior solution.
> From our point of view (and our audience), having the code be an actual part
> of Sage is just more convenient. It makes sure we have full access to the
> bug reporting of Trac, and it lowers the threshold for contribu
> How easy/feasible would it be to create an spkg and propose it to be added
> as an optional package?
>
> Is that another possibility?
>
It is a possibility, and would be pretty feasible, but an inferior
solution. From our point of view (and our audience), having the code be an
actual part o
On Thu, May 2, 2013 at 2:40 PM, Stefan van Zwam wrote:
> Dear Sage developers,
>
> Over the past two years I've been working with several people on bringing
> Matroid Theory to Sage. We wanted this to be research-level code that will
> remain relevant for a long time, so we decided to have the des
Dear Sage developers,
Over the past two years I've been working with several people on bringing
Matroid Theory to Sage. We wanted this to be research-level code that will
remain relevant for a long time, so we decided to have the design mature for a
while before integrating it with Sage. By now
27 matches
Mail list logo
