[Numpy-discussion] Anyone have a well-tested SWIG-based C++ STL valarray <=> numpy.array typemap to share?
Thu Sep 6 03:06:35 CDT 2007
2007/9/5, Christopher Barker <Chris.Barker@noaa.gov>:
> Matthieu Brucher wrote:
> > Blitz++ is more or less avandoned. It uses indexes than can be
> > not-portable between 32bits platforms and 64bits ones.
> Oh well -- that seems remarkably short sited, but would I have done
Well, it's too bad the mainteners used int instead of long or somthing like
that, but at the time, 64bits platforms did not exist.
> The Boost.Array is a fixed-size array, determined at compile-time,
> Ah, I had gotten the wrong impression -- I thought it was fixed at
> construction time, not compile time.
According to the doc, it's fixed at compile-time.
> not interesting there, I suppose.
> I agree, I kind of wonder what the point is.
In some case you might want them, but not very often, only to speed up
> Multiarrays are what you're looking for.
> Even if I just want 1-d? though I guess a 1-d multiarray is pretty simple.
> > Besides, it is not needed to build Boost to use them
> I've seen that -- it does look like all we'd need is the header.
> So, can one:
> - create a Multiarray from an existing data pointer?
> - get the data pointer for an existing Multiarray?
> I think that's what I'd need to make the numpy array <-> Multiarray
> transition without any copying.
I have the same problem at my job, but I don't think SWIG will suit me,
although I use it for simpler wrappers.
Like Philip said, there are some trials, I hope someone (or I) will come up
with a Python array <-> C++ array wrapper without copy. What you really need
is that the multiarray must be able to use the data pointer, it's a special
policy, and then you must be able to register a shared pointer to Python,
that is if the original container use shared pointer. If the last part is
not possible, you will need to create first a Python array and then make a
view of it in C++, even for a result array.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Numpy-discussion