Post by Neal BeckerPost by Andreas KlöcknerPost by Neal BeckerPost by Andreas KlöcknerPost by Neal BeckerVery 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.
Post by Neal BeckerI 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.
Post by Neal BeckerIf 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?