Charles R Harris wrote: > On Jan 16, 2008 11:30 AM, Neal Becker <[EMAIL PROTECTED]> wrote: > >> Hans Meine wrote: >> >> > Am Montag, 14. Januar 2008 19:59:15 schrieb Neal Becker: >> >> I don't want to use FROM_O here, because I really can only handle >> certain >> >> types. If I used FROM_O, then after calling FROM_O, if the type was >> not >> >> one I could handle, I'd have to call FromAny and convert it. >> > What is the problem with that? Is there any, apart from the code not >> > being as elegant as one might want it to be? >> > >> > AFAICS, it would be nice to have a function that takes a PyObject and a >> > list >> > of supported types and would perform the minimal needed conversion. >> OTOH, >> > if your code is templatized, it is maybe already written in an >> > STL-style way, >> > using iterators? Then, it would be very simple to provide a set of >> > iterators that e.g. promote unsigned short->int such that your >> > algorithm can work on the original data without creating a copy. >> > >> > Note that internally, ufuncs already do what you want. I have not yet >> > found the perfect way for a NumPy/C++ integration (which I am >> > interested in, possibly using boost::python which I have been doing for >> > the last years), but for element-wise operators, it would be very cool >> > to be able to re-use the ufunc mechanism (i.e. only implement the inner >> > loop, not caring about non-contiguous arrays etc.). >> > >> >> I have been making some good progress on numpy/c++ integration. I can >> share >> some examples if there is interest. >> > > I would be interested in that. > > Chuck I placed a little test code and a quick design doc here: https://nbecker.dyndns.org/numpy.ext.tar.bz2
_______________________________________________ Numpy-discussion mailing list [email protected] http://projects.scipy.org/mailman/listinfo/numpy-discussion
