Re: [Numpy-discussion] Issue Tracking

2012-02-13 Thread jason-sage
On 2/13/12 2:56 PM, Matthew Brett wrote:
 I have the impression that the Cython / SAGE team are happy with their
 Jenkins configuration.

I'm not aware of a Jenkins buildbot system for Sage, though I think 
Cython uses such a system: https://sage.math.washington.edu:8091/hudson/

We do have a number of systems we build and test Sage on, though I don't 
think we have continuous integration yet.  I've CCd Jeroen Demeyer, who 
is the current release manager for Sage.  Jeroen, do we have an 
automatic buildbot system for Sage?

Thanks,

Jason

--
Jason Grout
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] Numpy performance testing

2011-12-29 Thread jason-sage
On 12/29/11 10:37 PM, Jaidev Deshpande wrote:
 Hi!

 Along with test coverage, have any of you considered any systematic
 monitoring of NumPy performance?

 I'm mildly obsessed with performance and benchmarking of NumPy. I used
 to use a lot of MATLAB until a year back and I tend to compare Python
 performance with it all the time. I generally don't feel happy until
 I'm convinced that I've extracted the last bit of speed out of my
 Python code.

 I think the generalization of this idea is more or less equivalent to
 performance benchmarking. Of course, I know there's a lot more than
 'MATLAB vs Python' to it. I'd be more than happy to be involved. GSoC
 or otherwise.

 Where do I start?

We've recently had a discussion about more intelligent timeit commands 
and timing objects in Python/Sage.  People here might find the 
discussion interesting, and it might also be interesting to collaborate 
on code.  The basic idea was a much smarter timeit command that uses 
more intelligent statistics and presents a much more comprehensive look 
at the timing information.

Here is the discussion: 
https://groups.google.com/forum/#!topic/sage-devel/8lq3twm9Olc

Here is our ticket tracking the issue: 
http://trac.sagemath.org/sage_trac/ticket/12168

Here are some examples of the analysis: http://sagenb.org/home/pub/3857/

I've CCd the sage-devel list as well, which is where our discussion 
happened.

Thanks,

Jason


___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] Reduced row echelon form

2008-11-18 Thread jason-sage
Anne Archibald wrote:
 2008/11/18 Robert Young [EMAIL PROTECTED]:

   
 Is there a method in NumPy that reduces a matrix to it's reduced row echelon
 form? I'm brand new to both NumPy and linear algebra, and I'm not quite sure
 where to look.
 

 Unfortunately, reduced row-echelon form doesn't really work when using
 approximate values: any construction of the reduced row-echelon form
 forces you many times to ask is this number exactly zero or just very
 small?; if it's zero you do one thing, but if it's very small you do
 something totally different - usually divide by it. With
 floating-point numbers, every calculation is approximate, and such a
 method will blow up completely. If you really need reduced row echelon
 form, you have to start with exact numbers and use a package that does
 exact computations (I think SymPy might be a place to start).
   

I also recommend Sage here (http://www.sagemath.org).  For example, here 
is a session in which we calculate the reduced echelon form of a matrix 
over the rationals (QQ):

sage: a=matrix(QQ,[[1,2,3],[4,5,6],[7,8,9]])
sage: a.echelon_form()
[ 1  0 -1]
[ 0  1  2]
[ 0  0  0]

Sage has quite a bit of advanced functionality for exact linear 
algebra.  (It also uses numpy as a backend to provide some nice 
functionality for approximate linear algebra).  Here is a short tutorial 
on constructions in linear algebra:  
http://sagemath.org/doc/const/node28.html

Jason

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] (Late) summary of PEP-225 discussion at Scipy

2008-11-04 Thread jason-sage
Fernando Perez wrote:
 Hi everyone,

 thanks for all the feedback.  Last call on this one.  If nobody
 objects to the language that's written here:

 https://cirl.berkeley.edu/fperez/static/numpy-pep225/
   


one small typo: in the Why just go one step? section, you have the phrase:

