[sage-devel] Re: numpy vs. in-place optimizations

2007-11-02 Thread Robert Bradshaw
On Nov 2, 2007, at 12:22 PM, Carl Witty wrote: > On Nov 2, 11:25 am, Robert Bradshaw <[EMAIL PROTECTED]> > wrote: >> :-(, but I have to concede to your logic. The line to change is 148 >> of coerce.pxi. Setting this value to 0 will turn them completely off. >> Other than numpy, (and the builtin l

[sage-devel] Re: numpy vs. in-place optimizations

2007-11-02 Thread mabshoff
On Nov 2, 8:25 pm, "William Stein" <[EMAIL PROTECTED]> wrote: > On 11/2/07, Carl Witty <[EMAIL PROTECTED]> wrote: > > > > > On Nov 2, 11:25 am, Robert Bradshaw <[EMAIL PROTECTED]> > > wrote: > > > :-(, but I have to concede to your logic. The line to change is 148 > > > of coerce.pxi. Setting th

[sage-devel] Re: numpy vs. in-place optimizations

2007-11-02 Thread William Stein
On 11/2/07, Carl Witty <[EMAIL PROTECTED]> wrote: > On Nov 2, 11:25 am, Robert Bradshaw <[EMAIL PROTECTED]> > wrote: > > :-(, but I have to concede to your logic. The line to change is 148 > > of coerce.pxi. Setting this value to 0 will turn them completely off. > > Other than numpy, (and the buil

[sage-devel] Re: numpy vs. in-place optimizations

2007-11-02 Thread Carl Witty
On Nov 2, 11:25 am, Robert Bradshaw <[EMAIL PROTECTED]> wrote: > :-(, but I have to concede to your logic. The line to change is 148 > of coerce.pxi. Setting this value to 0 will turn them completely off. > Other than numpy, (and the builtin libraries), do we use any other > extension types? If th

[sage-devel] Re: numpy vs. in-place optimizations

2007-11-02 Thread Robert Bradshaw
On Nov 2, 2007, at 10:48 AM, William Stein wrote: > > On 11/2/07, Dan Christensen <[EMAIL PROTECTED]> wrote: >> numpy arrays are extremely flexible, with broadcasting, view >> semantics >> and in-place operations being the most important reason why. For >> example, if x is an array, then x[3:

[sage-devel] Re: numpy vs. in-place optimizations

2007-11-02 Thread William Stein
On 11/2/07, Dan Christensen <[EMAIL PROTECTED]> wrote: > numpy arrays are extremely flexible, with broadcasting, view semantics > and in-place operations being the most important reason why. For > example, if x is an array, then x[3:5] is a view of part of x, and > I can adjust the entries in jus

[sage-devel] Re: numpy vs. in-place optimizations

2007-11-02 Thread Dan Christensen
Robert Bradshaw <[EMAIL PROTECTED]> writes: > This is due to the inplace operator stuff using refcounts to > determine if it's safe to mutate. The simple workaround is to not use > numpy arrays of SAGE objects. Another question is why would one do so > (i.e. what is lacking in the SAGE line

[sage-devel] Re: numpy vs. in-place optimizations

2007-10-31 Thread William Stein
On 10/31/07, Robert Bradshaw <[EMAIL PROTECTED]> wrote: > > So matplotlib depends on Numpy? Yes. > > or uses numerical matrices, > > I thought we used GSL as a back end, but does it often fall back to > Numpy then? We use both numpy and gsl. Numpy is better for certain things. > > it is very

[sage-devel] Re: numpy vs. in-place optimizations

2007-10-31 Thread Robert Bradshaw
On Oct 31, 2007, at 12:22 PM, William Stein wrote: > On 10/31/07, Robert Bradshaw <[EMAIL PROTECTED]> wrote: >>> I can think of lots of "solutions", although I don't know which of >>> them might be worth the effort. >>> >>> 1) a global enable/disable >>> 2) hook into __import__ to notice imports

[sage-devel] Re: numpy vs. in-place optimizations

2007-10-31 Thread William Stein
On 10/31/07, Robert Bradshaw <[EMAIL PROTECTED]> wrote: > > I can think of lots of "solutions", although I don't know which of > > them might be worth the effort. > > > > 1) a global enable/disable > > 2) hook into __import__ to notice imports of numpy, and turn off the > > optimization globally i

[sage-devel] Re: numpy vs. in-place optimizations

2007-10-31 Thread Robert Bradshaw
On Oct 30, 2007, at 6:29 PM, Carl Witty wrote: > On Oct 30, 1:48 pm, Robert Bradshaw <[EMAIL PROTECTED]> > wrote: >> This is due to the inplace operator stuff using refcounts to >> determine if it's safe to mutate. The simple workaround is to not use >> numpy arrays of SAGE objects. Another quest

[sage-devel] Re: numpy vs. in-place optimizations

2007-10-30 Thread Carl Witty
On Oct 30, 6:29 pm, Carl Witty <[EMAIL PROTECTED]> wrote: > On Oct 30, 1:48 pm, Robert Bradshaw <[EMAIL PROTECTED]> > wrote: > > > This is due to the inplace operator stuff using refcounts to > > determine if it's safe to mutate. The simple workaround is to not use > > numpy arrays of SAGE objects

[sage-devel] Re: numpy vs. in-place optimizations

2007-10-30 Thread Carl Witty
On Oct 30, 1:48 pm, Robert Bradshaw <[EMAIL PROTECTED]> wrote: > This is due to the inplace operator stuff using refcounts to > determine if it's safe to mutate. The simple workaround is to not use > numpy arrays of SAGE objects. Another question is why would one do so > (i.e. what is lacking in t

[sage-devel] Re: numpy vs. in-place optimizations

2007-10-30 Thread Robert Bradshaw
On Oct 30, 2007, at 1:11 PM, Carl Witty wrote: > On Tue, 2007-10-30 at 11:24 -0700, Robert Bradshaw wrote: >> I don't see this one--could you send me a link? >> >> I didn't know we used SAGE objects in any numpy classes. > > Numpy provides a type of matrices of arbitrary Python objects. > > http: