vbarrielle
commented
8 years ago Thanks a lot for all your feedback. I'll try to answer each point and open an individual issue for those that can be quickly addressed. I think we can have the discussion as issues here, since it's a good way to keep track of each individual point.
zeros, ones etc ask for StorageOrder, and default to C if given Unordered. Having to always specify order is a pretty serious inconvenience, I would much prefer the library chooses a default that allows me to not pass StorageOrder at all.
Put in issue #2
in fn strides why not return &DimArray? anyone else can clone, so no need for strides_ref that I see. Same for fn shape. Probably missing a subtlety.
There is fn strides_ref() to get a reference. But probably this feels weird. Do you have any naming idea for the reverse approach (ie strides() returns a reference, the other for a copy?)
ordering returns F,C even if inner_stride is not 1, so that data is not contiguous, that is pretty surprising to me.
Here I think we have two overlapping informations. Maybe an fn is_contiguous() should return one if the inner_stride is 1, because some algorithms want to know if we're in C or F order to choose the most efficient path, even without contiguous data. An other solution would be to have a more detailed enum for ordering. Let's continue that discussion in issue #3.
outer_block_iter is an interesting choice of iterator to have. I think the block_size=1 version whose items are of order smaller by one is the important one, so we can have nested loops that eventually consider elements. The general case is iter_subarrays(along: Axis), I think.
outer_block_iter is mainly there for products implementations, as it's always more cache-friendly to perform matrix products blockwise. But clearly users would need some friendlier API, like your proposed iter_subarrays. That was one of the features I was planning to add soon (I landed a slice_dim(axis: Axis, index: usize) yesterday that will enable that iterator).
data_index does not do the bounds checking. I'm not saying that is suboptimal, but I wonder.
I don't know whether it's the proper place to perform bounds checking, it does not actually access the data array. I think the out of bounds access needs to either happen later when actually indexing the data sllce, or earlier when this method is used to compute an index for unsafe unchecked indexing.
rows stands for number of rows, but could also stand for an iterator over rows or the Range of legal row indices (with the number as n_rows etc). I think we should prefer the language of the API to use higher level objects than usize as often as possible.
Good point for the naming, I feel there are 3 possible naming strategies:
- rows() and iter_rows()
- n_rows() and rows()
- n_rows() and iter_rows() The first two are somehow implicit but can be quite convenient, but it needs to be consistent throughout the API.
Using arrays as indices is a bit of a pain in the butt: let first = myarr[vec!(0,0,0)]; is kind of unwieldy. Wish Rust had nicer array syntax, but have to admit the bar of being about as lightweight as [] is high. Of course the matrix and vector special cases can be provided with 2-tuple and number instances of Index mostly solving the problem.
Actually indexing looks like:
let first = myarr[[0,0,0]];Getting a tuple instead of an array would mean the same amount of typing, but perhaps a nicer readability.
I think that supporting generally strided tensors is very important for interoperability with external ecosystem including numpy. That said, in my usage I expect the contiguous dimension to be part of the type, so that I know that my innermost loops are cache friendly. If we have such types, we can simply convert to them (testing the stride and returning None if incompatible, and creating a contiguous copy are both reasonable options).
Good point, though I don't know yet how to include it in the type. If possible I'd like to have such information as some kind of phantom data marker. Let's discuss that some more in issue #4.
This returns us to the question of writing algorithms abstractly over (most aspects of) tensor representation. I wonder if we need something like IntoTensor and FromTensor (as in IntoIterator, FromIterator), which allows a thing to be accessed with an appropriately sized array. Then binops can be implemented once in terms of IntoTensor, with return value organization determined externally. I am guessing the following: let c: RowMajorMatrix = a + b;
While this looks appealing as a feature, I can't figure out yet how this would work in practice. Though from an API point of view I think it will need to look like
let c: RowMajorMatrix = (a + b).collect();as it seems to be needed in std.
For general strided arrays, it seems natural to provide also Index<(usize,Axis)> and iter_subarrays(along: Axis).
Yes definitely needed. Issue tracked as #5
daniel-vainsencher
bluss
I'm mixing multiple issues here for discussion, we can break out things that need real change and close this later. We can move a discussion elsewhere, like the subreddit, as you wish.
zeros, ones etc ask for StorageOrder, and default to C if given Unordered. Having to always specify order is a pretty serious inconvenience, I would much prefer the library chooses a default that allows me to not pass StorageOrder at all.
in fn strides why not return &DimArray? anyone else can clone, so no need for strides_ref that I see. Same for fn shape. Probably missing a subtlety.
ordering returns F,C even if inner_stride is not 1, so that data is not contiguous, that is pretty surprising to me.
outer_block_iter is an interesting choice of iterator to have. I think the block_size=1 version whose items are of order smaller by one is the important one, so we can have nested loops that eventually consider elements. The general case is iter_subarrays(along: Axis), I think.
data_index does not do the bounds checking. I'm not saying that is suboptimal, but I wonder.
rows stands for number of rows, but could also stand for an iterator over rows or the Range of legal row indices (with the number as n_rows etc). I think we should prefer the language of the API to use higher level objects than usize as often as possible.
Anyway, this is clearly a sketch, most of the above will get fixed while adding stuff to flesh it out. Some larger issues:
Using arrays as indices is a bit of a pain in the butt:
let first = myarr[vec!(0,0,0)];
is kind of unwieldy. Wish Rust had nicer array syntax, but have to admit the bar of being about as lightweight as [] is high. Of course the matrix and vector special cases can be provided with 2-tuple and number instances of Index mostly solving the problem.
This returns us to the question of writing algorithms abstractly over (most aspects of) tensor representation. I wonder if we need something like IntoTensor and FromTensor (as in IntoIterator, FromIterator), which allows a thing to be accessed with an appropriately sized array. Then binops can be implemented once in terms of IntoTensor, with return value organization determined externally. I am guessing the following:
let c: RowMajorMatrix = a + b;
can be made to work even when a, b, c have different organizations, and efficiently when they do.