and it is thus wortwhile solving the general problem

wortwhile should be worthwhile.

I've posted a message about this to sage-devel, as they are likely 
interested in this topic as well.

Thanks,

Jason

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


[Numpy-discussion] numpy.complex* functions do not call the __complex__ method

2008-09-25 Thread jason-sage
In creating an array of type numpy.complex128, I'm having problems 
passing in Sage types that should be considered complex numbers since 
they implement the standard __complex__ method.  However, numpy doesn't 
recognize that.  Here's a minimal example:

In [1]: class MyNum:
   ...: def __complex__(self):
   ...: return complex(1,3)
   ...:
   ...:

In [2]: import numpy

In [3]: a=MyNum()

In [4]: complex(a)
Out[4]: (1+3j)

In [5]: numpy.complex128(a)
---
type 'exceptions.AttributeError'Traceback (most recent call last)

/home/jason/download/numpy/numpy-1.1.0/src/numpy/ipython console in 
module()

type 'exceptions.AttributeError': MyNum instance has no attribute 
'__float__'



This is with numpy 1.1.  Is this a bug, or is this by design?

Thanks,

Jason

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] numpy.complex* functions do not call the __complex__ method

2008-09-25 Thread jason-sage
Neal Becker wrote:
 [EMAIL PROTECTED] wrote:

   
 In creating an array of type numpy.complex128, I'm having problems
 passing in Sage types that should be considered complex numbers since
 they implement the standard __complex__ method.  However, numpy doesn't
 recognize that.  Here's a minimal example:

 

 I had tried to add my own complex_int class (using c++ code).  Although 
 partly successful, I was not able to get x.real to work.  The reason is that 
 PyArray_ISCOMPLEX is used in various places, and this is a hard-coded macro.  
 There is no way to extend numpy's complex behavior to support user added 
 types.  I wish there was.
   

Is there any possibility of redefining the macro to first call the 
Python function that converts to a python complex?  (I don't know much 
about the python C API, just throwing an idea out).  My example works if 
I do:

numpy.complex128(complex(my_complex_number)),

 but not if I do

numpy.complex128(my_complex_number).

Can we make the call to python's complex (or maybe numpy's copy of it) 
automatic?

Thanks,

Jason

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] PyArray_SETITEM macro ends in semicolon

