Repository navigation
32 bit vs. 64 bit indexing #1
Description
Activity
Yes. If Array will ever become that powerful it would be fantastic, and this version just a prototype. Each axis is limited to u32 but the number of elements in an Array is limited only by usize – so it's not so bad.
Indeed indices are smaller so that we save space in Array and its iterators. I think the iterators are still too inefficient with 2 or more dimensions for the library to be respectable.
In my petgraph library I'm experimenting with configurable index size for a container via a defaulted type parameter, but it is a bit cumbersome.
Array is easier actually -- we are already generic over the dimension/indexing type. But just adding (usize, usize) as a dimension type will mean that (1,2) doesn't infer to one unique dimension type anymore.
I think I've underestimated how big a deal this is (due to strides, the u32 per dimension idea doesn't really work, strides are multiplied).
Yesterday I was window shopping for new computer languages and I found rust which looks awesome if not yet mainstream. I like array-based approaches to certain problems, so I checked for ndarray support and found this github library. Nice!
Anyway, I noticed that this crate uses
u32for indexing.http://bluss.github.io/rust-ndarray/doc/ndarray/struct.Array.html
In numpy it is increasingly common for users to have large arrays that cannot be indexed by such small integer types. I personally don't have enough RAM for this, but this could change in the future. Or you might want the same interface for arrays on disk as in RAM, or the same interface for sparse arrays that could more easily hold more entries. But of course using unnecessarily large integer types for indexing slows the code and increases the memory usage...