I’m writing a utility that collects a user’s n-dimensional matrices over time and stores them in an n+1 dimensional array. Something like this:
storage[:, :, k] = input
But of course I can’t literally type those colons, because the input could be anything (as long as it’s consistent from call to call). So I’ve written this to store the input matrix:
For what it’s worth, in my case storage is actually part of an HDF5 file with a space preallocated for all of the data the user will pass in. The syntax for [:, :, :, k] is what the HDF5 package uses for input, and I don’t think strides will work for it.
My syntax above just feels a little silly, and I’m wondering if there’s a better way.
EllipsisNotation.jl at least gives nice syntax: storage[..,k]. In was fine for performance, but when we made it more generic it doesn’t infer properly anymore so you may want to use an older version, or help us finish it up .
Thanks, but if I understand correctly, this would be for reading, and I need to write with setindex! (it’s the method the HDF5 package has writing to data in files). Have I missed something?
This is more elegant than what I had. My code now looks like (taken from EllipsisNotation.jl):
colons = (Colon() for i in 1:length(size(input)))
storage[colons..., k] = input
Nice. I’m going with @ChrisRackauckas’s suggestion for clarity, but I wonder if this recursive implementation is any faster?
One could; it just won’t work for my application, where storage is (must be) a multidimensional array.
Thanks all. You helped me retire a TODO in my code, find a bunch of new functions, and figure out why @bramtayl’s second replace_last method would be interpreted as the base case.
Only if you hit the splatting penalty, i.e. have more than 16 dimensions. The issue with EllipsisNotation.jl is a little bit different and has to do with inferrability when it generalized. If it infers correctly, any implementation should be about the same speed.