Boost logo

Ublas :

Subject: Re: [ublas] poll: what's your uBLAS I/O usage ?
From: Jesse Perla (jesseperla_at_[hidden])
Date: 2010-06-01 10:51:11

Rutger ter Borg <rutger <at>> writes:

> a) definitely the right metafunctions. Perhaps not restrictive enough yet,
> as the provided data may be a range / slice / view? I.e., a linear_array
> doesn't guarantee that the object modeled uses that memory in a contiguous
> way. For this, you could use the stride_*() and size_*() meta-functions.

I think that for now, it is reasonable to expect an in memory copy for
non-contiguous data (or column-major). So perhaps I can get iterators
on the data which would work for strides > 1? Is there a bindings method
to get a generic iterator that I could use for std::copy to a contiguous
chunk of memory? Is this what the linear_iterator is for? If so, how do
I get it for an arbitrary matrix and vector? I couldn't figure out the right
combination of tags/etc.

My basic strategy would be:
1) If stride > 1 for either dimension, then do a std::copy with generic
2) If storage ordering is column major, then do a transpose. (order with 1
could be reversed depending on what trans() does)
3) Write the data with the API, then free the allocated memory

Does this make sense? I am going to hold off on sparse matrices for now
since I don't need them and don't understand much about the storage.

Am I missing something here when I think that storing the trans of a fortran
ordered matrix (of arbitrary strides) with an API that expects C storage will
end up correct in matlab?

> b) we have begin_value and end_value which work for any container, but, in
> case of a view, may result in too much data. begin() and end() work for
> (strided) vectors, but isn't implemented yet for matrices (there's some work
> remaining to do on the iterators). Please see bindings/begin, bindings/end,
> bindings/detail/linear_iterator for most of the stuff. Feel free to
> contribute

Thanks. I was kind of confused with the begin() and end() for matrices
and exactly what I should be passing for the tags. And I wasn't sure if
these returned an iterator throw rows/columns or pointers to the underlying
data storage. Any hints for this?

> c) there is no algorithmic support for doing in-place transpose besides
> those in lapack/aux. Is this what you're asking? There's the trans()
> function, of course (which allows mutable access).
I couldn't figure out what the trans() did exactly. Can I:
1) trans() my structure if column major
2) Ask it for a linear iterator to go through the data and do my copy? With
the linear iterator now going through in the right order?

Thanks for your help. Hopefully this can be a test case for the bindings.