2008-09-25 Thread jason-sage
Dag Sverre Seljebotn wrote:
 [EMAIL PROTECTED] wrote:
   
 I'm working on getting the Sage matrices for real/complex doubles to use 
 numpy as a backend.  In this, I'm using the PyArray_SETITEM macro from 
 within Cython.  However, Cython wraps the macro in a function call to 
 convert the output to a Python value:

   __pyx_1 = PyInt_FromLong(PyArray_SETITEM(__pyx_v_self-_matrix_numpy, 
 PyArray_GETPTR2(__pyx_v_self-_matrix_numpy, __pyx_v_i, __pyx_v_j), 
 __pyx_v_value));

 However, after preprocessing, because of the semicolon at the end of the 
 SETITEM macro, we get:


 PyInt_FromLong(((PyArrayObject 
 *)(__pyx_v_self-_matrix_numpy))-descr-f-setitem((PyObject 
 *)(__pyx_v_value), (char *)(((void *)PyArrayObject 
 *)(__pyx_v_self-_matrix_numpy))-data) + (__pyx_v_i)*(((PyArrayObject 
 *)(__pyx_v_self-_matrix_numpy))-strides)[0] + 
 (__pyx_v_j)*(((PyArrayObject 
 *)(__pyx_v_self-_matrix_numpy))-strides)[1]))), (PyArrayObject 
 *)(__pyx_v_self-_matrix_numpy)););

 Note that at the end, we have a ););.  The file refuses to compile.  
 Presumably, since SETITEM returns a value, wrapping the return value in 
 a function call seems to be a reasonable thing to do.  Would there be a 
 problem in eliminating the semicolon and instead wrapping the entire 
 function body in parenthesis?

 I noticed that GETITEM also ended in a semicolon, though I didn't have 
 the same problem as above since Cython didn't automatically wrap it in a 
 function call (I'm not even sure if it returns something).

 On a side note, is the above the best way (i.e., fastest way given an 
 arbitrary numpy array) to set/get
 an element?
   
 

 If I get to where I want to be with Cython/NumPy integration, there 
 definitely shouldn't be a need to call PyArray_SETITEM from Cython.

 As you already use Cython, and if you know that your array is 
 real/complex doubles (as indicated by your post), and also know that you 
 have two dimensions (as indicated by your code), then there are 
 definitely faster methods. Have you looked at the Cython numpy array 
 support, as explained in

 http://wiki.cython.org/tutorials/numpy

 ? (This was mentored by Robert Bradshaw of Sage too). Your usecase looks 
 like a place where it can be used. I am actively developing this, so if 
 you wish you can send me proposals for changes to the Cython NumPy 
 support which fixes whatever issues you have with it. (Support for 
 access to complex numbers is an obvious one and that is worked on now.)

   

Yes, I'm excited about this.  In fact, I held off making the transition 
to numpy for a while thinking that the buffer interface would be in 
Sage's Cython any day.  However, I realized that the biggest thing this 
would affect would be the getter and setter function for an array entry 
(most things are just offloaded to numpy/scipy functions), so I decided 
to make a push for it and convert the double and complex double matrices 
over to numpy arrays anyway.  I'm really looking forward to seeing the 
cython buffer access, though.  Thanks for all your work; I've been 
lurking on the mailing list archives and Cython website to track the 
progress on occasion during the summer.


 (As an aside, the int returned from PyArray_SETITEM is likely an error 
 return value (though I'm not 100% sure). Converting it to a Python long 
 is really inefficient, type the variable that is assigned to as an int. 
 But that really belongs on the Cython list.)
   

That's a really good point.  Thanks.  It is an error value; I should 
type it to prevent it from being converted to a python long.

Thanks,

Jason


___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


[Numpy-discussion] PyArray_SETITEM macro ends in semicolon

2008-09-24 Thread jason-sage
I'm working on getting the Sage matrices for real/complex doubles to use 
numpy as a backend.  In this, I'm using the PyArray_SETITEM macro from 
within Cython.  However, Cython wraps the macro in a function call to 
convert the output to a Python value:

  __pyx_1 = PyInt_FromLong(PyArray_SETITEM(__pyx_v_self-_matrix_numpy, 
PyArray_GETPTR2(__pyx_v_self-_matrix_numpy, __pyx_v_i, __pyx_v_j), 
__pyx_v_value));

However, after preprocessing, because of the semicolon at the end of the 
SETITEM macro, we get:


PyInt_FromLong(((PyArrayObject 
*)(__pyx_v_self-_matrix_numpy))-descr-f-setitem((PyObject 
*)(__pyx_v_value), (char *)(((void *)PyArrayObject 
*)(__pyx_v_self-_matrix_numpy))-data) + (__pyx_v_i)*(((PyArrayObject 
*)(__pyx_v_self-_matrix_numpy))-strides)[0] + 
(__pyx_v_j)*(((PyArrayObject 
*)(__pyx_v_self-_matrix_numpy))-strides)[1]))), (PyArrayObject 
*)(__pyx_v_self-_matrix_numpy)););

Note that at the end, we have a ););.  The file refuses to compile.  
Presumably, since SETITEM returns a value, wrapping the return value in 
a function call seems to be a reasonable thing to do.  Would there be a 
problem in eliminating the semicolon and instead wrapping the entire 
function body in parenthesis?

I noticed that GETITEM also ended in a semicolon, though I didn't have 
the same problem as above since Cython didn't automatically wrap it in a 
function call (I'm not even sure if it returns something).

On a side note, is the above the best way (i.e., fastest way given an 
arbitrary numpy array) to set/get
an element?

Thanks,

Jason

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion