[Numpy-discussion] Anyone have a well-tested SWIG-based C++ STL valarray <=> numpy.array typemap to share?
Wed Sep 5 13:45:57 CDT 2007
Bill Spotz wrote:
> Yes, this resizing memory management issue is the main reason I haven't
> tried to implement it in numpy.i yet.
> <thinking out loud>
> A possibly better solution would be to develop a class that inherits
> from std::valarray<TYPE> but also implements the array interface
> attributes (these attributes would have to be dynamic, in that they
> check the std::valarray attributes when accessed rather than storing
I like that, though it's way over my head to implement.
However, I'm beginning to have my doubts about valarrays. I'm reading:
Josuttis, Nicolai M. 1999. "The C+= Standard Library: A Tutorial and
It's 8 years old now, but he writes:
"The valarray classes were not designed very well. In fact, nobody tried
to determine if the specification worked"
He goes on to suggest that Blitz++ might have more of a future. (though
it looks like he's involved with the Boost project now)
He also points out some major flaws in the text. In reading, I also see
that while valarrays can be used for multidimensional arrays, the
semantics are pretty ugly.
However, he also says: "In principle...you can change their size.
However, changing the size of a valarray is provided only to make a
two-step initialization (creating and setting the size)"
So maybe the memory re-allocation is such an issue.
Does anyone know the status of support for valarrays now?
Is there another alternative? At the moment, all we need is a one-d
fixed size array. There is Boost::array (and MultiArray), but Boost has
always seemed like a big, ugly, hard to build dependency. Can you just
grab the code for some of these small pieces by themselves?
Christopher Barker, Ph.D.
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
More information about the Numpy-discussion