Travis E. Oliphant wrote:
>
>> nd to copy hundres of MB around unnecessarily.
>>
>> I think it is a real shame that boost currently doesn't properly support
>> numpy out of the box, although numpy has long obsoleted both numarray and
>> Numeric (which is both buggy and completely unsupported). Al
Travis E. Oliphant wrote:
>
>> nd to copy hundres of MB around unnecessarily.
>>
>> I think it is a real shame that boost currently doesn't properly support
>> numpy out of the box, although numpy has long obsoleted both numarray and
>> Numeric (which is both buggy and completely unsupported). Al
>
> less than what? std:valarray, etc. all help with this.
I do not agree with this statement. A correct memory managed array would
increment and decrement a reference counter somewhere.
Yes, it sure would be nice to build it on an existing code base, and
> boost::multiarray seems to fit.
T
David Cournapeau wrote:
> Maybe I am naive, but I think a worthy goal would be a minimal C++
> library which wraps ndarray, without thinking about SWIG, boost and co
> first.
That's exactly what I had in mind. If you have something that works well
with ndarray -- then SWIG et al. can work with
Christopher Barker <[EMAIL PROTECTED]> writes:
> Alexander Schmolck wrote:
>> I just saw a closely related question posted one
>> week ago here (albeit mostly from a swig context).
>
> SWIG, Boost, whatever, the issues are similar. I guess what I'd love to
> find is an array implementation that
Christopher Barker wrote:
> Alexander Schmolck wrote:
>> I just saw a closely related question posted one
>> week ago here (albeit mostly from a swig context).
>
> SWIG, Boost, whatever, the issues are similar. I guess what I'd love to
> find is an array implementation that plays well with modern
Alexander Schmolck wrote:
> I just saw a closely related question posted one
> week ago here (albeit mostly from a swig context).
SWIG, Boost, whatever, the issues are similar. I guess what I'd love to
find is an array implementation that plays well with modern C++, and
also numpy.
> The cod
> nd to copy hundres of MB around unnecessarily.
>
> I think it is a real shame that boost currently doesn't properly support numpy
> out of the box, although numpy has long obsoleted both numarray and Numeric
> (which is both buggy and completely unsupported). All the more so since
> writing mult
Philip Austin <[EMAIL PROTECTED]> writes:
> Alexander Schmolck writes:
>
> > So my question is: might it make sense to use (a slightly wrapped)
> > numpy.ndarray, and if so is some code already floating around for that (on
> > first glance it seems like there's a bit of support for the obsolete
Alexander Schmolck writes:
> So my question is: might it make sense to use (a slightly wrapped)
> numpy.ndarray, and if so is some code already floating around for that (on
> first glance it seems like there's a bit of support for the obsolete Numeric
> package in boost, but none for the newer
Hi,
I've sent pretty much the same email to c++sig, but I thought I'd also try my
luck here, especially since I just saw a closely related question posted one
week ago here (albeit mostly from a swig context).
I'm working working on an existing scientific code base that's mostly C++ and
I'm curre
11 matches
Mail list logo
