[Numpy-discussion] Template system
Hi All, I'm thinking of adding the template system I pulled out of Django to Numpy to use in place of the current code generator. Its advantages are documentation, flexibility, and maintainance. The code totals about 470 KB, comes with a BSD license, and is compatible with Python = 2.3. I want to bring this up on the list because I'm sure there will be objections along the lines of why do we need that? So I want to see how strenuous the objections are. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Template system
Charles R Harris wrote: Hi All, I'm thinking of adding the template system I pulled out of Django to Numpy to use in place of the current code generator. Its advantages are documentation, flexibility, and maintainance. The code totals about 470 KB, comes with a BSD license, and is compatible with Python = 2.3. I want to bring this up on the list because I'm sure there will be objections along the lines of why do we need that? So I want to see how strenuous the objections are. It's too big. If you want a better template system than the current one, there are a few which are contained in a single file. That would be fine to include, but I object strongly to incorporating Jinja. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] example of ufunc c-code?
Neal Becker wrote:
Where can I find a (hopefully simple) example of c-code for a ufunc?
Wow, that was easy. Maybe you can use this as an example:
#include boost/python/module.hpp
#include boost/python/class.hpp
#include boost/python/init.hpp
#include boost/python/def.hpp
#include boost/range.hpp
//#include boost/python/make_constructor.hpp
#include numpy_iter.hpp
#include numpy/ufuncobject.h
#include complex
using namespace boost::python;
typedef std::complexdouble complex_t;
inline double mag_sqr (double x) { return x * x; }
inline double mag_sqr (complex_t x) { return real(x)*real(x)+imag(x)*imag(x); }
templatetypename in_t, typename out_t
static void mag_sqr_loop1d (char** args, npy_intp* dimensions, npy_intp* steps, void* data) {
in_t* in = (in_t*)(args[0]);
out_t* out = (out_t*)(args[1]);
npy_intp size = dimensions[0];
npy_intp i_stride = steps[0]/sizeof(in_t);
npy_intp o_stride = steps[1]/sizeof(out_t);
for (int i = 0; i size; ++i, in += i_stride, out += o_stride)
*out = mag_sqr (*in);
}
static object register_magsqr() {
PyUFuncGenericFunction funcs[] = {mag_sqr_loop1ddouble,double,
mag_sqr_loop1dcomplex_t,double
};
char types[] = {NPY_DOUBLE, NPY_DOUBLE, NPY_CDOUBLE, NPY_DOUBLE};
return object (handle (PyUFunc_FromFuncAndData (funcs, NULL, types, 2, 1, 1, PyUFunc_None, magsqr, magsqr, 0)));
}
BOOST_PYTHON_MODULE (mag_sqr) {
import_array();
import_ufunc();
object mag_sqr_obj = register_magsqr();
scope().attr (mag_sqr) = mag_sqr_obj;
}
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Template system
On Jan 11, 2008 2:58 PM, Robert Kern [EMAIL PROTECTED] wrote: Charles R Harris wrote: Hi All, I'm thinking of adding the template system I pulled out of Django to Numpy to use in place of the current code generator. Its advantages are documentation, flexibility, and maintainance. The code totals about 470 KB, comes with a BSD license, and is compatible with Python = 2.3. I want to bring this up on the list because I'm sure there will be objections along the lines of why do we need that? So I want to see how strenuous the objections are. It's too big. If you want a better template system than the current one, there are a few which are contained in a single file. That would be fine to include, but I object strongly to incorporating Jinja. Ummm, harsh. I'm certainly open to suggestions. I took a closer look at the django system and reduced it to 308K, 70K zipped. There was a lot of space taken up by the .svn directories inherited from django and *.pyc files. I could probably knock another 50K off by removing some functionality we don't really need: html, http, dates, time, and maybe template inheritance. Just for comparison, here are some things that are in a fresh checkout of numpy, including the .svn files Numpy 23 MB f2py 5.4 MB doc/swig 1.5 MB code_generators 192K So adding the template subsystem would increase the repository size by about 1.4%. Do you have any objections in addition to the size? Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] wrap Python/numpy to C/C++. mingw. elmer.
Hi Sorry for irrelevant subject. I found elmer when I was googling for something to wrap my python/numpy code to C/C++ automatically because I want a dll for some application and I know nothing about python Api (shame on me). Does anybody successfully compiled elmer on windows with mingw? Or is it anything better than elmer? (mingwISHER!/windowsISHER!) I will appreciate any suggestion. Regards Mani ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Template system
Charles R Harris wrote: On Jan 11, 2008 2:58 PM, Robert Kern [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Charles R Harris wrote: Hi All, I'm thinking of adding the template system I pulled out of Django to Numpy to use in place of the current code generator. Its advantages are documentation, flexibility, and maintainance. The code totals about 470 KB, comes with a BSD license, and is compatible with Python = 2.3. I want to bring this up on the list because I'm sure there will be objections along the lines of why do we need that? So I want to see how strenuous the objections are. It's too big. If you want a better template system than the current one, there are a few which are contained in a single file. That would be fine to include, but I object strongly to incorporating Jinja. Ummm, harsh. I'm certainly open to suggestions. I took a closer look at the django system and reduced it to 308K, 70K zipped. There was a lot of space taken up by the .svn directories inherited from django and *.pyc files. I could probably knock another 50K off by removing some functionality we don't really need: html, http, dates, time, and maybe template inheritance. Just for comparison, here are some things that are in a fresh checkout of numpy, including the .svn files Numpy 23 MB f2py 5.4 MB doc/swig 1.5 MB code_generators 192K So adding the template subsystem would increase the repository size by about 1.4%. Do you have any objections in addition to the size? Yes. I'm not convinced that we need anything better than we have now. Show me how using Jinja templates makes the current code better. Check the one-file templating modules (like YAPTU[1] or Cog[2]) out there to see if those are sufficient. Jinja and its kin (Mako, Cheetah, etc.) are intended for a very different use case, and their design, implementation, and footprint are optimized for that. [1] http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52305 [2] http://nedbatchelder.com/code/cog/ -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] wrap Python/numpy to C/C++. mingw. elmer.
Hey Mani, I've included Rick Ratzel on this since he is the author of elmer and may have more guidance. eric mani sabri wrote: Hi Sorry for irrelevant subject. I found elmer when I was googling for something to wrap my python/numpy code to C/C++ automatically because I want a dll for some application and I know nothing about python Api (shame on me). Does anybody successfully compiled elmer on windows with mingw? Or is it anything better than elmer? (mingwISHER!/windowsISHER!) I will appreciate any suggestion. Regards Mani ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] subclassing matrix
On Jan 11, 2008, Colin J. Williams wrote:
You make a good case that it's good not
to need to ponder what sort of
vector you are dealing with.
My guess is that the answer to your
question is no but I would need to
play with your code to see that. My
feeling is that, at the bottom of
the __new__ module, the returned object
should be an instance of the
Vector class.
It's been a while since I've worked with
numpy and so I'll look at it
and hope that someone gives you a
definitive answer before I sort it out.
Colin W.
Well, let's say that I get rid of that class promotion line. When the
input object to the constructor is a string or a tuple
such as Vector('1 2 3') or Vector([1,2,3]), then the returned object
is always an instance of Vector. However, when the input object is a
numpy.matrix instance, the returned object remains a numpy.matrix
instance! So by doing that little hack, I promote it to Vector.
BUT...
It seems that I have solved only half of my problem here. The other
half rears its ugly head when I perform operations between instances
of numpy.matrix and Vector. The result ends up returning a matrix,
which is bad because it has no knowledge of any custom Vector
attributes. Here's a simple case:
u = Vector('1 2 3') #Vector instance
P = numpy.mat(numpy.eye(3)) #matrix instance
u_new = P*u #matrix instance, not desirable!
u_new_as_Vector = Vector(P*u) #Vector instance
I'd rather not have to remember to re-instantiate the result in client
code. I think I understand why this is happening - the code in
numpy.core.defmatrix.matrix.__mul__ goes like this:
def __mul__(self, other):
if isinstance(other,(N.ndarray, list, tuple)) :
# This promotes 1-D vectors to row vectors
return N.dot(self, asmatrix(other))
if N.isscalar(other) or not hasattr(other, '__rmul__') :
return N.dot(self, other)
return NotImplemented
It passes the first condition: isinstance(other,(N.ndarray)) is true;
and so the return value becomes a matrix.
Bummer.
Do I also need to override a few overloaded methods like __mul__,
__rmul__, etc. to make this work?
Cheers,
-Basilisk96
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Template system
OK, so far I've knocked it down to 35KB by removing stuff I'm not interested in. It is now smaller than Cog, and 7x larger than the file we now use to do the same job. I'm pretty sure I can make it leaner than that. It remains extensible. On Jan 11, 2008 7:02 PM, Robert Kern [EMAIL PROTECTED] wrote: Charles R Harris wrote: On Jan 11, 2008 2:58 PM, Robert Kern [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Charles R Harris wrote: Hi All, I'm thinking of adding the template system I pulled out of Django to Numpy to use in place of the current code generator. Its advantages are documentation, flexibility, and maintainance. The code totals about 470 KB, comes with a BSD license, and is compatible with Python = 2.3. I want to bring this up on the list because I'm sure there will be objections along the lines of why do we need that? So I want to see how strenuous the objections are. It's too big. If you want a better template system than the current one, there are a few which are contained in a single file. That would be fine to include, but I object strongly to incorporating Jinja. Ummm, harsh. I'm certainly open to suggestions. I took a closer look at the django system and reduced it to 308K, 70K zipped. There was a lot of space taken up by the .svn directories inherited from django and *.pyc files. I could probably knock another 50K off by removing some functionality we don't really need: html, http, dates, time, and maybe template inheritance. Just for comparison, here are some things that are in a fresh checkout of numpy, including the .svn files Numpy 23 MB f2py 5.4 MB doc/swig 1.5 MB code_generators 192K So adding the template subsystem would increase the repository size by about 1.4%. Do you have any objections in addition to the size? Yes. I'm not convinced that we need anything better than we have now. Show me how using Jinja templates makes the current code better. Check the one-file templating modules (like YAPTU[1] or Cog[2]) out there to see if those are sufficient. Jinja and its kin (Mako, Cheetah, etc.) are intended for a very different use case, and their design, implementation, and footprint are optimized for that. [1] http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52305 [2] http://nedbatchelder.com/code/cog/ -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] subclassing matrix
On Jan 11, 2008 9:59 PM, Basilisk96 [EMAIL PROTECTED] wrote:
On Jan 11, 2008, Colin J. Williams wrote:
You make a good case that it's good not
to need to ponder what sort of
vector you are dealing with.
My guess is that the answer to your
question is no but I would need to
play with your code to see that. My
feeling is that, at the bottom of
the __new__ module, the returned object
should be an instance of the
Vector class.
It's been a while since I've worked with
numpy and so I'll look at it
and hope that someone gives you a
definitive answer before I sort it out.
Colin W.
Well, let's say that I get rid of that class promotion line. When the
input object to the constructor is a string or a tuple
such as Vector('1 2 3') or Vector([1,2,3]), then the returned object
is always an instance of Vector. However, when the input object is a
numpy.matrix instance, the returned object remains a numpy.matrix
instance! So by doing that little hack, I promote it to Vector.
BUT...
It seems that I have solved only half of my problem here. The other
half rears its ugly head when I perform operations between instances
of numpy.matrix and Vector. The result ends up returning a matrix,
which is bad because it has no knowledge of any custom Vector
attributes. Here's a simple case:
u = Vector('1 2 3') #Vector instance
P = numpy.mat(numpy.eye(3)) #matrix instance
u_new = P*u #matrix instance, not desirable!
u_new_as_Vector = Vector(P*u) #Vector instance
I'd rather not have to remember to re-instantiate the result in client
code. I think I understand why this is happening - the code in
numpy.core.defmatrix.matrix.__mul__ goes like this:
def __mul__(self, other):
if isinstance(other,(N.ndarray, list, tuple)) :
# This promotes 1-D vectors to row vectors
return N.dot(self, asmatrix(other))
if N.isscalar(other) or not hasattr(other, '__rmul__') :
return N.dot(self, other)
return NotImplemented
It passes the first condition: isinstance(other,(N.ndarray)) is true;
and so the return value becomes a matrix.
Bummer.
Do I also need to override a few overloaded methods like __mul__,
__rmul__, etc. to make this work?
I believe that you need to look at __array_finalize__ and __array_priority__
(and there may be one other thing as well, I can't remember; it's late).
Search for __array_finalize__ and that will probably help get you started.
--
. __
. |-\
.
. [EMAIL PROTECTED]
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Template system
Charles R Harris wrote: OK, so far I've knocked it down to 35KB by removing stuff I'm not interested in. It is now smaller than Cog, and 7x larger than the file we now use to do the same job. I'm pretty sure I can make it leaner than that. It remains extensible. One good way to see whereas it is a worthwhile addition would be to give an example of one source file using this new template. cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
