[Pyublas] All vectors are strided

[Neal Becker]

v
array([[ 0, 1, 2, 3],
[ 4, 5, 6, 7],
[ 8, 9, 10, 11],
[12, 13, 14, 15]])
v[:,:2]
array([[ 0, 1],
[ 4, 5],
[ 8, 9],
[12, 13]])

Sure it's a 2D slice. numpy_vector in ublas is designed to accept any
dimensionality. If we only have strided, these things can't be passed into
PyUblas. Bad.
Andreas

I was not aware that numpy_vector, which is 1-dimensional, was intended to
accept higher-D numpy arrays. What does it mean to map a higher-D numpy array
to a 1-D numpy_vector? Do we really want this?

The custom iterators that were added to numpy_vector will only work for dense
contiguous arrays of stride=1.

I had thought that numpy_vector only accepts 1-d numpy array. In that case,
we don't need a distinction between numpy_strided_vector and numpy_vector.
Both are only dense contiguous arrays with numpy_vector having stride=1 and
numpy_strided_vector having any stride.

[Andreas Klöckner]

Post by Neal Becker

v
array([[ 0, 1, 2, 3],
[ 4, 5, 6, 7],
[ 8, 9, 10, 11],
[12, 13, 14, 15]])
v[:,:2]
array([[ 0, 1],
[ 4, 5],
[ 8, 9],
[12, 13]])

Sure it's a 2D slice. numpy_vector in ublas is designed to accept any
dimensionality. If we only have strided, these things can't be passed
into PyUblas. Bad.
Andreas

I was not aware that numpy_vector, which is 1-dimensional, was intended to
accept higher-D numpy arrays. What does it mean to map a higher-D numpy
array to a 1-D numpy_vector?

So far, it means that you get access to a linearized representation of numpy's
memory layout that is not guaranteed to preserve order. (e.g. in the case of
negative strides)

I admit that that's pretty weak.

Post by Neal Becker
Do we really want this?

I'm beginning to feel that it might be a good idea to distinguish between
vector (strictly 1D), strided_vector (1D, with strides), matrix (2D), and
ndarray (any dimensionality).

Post by Neal Becker
The custom iterators that were added to numpy_vector will only work for
dense contiguous arrays of stride=1.

As will the pointers that are currently in there.

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/20081116/8e738ac5/attachment.pgp>

[Neal Becker]

Post by Andreas Klöckner

Post by Neal Becker

v
array([[ 0, 1, 2, 3],
[ 4, 5, 6, 7],
[ 8, 9, 10, 11],
[12, 13, 14, 15]])
v[:,:2]
array([[ 0, 1],
[ 4, 5],
[ 8, 9],
[12, 13]])

Sure it's a 2D slice. numpy_vector in ublas is designed to accept any
dimensionality. If we only have strided, these things can't be passed
into PyUblas. Bad.
Andreas

I was not aware that numpy_vector, which is 1-dimensional, was intended
to accept higher-D numpy arrays. What does it mean to map a higher-D
numpy array to a 1-D numpy_vector?

So far, it means that you get access to a linearized representation of
numpy's memory layout that is not guaranteed to preserve order. (e.g. in
the case of negative strides)
I admit that that's pretty weak.

Post by Neal Becker
Do we really want this?

I'm beginning to feel that it might be a good idea to distinguish between
vector (strictly 1D), strided_vector (1D, with strides), matrix (2D), and
ndarray (any dimensionality).

Post by Neal Becker
The custom iterators that were added to numpy_vector will only work for
dense contiguous arrays of stride=1.

As will the pointers that are currently in there.

I propose that numpy_vector would only support conversion from 1d array. If
that were true, the only need for strided_vector is for speed. But, the tests
I did on at least one platform/compiler show little difference in speed when
custom iterators are used.

So, there is no need to distinguish strided vector/non-strided vector.