[Pyublas] numpy_vector vs ublas vector

[Christophe Koudella]

Hi,

thanks for your reply. v. helpful. You can compile the package with legacy
boost 1.34.1 and
an older version of gcc, although we had to comment out a conversion
operation for the sparse
container - we are not sure why, but are proceeding incrementally.

One thing that is confusing me is the deal with numpy_vector vs the native
ublas vector.
It seems to be possible, as your examples show, to write and expose C++ code
that will
work both with numpy_vector or ublas vector signatures. How does that work?
It seems clear
that for numpy_vector signatures you have implemented handle semantics. On
the other
hand what happens for ublas vector signed functions? When calling from
python, are numpy
arrays converted on the fly into into numpy_vector arrays, and are then
sliced when passed
into the function and then copied by value before going into C++?

May I ask you how you envisage pyublas to work in a large scale system?
Imagine you need
to write some complicated and deep C++ code? Would you envisage writing that
entirely in
terms of numpy_vectors and other pyublas arrays? Or could you just handle
the python interface
(at in and output) with pyublas containers and then rely on native ublas
containers within the
C++ code? If the former, then what is the dependency of pyublas on ublas?
For instance, could
we ever be in a situation in which a future boost release would just break
pyublas?

These are important questions when wanting to use this stuff in a multi-user
"multi-year" hybrid
system.

Also, I apologize if my question are ill-formulated. I haven't understood
everything from the doc, and
so far have spent limited time in the source code.

Thanks & best wishes,
Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tiker.net/pipermail/pyublas/attachments/20091010/e2b53958/attachment.htm>

[Andreas Klöckner]

Post by Christophe Koudella
Hi,
One thing that is confusing me is the deal with numpy_vector vs the native
ublas vector.
It seems to be possible, as your examples show, to write and expose C++
code that will
work both with numpy_vector or ublas vector signatures. How does that work?

Make a template, and cast the function to the right signature when exposing
it. You may also expose many functions onto the same name, which effectively
gives you function overloading.

Post by Christophe Koudella
It seems clear
that for numpy_vector signatures you have implemented handle semantics. On
the other
hand what happens for ublas vector signed functions? When calling from
python, are numpy
arrays converted on the fly into into numpy_vector arrays, and are then
sliced when passed
into the function and then copied by value before going into C++?

Yes, ublas vectors do deep copies.

Post by Christophe Koudella
May I ask you how you envisage pyublas to work in a large scale system?
Imagine you need
to write some complicated and deep C++ code? Would you envisage writing
that entirely in
terms of numpy_vectors and other pyublas arrays? Or could you just handle
the python interface
(at in and output) with pyublas containers and then rely on native ublas
containers within the
C++ code?

It depends. If you cross the language barrier often with large data, you may
want to keep state in pyublas vectors. If a deep copy is a negligible expense,
then staying with ublas's native types is likely a better idea. Perhaps the
best choice: Write your code as templates that are independent of the concrete
vector type, try both, and then decide based on benchmark results.

Post by Christophe Koudella
If the former, then what is the dependency of pyublas on ublas?
For instance, could
we ever be in a situation in which a future boost release would just break
pyublas?

Break as in 'make impossible': not likely at all.
Break as in 'introduce minor annoyance that needs to be patched': sure, could
happen. If upstream Boost makes incompatible changes, there's little that can
be done in PyUblas. Once the issue is known, we can ifdef around it, of
course.

Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.tiker.net/pipermail/pyublas/attachments/20091010/33848ce5/attachment.pgp>