Re: STL wrapper for PyArrayObject
On Friday 05 January 2001 06:24, pfenn@mmm.com wrote:
Be sure to look at the CXX on sourceforge.
Ja! This is a sweet combination. The Joy of Swig is we can declare some parameters as basic types, but others as raw PyObjects. Then we can have our way with these. And using CXX, we wrap these objects in high-level C++ methods. Not the low-level fragile C. The effect compares favorably to ATL for VC++ and ActiveX. But there's just one little question here. (Hence the buckshot of list servers.) If we pass a multiarray into a function expecting a PyArrayObject, how then do we add new elements to it? I tried things like 'push_back()' and 'setItem()', but they either did not exist or did not extend the array. Am I going to have to generate a new array and copy the old one into the new? --Phlip -- Phlip ======= http://users.deltanet.com/~tegan/home.html ======= ------------------------------------------------------------ --== Sent via Deja.com ==-- http://www.deja.com/
Phlip TheProgrammer wrote:
And using CXX, we wrap these objects in high-level C++ methods. Not the low-level fragile C. The effect compares favorably to ATL for VC++ and ActiveX.
If we pass a multiarray into a function expecting a PyArrayObject, how then do we add new elements to it? I tried things like 'push_back()' and 'setItem()', but they either did not exist or did not extend the array.
Am I going to have to generate a new array and copy the old one into the new?
I waited a little while before answering this, because there are certainly people more qualified to do so that me. I am only on the NumPy list, so it may have been answered on a different list. The short answer is yes, you will have to generate a new a array and copy the old one into the new. MultiArray objects were created to provide efficient storage of lots of numbers (among other things). Because of this requirement, the numbers are stored as a large single array, and so they cannot be re-sized without re-creating that array. You may be able to change just the data array itself (and a few properties), rather than creating a new structure entirely, but it probably wouldn't be worth it. By the way, I'd like to hear how this all works out. Being able to use NumPy Arrays in extensions more easily would be great! -Chris -- Christopher Barker, Ph.D. cbarker@jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------
Proclaimed Chris Barker from the mountaintops:
The irritation is, without a CXX list server, I'm having to molest the off-topic fora where Dubois et al are reputed to hang out.
Here's the state of the system: static void copyData ( Py::Array & ma, vector<vector< string > > & database, int maxFields ) { #if 1 Py::Sequence shape (Py::Int (2)); // <-- pow shape[0] = Py::Int (int (database.size())); shape[1] = Py::Int (maxFields); PyArray_Reshape ((PyArrayObject*)ma.ptr(), shape.ptr()); #else int zone[] = { database.size(), maxFields }; Py::Object mo ((PyObject*)PyArray_FromDims (2, zone, PyArray_OBJECT) ); ma = mo; assert (ma.dimension(1) == database.size()); assert (ma.dimension(2) == maxFields); for (int idxRow (0); idxRow < maxRows; ++idxRow) { Py::Array row (ma[idxRow]); for (int idxCol (0); idxCol < maxFields; ++idxCol) { string const & str (database[idxRow][idxCol]); Py::String pyStr (str.c_str()); Py::Object obj (pyStr); row [idxCol] = obj; // <-- pow } } #endif } Both versions crash on the line marked "pow". The top one crashes when I think I'm trying to do the equivalent of the Python array = (2.4) The bottom one crashes after creating a new array, right when I try to copy in an element. The Pythonic equivalent of matrixi [row][col] = "8" Everyone remember I'm not trying to presenve the old contents of the array - just return from the extension a new array full of stuff.
By the way, I'd like to hear how this all works out. Being able to use NumPy Arrays in extensions more easily would be great!
Our Chief Drive-by Architect has ordered me to use them like an in-memory database. >Sigh< --Phlip "...fanatical devotion to the Pope, and cute red uniforms..."
Phlip TheProgrammer wrote:
And using CXX, we wrap these objects in high-level C++ methods. Not the low-level fragile C. The effect compares favorably to ATL for VC++ and ActiveX.
If we pass a multiarray into a function expecting a PyArrayObject, how then do we add new elements to it? I tried things like 'push_back()' and 'setItem()', but they either did not exist or did not extend the array.
Am I going to have to generate a new array and copy the old one into the new?
I waited a little while before answering this, because there are certainly people more qualified to do so that me. I am only on the NumPy list, so it may have been answered on a different list. The short answer is yes, you will have to generate a new a array and copy the old one into the new. MultiArray objects were created to provide efficient storage of lots of numbers (among other things). Because of this requirement, the numbers are stored as a large single array, and so they cannot be re-sized without re-creating that array. You may be able to change just the data array itself (and a few properties), rather than creating a new structure entirely, but it probably wouldn't be worth it. By the way, I'd like to hear how this all works out. Being able to use NumPy Arrays in extensions more easily would be great! -Chris -- Christopher Barker, Ph.D. cbarker@jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------
Proclaimed Chris Barker from the mountaintops:
The irritation is, without a CXX list server, I'm having to molest the off-topic fora where Dubois et al are reputed to hang out.
Here's the state of the system: static void copyData ( Py::Array & ma, vector<vector< string > > & database, int maxFields ) { #if 1 Py::Sequence shape (Py::Int (2)); // <-- pow shape[0] = Py::Int (int (database.size())); shape[1] = Py::Int (maxFields); PyArray_Reshape ((PyArrayObject*)ma.ptr(), shape.ptr()); #else int zone[] = { database.size(), maxFields }; Py::Object mo ((PyObject*)PyArray_FromDims (2, zone, PyArray_OBJECT) ); ma = mo; assert (ma.dimension(1) == database.size()); assert (ma.dimension(2) == maxFields); for (int idxRow (0); idxRow < maxRows; ++idxRow) { Py::Array row (ma[idxRow]); for (int idxCol (0); idxCol < maxFields; ++idxCol) { string const & str (database[idxRow][idxCol]); Py::String pyStr (str.c_str()); Py::Object obj (pyStr); row [idxCol] = obj; // <-- pow } } #endif } Both versions crash on the line marked "pow". The top one crashes when I think I'm trying to do the equivalent of the Python array = (2.4) The bottom one crashes after creating a new array, right when I try to copy in an element. The Pythonic equivalent of matrixi [row][col] = "8" Everyone remember I'm not trying to presenve the old contents of the array - just return from the extension a new array full of stuff.
By the way, I'd like to hear how this all works out. Being able to use NumPy Arrays in extensions more easily would be great!
Our Chief Drive-by Architect has ordered me to use them like an in-memory database. >Sigh< --Phlip "...fanatical devotion to the Pope, and cute red uniforms..."
participants (3)
-
Chris Barker -
Phlip -
Phlip TheProgrammer