norm_2 problem fixed
by Neal Becker

Problem was caused by the iterators that I had introduced! It seems they need
to derive from ublas::dense_random_access_iterator_tag, not from
boost::random_access_traversal tag.
At least with this change, it does compile:
diff --git a/src/cpp/pyublas/numpy.hpp b/src/cpp/pyublas/numpy.hpp
index 1699e6f..3f87012 100644
--- a/src/cpp/pyublas/numpy.hpp
+++ b/src/cpp/pyublas/numpy.hpp
@@ -745,11 +745,13 @@ namespace pyublas
class numpy_vec_iterator :
public boost::iterator_facade<numpy_vec_iterator, T,
- boost::random_access_traversal_tag>
+ // boost::random_access_traversal_tag>
+ boost::numeric::ublas::dense_random_access_iterator_tag>
{
public:
typedef boost::iterator_facade<numpy_vec_iterator, T,
- boost::random_access_traversal_tag> self_t;
+ // boost::random_access_traversal_tag> self_t;
+ boost::numeric::ublas::dense_random_access_iterator_tag> self_t;
typedef typename self_t::difference_type difference_type;
@@ -789,12 +791,14 @@ namespace pyublas
class numpy_vec_const_iterator
: public boost::iterator_facade<
numpy_vec_const_iterator, const T,
- boost::random_access_traversal_tag >
+ // boost::random_access_traversal_tag >
+ boost::numeric::ublas::dense_random_access_iterator_tag>
{
public:
typedef boost::iterator_facade<
numpy_vec_const_iterator, const T,
- boost::random_access_traversal_tag> self_t;
+ // boost::random_access_traversal_tag> self_t;
+ boost::numeric::ublas::dense_random_access_iterator_tag> self_t;
typedef typename self_t::difference_type difference_type;
@@ -955,13 +959,15 @@ namespace pyublas
class numpy_strided_vec_iterator :
public boost::iterator_facade<
numpy_strided_vec_iterator, T,
- boost::random_access_traversal_tag >
+ // boost::random_access_traversal_tag >
+ boost::numeric::ublas::dense_random_access_iterator_tag> // Is this correct?
{
public:
typedef boost::iterator_facade<
numpy_strided_vec_iterator,
T,
- boost::random_access_traversal_tag
+ // boost::random_access_traversal_tag
+ boost::numeric::ublas::dense_random_access_iterator_tag // Is this
correct?
>
self_t;
@@ -1005,12 +1011,14 @@ namespace pyublas
class numpy_strided_vec_const_iterator :
public boost::iterator_facade<
numpy_strided_vec_const_iterator, const T,
- boost::random_access_traversal_tag >
+ // boost::random_access_traversal_tag >
+ boost::numeric::ublas::dense_random_access_iterator_tag> // ?
{
public:
typedef boost::iterator_facade<
numpy_strided_vec_const_iterator, const T,
- boost::random_access_traversal_tag > self_t;
+ // boost::random_access_traversal_tag > self_t;
+ boost::numeric::ublas::dense_random_access_iterator_tag> self_t; //?
typedef typename self_t::difference_type difference_type;
10 years, 6 months

I see
by Neal Becker

It seems to want me to use as_ublas:
template<typename out_t, typename in_t>
inline out_t norm_2 (in_t const& in) {
return ublas::norm_2 (in.as_ublas());
}
That works (although I don't understand why)
10 years, 6 months

This compiles fine
by Neal Becker

#include <boost/numeric/ublas/vector.hpp>
#include <boost/numeric/ublas/vector_proxy.hpp>
namespace ublas=boost::numeric::ublas;
template<typename out_t, typename in_t>
inline out_t norm_2 (in_t const& in) {
return ublas::norm_2 (in);
}
int main () {
ublas::vector<double> x (10);
double y = norm_2 (x);
double z = norm_2 (project (x, ublas::slice (0, 3, 2)));
}
So, problem is not with calling norm_2 of a vector_slice.
10 years, 6 months

Calling norm_2 on numpy_strided_vector
by Neal Becker

template<typename out_t, typename in_t>
inline out_t norm_2 (in_t const& in) {
return ublas::norm_2 (in);
}
[with out_t = double,
in_t = pyublas::numpy_strided_vector<std::complex<double> >]
Gives:
/usr/local/src/boost.hg/boost/numeric/ublas/vector_expression.hpp:1447: error:
no matching function for call to
'boost::numeric::ublas::vector_scalar_unary<boost::numeric::ublas::vector_slice<pyublas::numpy_vector<std::complex<double>
> >,
boost::numeric::ublas::vector_norm_2<boost::numeric::ublas::vector_slice<pyublas::numpy_vector<std::complex<double>
> > > >::evaluate(std::random_access_iterator_tag) const'
/usr/local/src/boost.hg/boost/numeric/ublas/vector_expression.hpp:1453: note:
candidates are: typename F::result_type
boost::numeric::ublas::vector_scalar_unary<E,
F>::evaluate(boost::numeric::ublas::dense_random_access_iterator_tag) const
[with E =
boost::numeric::ublas::vector_slice<pyublas::numpy_vector<std::complex<double>
> >, F =
boost::numeric::ublas::vector_norm_2<boost::numeric::ublas::vector_slice<pyublas::numpy_vector<std::complex<double>
> > >]
.... more candidates....
Any ideas? Can't I use pyublas::numpy_strided_vector<T> anywhere
ublas::vector could be used? (I'm assuming the answer is the same if it was
pyublas::numpy_vector<T>)
10 years, 6 months

eigen
by Neal Becker

I've been reading good things about eigen (on the eigen ML, mostly). I wonder
if anyone has looked into possibly interfacing this with python/numpy?
10 years, 6 months

to python conversion question
by Neal Becker

What happens if I pass a vector of a different element type than the c++ code
expects? For example, what if:
F (numpy_vector<double>)
is called from python with zeros (10, dtype=int)? How about other conversions
(double vs complex?)
What I'd like to happen is I'd get an error, and that if I wanted I could
overload F:
F (numpy_vector<int>)...
10 years, 6 months

Re: [Pyublas] Is this thing on?
by Neal Becker

On Thursday 22 January 2009, Andreas Klöckner wrote:
> On Donnerstag 22 Januar 2009, you wrote:
> > On Wednesday 21 January 2009, Andreas Klöckner wrote:
> > > On Mittwoch 21 Januar 2009, Neal Becker wrote:
> > > > On Wednesday 21 January 2009, Andreas Klöckner wrote:
> > > > > On Mittwoch 21 Januar 2009, Neal Becker wrote:
> > > > > > Very quiet on this list lately. Anything new?
> > > > >
> > > > > Not really--For me, PyUblas is doing the job it was designed for.
> > > > > That's not necessarily bad. :)
> > > > >
> > > > > Andreas
> > > >
> > > > Any thoughts on my proposed unification of strided/non-strided
> > > > vectors?
> > >
> > > As I said in my last email on the subject, I would like to retain
> > > PyUblas's ability to accept any-shape arrays with arbitrarily funky
> > > slicing. I am aware that the iterators presently don't make useful
> > > guarantees for these types of arrays, but being able to accept them at
> > > all is a plus regardless.
> > >
> > > Unfortunately, Ublas's stride capabilities are too poor to fulfill this
> > > requirement, so I don't see a good way of unifying strided/unstrided
> > > with only its help.
> > >
> > > IMO, the right solution would be to implement an iterator that
> > > understands NumPy's memory layout accurately. It's ok for this iterator
> > > to be bi-di (or even only forward) for now.
> > >
> > > Andreas
> >
> > As it stands now, neither numpy_vector nor numpy_strided_vector will do
> > anything useful when their iterators are applied to anything but a 1-dim
> > numpy array. Or, I should say I have no idea what happens if you give
> > them a >1 dimen array.
>
> numpy_vector will do something useful if given a 2+D array. If possible,
> it'll give you a begin() and end() that sweeps the entire contents of the
> array. That's weak, but it's not nothing. :) At least it makes sure that
> elementwise Ublas operations (2*x etc) do the right thing.
>
> > I thought that given the current situation, the distinction between
> > numpy_vector and numpy_strided_vector serves no purpose. There is no
> > longer any speed difference in my tests. The code can be simplified and
> > cleaned up.
>
> You sure there's no speed difference between strided and unstrided? I'd be
> very surprised.
>
> > If we insist that a >1 dimen array can be given to numpy_vector, my first
> > question is, what would you expect it to do, precisely?
>
> Pretty much what it does at present. Let elementwise stuff work.
>
> Andreas
Here is a test with USE_ITERATORS = True:
(I increased the number of loop iterations in these tests)
python strided_speed.py
test_ublas_speed: 6.940627s
test_unstrided_speed: 6.928687s
test_strided_speed: 93.956173s
test_ublas_speed2: 7.656597s
test_unstrided_speed2: 6.946584s
test_strided_speed2: 14.289721s
When native ublas operations are used (test_ublas uses x *= 2), there is a big
diff. This is IIRC because ublas uses indexing instead of iterators.
When we directly use iterators (test_ublas_speed2, etc), there is a lot less
difference. For nontrivial operations (not *= 2), I probably am OK with that
difference.
My problem is, that I want a lib of generic functions, and I really don't want
to have to write them 2 times for strided/nonstrided, nor try to guess when
someone might want to pass a strided vector. So, what are we to do?
10 years, 6 months