Re: Mir Slice.shape is not consistent with the actual array shape
On Sunday, 24 May 2020 at 15:24:14 UTC, 9il wrote: On Sunday, 24 May 2020 at 14:17:33 UTC, Pavel Shkadzko wrote: [...] BTW, the code example above doesn't compiles. OT: Instead of [...] you can generate the same common D array using Mir: auto a = [2, 2, 4].iota!int(1).ndarray; I posted in a rush. There should be "auto arrSlice = a.sliced;" and "writeln(a.getShape);".
Re: Mir Slice.shape is not consistent with the actual array shape
On Sunday, 24 May 2020 at 14:17:33 UTC, Pavel Shkadzko wrote: I am confused by the return value of Mir shape. Consider the following example. /// import std.stdio; import std.conv; import std.array: array; import std.range: chunks; import mir.ndslice; int[] getShape(T : int)(T obj, int[] dims = null) { return dims; } // return arr shape int[] getShape(T)(T obj, int[] dims = null) { dims ~= obj.length.to!int; return getShape!(typeof(obj[0]))(obj[0], dims); } void main() { int[] arr = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16]; int[][][] a = arr.chunks(4).array.chunks(2).array; writeln(arr); writeln(arr.shape); auto arrSlice = arr.sliced; writeln(arrSlice); writeln(arrSlice.shape); } /// [[[1, 2, 3, 4], [5, 6, 7, 8]], [[9, 10, 11, 12], [13, 14, 15, 16]]] [2, 2, 4] <-- correct shape [[[1, 2, 3, 4], [5, 6, 7, 8]], [[9, 10, 11, 12], [13, 14, 15, 16]]] [2] <-- which shape is that? I would expect sliced to create a Slice with the same dims. Well, sliced returns a shell over the array, but why does it return its own shape instead of the shape of the array it provides view into? This makes it even more confusing once you print both representations. What's the rationale here? BTW, the code example above doesn't compiles. OT: Instead of int[] arr = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16]; int[][][] a = arr.chunks(4).array.chunks(2).array; you can generate the same common D array using Mir: auto a = [2, 2, 4].iota!int(1).ndarray;
Re: Mir Slice.shape is not consistent with the actual array shape
On Sunday, 24 May 2020 at 14:35:33 UTC, jmh530 wrote: On Sunday, 24 May 2020 at 14:21:26 UTC, Pavel Shkadzko wrote: [snip] Sorry for the typo. It should be "auto arrSlice = a.sliced;" Try using fuse /+dub.sdl: dependency "mir-algorithm" version="*" +/ import std.stdio; import std.conv; import std.array: array; import std.range: chunks; import mir.ndslice; int[] getShape(T : int)(T obj, int[] dims = null) { return dims; } // return arr shape int[] getShape(T)(T obj, int[] dims = null) { dims ~= obj.length.to!int; return getShape!(typeof(obj[0]))(obj[0], dims); } void main() { int[] arr = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16]; int[][][] a = arr.chunks(4).array.chunks(2).array; int err; writeln(arr); writeln(a.shape(err)); auto aSlice = a.fuse; writeln(aSlice); writeln(aSlice.shape); } Yes, this works. It doesn't explain why sliced behaves like this though. Also, isn't sliced the default way of converting D arrays to Mir arrays? Above all arr.fuse.field flattens the array. So, fuse works as D join if combined with field but as slice allocator is used on a D array...
Re: Mir Slice.shape is not consistent with the actual array shape
On Sunday, 24 May 2020 at 14:17:33 UTC, Pavel Shkadzko wrote: I am confused by the return value of Mir shape. Consider the following example. [...] `sliced` returns a view on the array data, a 1-dimensional slice composed of common D arrays. Try to use `fuse` instead of `sliced`.
Re: Mir Slice.shape is not consistent with the actual array shape
On Sunday, 24 May 2020 at 14:21:26 UTC, Pavel Shkadzko wrote: On Sunday, 24 May 2020 at 14:17:33 UTC, Pavel Shkadzko wrote: I am confused by the return value of Mir shape. Consider the following example. [...] Sorry for the typo. It should be "auto arrSlice = a.sliced;" And another typo "writeln(arr.getShape);", too rushy.
Re: Mir Slice.shape is not consistent with the actual array shape
On Sunday, 24 May 2020 at 14:21:26 UTC, Pavel Shkadzko wrote: [snip] Sorry for the typo. It should be "auto arrSlice = a.sliced;" Try using fuse /+dub.sdl: dependency "mir-algorithm" version="*" +/ import std.stdio; import std.conv; import std.array: array; import std.range: chunks; import mir.ndslice; int[] getShape(T : int)(T obj, int[] dims = null) { return dims; } // return arr shape int[] getShape(T)(T obj, int[] dims = null) { dims ~= obj.length.to!int; return getShape!(typeof(obj[0]))(obj[0], dims); } void main() { int[] arr = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16]; int[][][] a = arr.chunks(4).array.chunks(2).array; int err; writeln(arr); writeln(a.shape(err)); auto aSlice = a.fuse; writeln(aSlice); writeln(aSlice.shape); }
Re: Mir Slice.shape is not consistent with the actual array shape
On Sunday, 24 May 2020 at 14:17:33 UTC, Pavel Shkadzko wrote: I am confused by the return value of Mir shape. Consider the following example. [...] Sorry for the typo. It should be "auto arrSlice = a.sliced;"
Mir Slice.shape is not consistent with the actual array shape
I am confused by the return value of Mir shape. Consider the following example. /// import std.stdio; import std.conv; import std.array: array; import std.range: chunks; import mir.ndslice; int[] getShape(T : int)(T obj, int[] dims = null) { return dims; } // return arr shape int[] getShape(T)(T obj, int[] dims = null) { dims ~= obj.length.to!int; return getShape!(typeof(obj[0]))(obj[0], dims); } void main() { int[] arr = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16]; int[][][] a = arr.chunks(4).array.chunks(2).array; writeln(arr); writeln(arr.shape); auto arrSlice = arr.sliced; writeln(arrSlice); writeln(arrSlice.shape); } /// [[[1, 2, 3, 4], [5, 6, 7, 8]], [[9, 10, 11, 12], [13, 14, 15, 16]]] [2, 2, 4] <-- correct shape [[[1, 2, 3, 4], [5, 6, 7, 8]], [[9, 10, 11, 12], [13, 14, 15, 16]]] [2] <-- which shape is that? I would expect sliced to create a Slice with the same dims. Well, sliced returns a shell over the array, but why does it return its own shape instead of the shape of the array it provides view into? This makes it even more confusing once you print both representations. What's the rationale here?