Ivan Andrus writes:
> Actually Cython itself comes with cython-mode.el [1], so perhaps we
> ought to use that.
IMO this is clearly the way to go :)
-Keshav
Join us in #sagemath on irc.freenode.net !
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe fro
*bump*
Please review, this is needed for gcc.
On 2012-02-09 17:29, Jeroen Demeyer wrote:
> The old (pre-flask-sagenb) Twisted spkg has some .c files with invalid C
> code generated by an old version of Pyrex. This are files which are
> only compiled on OS X Darwin and gcc-4.6.2 fails to compile
On 2012-02-09 20:04, William Stein wrote:
> I'm 100% confident about the statement: "Sage-5.0 is going to include
> the new flask version of the notebook".
Given your post about "Sage-5.0 goals", you are trivially right.
--
To post to this group, send an email to sage-devel@googlegroups.com
To un
On Thu, Feb 9, 2012 at 10:58 AM, Jeroen Demeyer wrote:
> On 2012-02-09 19:26, William Stein wrote:
>> On Thu, Feb 9, 2012 at 8:29 AM, Jeroen Demeyer
>> wrote:
>>> The old (pre-flask-sagenb) Twisted spkg has some .c files with invalid C
>>> code generated by an old version of Pyrex. This are fil
On 2012-02-09 19:26, William Stein wrote:
> On Thu, Feb 9, 2012 at 8:29 AM, Jeroen Demeyer wrote:
>> The old (pre-flask-sagenb) Twisted spkg has some .c files with invalid C
>> code generated by an old version of Pyrex. This are files which are
>> only compiled on OS X Darwin and gcc-4.6.2 fails
Apparently something in the Sage library still depends on Twisted, as
Jeroen noted on #11874 ( http://trac.sagemath.org/sage_trac/ticket/11874 ).
-Keshav
Join us in #sagemath on irc.freenode.net !
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from t
On Thu, Feb 9, 2012 at 8:29 AM, Jeroen Demeyer wrote:
> The old (pre-flask-sagenb) Twisted spkg has some .c files with invalid C
> code generated by an old version of Pyrex. This are files which are
> only compiled on OS X Darwin and gcc-4.6.2 fails to compile them.
> Re-generating these files wi
The old (pre-flask-sagenb) Twisted spkg has some .c files with invalid C
code generated by an old version of Pyrex. This are files which are
only compiled on OS X Darwin and gcc-4.6.2 fails to compile them.
Re-generating these files with a newer version of Pyrex solves the problem.
Please review:
Dear William,
On Mon, 24 Mar 2008, William Stein wrote:
> I would much prefer speeding up Sage matrices rather than incorporating
> MTX into Sage, since the result will in the former case will be much
> easier for users to understand and lots of other codes benefits.
Sure. As a user, i wouldn'
(I'm taking this thread *off* the Cython lists and onto sage-devel
where it belongs.)
On Mon, Mar 24, 2008 at 1:38 PM, Simon King <[EMAIL PROTECTED]> wrote:
> Dear Robert,
>
>
> On Mon, 24 Mar 2008, Robert Bradshaw wrote:
> >
> > Some of us ran into MeatAxe before, but no one had any experienc
On 10/11/07, Stefan Behnel <[EMAIL PROTECTED]> wrote:
> the C-API support has been rewritten for integration in Pyrex, but not much to
...
Hi,
Can I ask a few naive questions about "the C-API support", since I know that
me and _many_ of the people I work with are confused about what this support
On 7/12/07, Stefan Behnel <> wrote:
> Robert Bradshaw wrote:
> > As part of the SAGE project, and due to the difficulty in getting
> > some essential (to us) patches upstream, we have been keeping a
> > separate branch of Pyrex named SageX. It's just Pyrex + (a bunch of
> > patches)
>
> That remin
Wrapping up this, for the record, from a couple of weeks back:
On Jun 29, 2007, at 12:48 AM, Robert Bradshaw wrote:
> As other people have mentioned, there's a factor of 2 overhead in the
> first loop. I'm not sure why you're indexing from 1 either.
Thanks for the comments...
Indeed, I managed
As other people have mentioned, there's a factor of 2 overhead in the
first loop. I'm not sure why you're indexing from 1 either.
As for writing fast pyrex matrix code, M[i,j] is really slow. Here's
what happens:
- A new (len 2) tuple is allocated
- i and j are converted into Python ints (in
On 6/28/07, Justin C. Walker <[EMAIL PROTECTED]> wrote:
> def is_symmetric(self):
> [...]
> for i from 1 <= i < self._nrows:
> for j from 0 <= j < self._ncols:
> [ DO SOMETHING ]
> def is_sym3(self):
> [...]
> for i in xrange(1,self._nrow
"Justin C. Walker" <[EMAIL PROTECTED]> writes:
> if self[i,j] != self[j,i]: return False
One more thought: this could be creating Python ints for i and j each
repetition; optimized indexing might avoid that.
Nick
--~--~-~--~~~---~--~~
To post to
In the first one, you're checking all entries, not just upper-triangular ones.
That'd account for a factor of 2 pretty well.
On Thu, 28 Jun 2007, Justin C. Walker wrote:
>
> Hi,
>
> I tried the following, added to the Matrix class definition in matrix/
> matrix0.pyx:
>
> def is_symmetric(
Two comments, without a great deal of thought or justification.
> if self[i,j] != self[j,i]: return False
This could be getting compiled to a default Python object indexing,
which is slow like molasses. You might want to check the generated C
code and change it to use faster in
On Monday 26 March 2007 12:43 pm, Robert Kern wrote:
> Brian Blais wrote:
> > Hello,
> >
> > I have a class defined in Pyrex (to get speed increases), and python
> > complains that is can't be pickled (class def included below). I looked
> > the documentation, and see that I can define __setstate
On Mon, 18 Dec 2006 12:22:23 -0800, Joel B. Mohler <[EMAIL PROTECTED]> wrote:
> I found a small bit of code that gets compiled incorrectly to c. A sample is:
>
> def unlist():
> lst = [1,2]
> lst,m = lst
>
> The translated c-code from this will produce an Unindexable exception.
On Sun, 29 Oct 2006 11:09:44 -0700, David Harvey
<[EMAIL PROTECTED]> wrote:
> On Oct 29, 2006, at 12:01 PM, William Stein wrote:
>> After building, from the interpreter I did this:
>>
>> sage: import sage.modular.modsym.p1list as p
>> sage: p.test_foo(10)
>> 100
>
> Sweet. Well, maybe we should
On Oct 29, 2006, at 12:01 PM, William Stein wrote:
> After building, from the interpreter I did this:
>
> sage: import sage.modular.modsym.p1list as p
> sage: p.test_foo(10)
> 100
Sweet. Well, maybe we should be doing that in a few places then.
Seems very clean and natural.
David
--~--~---
On Sun, 29 Oct 2006 09:08:27 -0700, David Harvey
<[EMAIL PROTECTED]> wrote:
> You CAN export module-level cdef functions from one pyrex module to
> another.
I didn't realize this...
> I added the following to arith.pyx:
>
> ==
> cdef public int my_function(int x):
>
On Tue, 24 Oct 2006 18:28:37 -0500, Greg Ewing
<[EMAIL PROTECTED]> wrote:
> William Stein wrote:
>> I don't think it matters, since the nb_index field is at the
>> very end of the struct that defines the class, so probably it would
>> still work in the older versions.
>
> A binary compiled fo
Hi,
Since everybody is posting their patched version of Pyrex, I'll post
mine:
http://modular.math.washington.edu/tmp/pyrex-20061022.tar.bz2
Mine has full support for the new __index__ method.
It also supports correct cimports across directories (and sets
tp_name correctly in extension modul
On Sun, 22 Oct 2006 04:00:37 -0700, Martin Albrecht
<[EMAIL PROTECTED]> wrote:
>> It turns out that pyrex is run from the top level directory like this:
>>
>>
>> pyrexc -I/Volumes/HOME/s/devel/sage-main2 sage/rings/integer_mod.pyx
>>
>> Thus the source filename is given as sage/rings/integer
On Fri, 20 Oct 2006 02:16:30 -0700, Joshua Kantor
<[EMAIL PROTECTED]> wrote:
> The example I send I had modified before sending it and
> apparently in that example the Py_INCREF I had isn't necessary,
> I've attached the original example I had where it is necessary.
> Consider foo vs foo_bar. f
27 matches
Mail list logo
