Cheers. Could have sworn I'd tried that, but apparently not.
On Sunday, May 26, 2013 5:07:11 PM UTC-5, leif wrote:
>
> csar wrote:
> > I seem to be unable to apply patches as Mercurial's trying to apply the
> > patch in the wrong place. I get:
> >
> > [Errno 20] Not a directory:
> > '/Applica
Volker Braun wrote:
This is almost certainly a long-running computation in C/Cython that is
not properly wrapped in sig_on() / sig_off(). So Ctrl-C handling is not
enabled.
In C++ that is (NTL). ;-)
Interrupting it after it has eaten up a few GB (growing), I get:
Program received signal SIGIN
This is almost certainly a long-running computation in C/Cython that is not
properly wrapped in sig_on() / sig_off(). So Ctrl-C handling is not enabled.
On Sunday, May 26, 2013 11:23:56 PM UTC+1, Marco Streng wrote:
>
> sage: subOrderK = L.order(bas + [b*alpha for b in bas])
>
> ^C^C^C^C^C^C^C^C^
On Fri, May 24, 2013 at 10:38 AM, Karl-Dieter Crisman
> wrote:
> > Just pass this on to anyone who might know the answer (you? sage-nt?) -
> the
> > same person asked this twice:
> >
> >
> http://stackoverflow.com/questions/11850418/computing-maximal-orders-in-large-number-fields-with-sage
> >
> >
csar wrote:
I seem to be unable to apply patches as Mercurial's trying to apply the
patch in the wrong place. I get:
[Errno 20] Not a directory:
'/Applications/sage/sage/combinat/posets/posets.py'
patch failed, rejects left in working dir
when it should be trying in /Applications/sage/devel/sag
I seem to be unable to apply patches as Mercurial's trying to apply the
patch in the wrong place. I get:
[Errno 20] Not a directory:
'/Applications/sage/sage/combinat/posets/posets.py'
patch failed, rejects left in working dir
when it should be trying in /Applications/sage/devel/sage/sage/...
On Sat, May 25, 2013 at 04:33:08PM +, Simon King wrote:
> > See http://trac.sagemath.org/sage_trac/ticket/14385 .
>
> So, automatic it is. Great!
Yes! Thanks again to Robert for removing this former regular source of
conflicts!
Cheers,
Nicolas
--
Nicolas M. Th
On Saturday, May 25, 2013 6:31:59 PM UTC+2, kcrisman wrote:
>
> We already know about some of the other Sage products with potential
> confusion…
Yes indeed. I updated our legal notice.
H
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To u
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
Hey, it's exactly what I was talking about :-D
Except that they have a "committee". But well.
It does no seem so big, though. I wonder if I will join it or fork it :-)
Thaaanks !
And if anybody here is interested, please drop a line !
Nathann
On 26 May 2013 00:46, Paul-Olivier
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?!
12 matches
Mail list logo
