Row/column major ordering

[wilzbach]

See also: https://en.wikipedia.org/wiki/Row-major_order

It is sometimes useful to apply an operation in "Fortran mode"
(=column-major, everted)

Have a look at this example from NumPy:

>>> a = np.arange(6).reshape((3, 2))
>>> a.reshape(2,3, order='F')
array([[0, 4, 3],
       [2, 1, 5]])

You can think of this as "look at the array in column mode" -
apply the operation and "write in back in column mode".

So in Python one can actually "simulate" it with the following

>>> a.T.reshape(3,2).T
>>> array([[0, 4, 3],
       [2, 1, 5]])

If one tries the example with ndslice we get

b.everted.reshape(2, 3).everted.writeln;
/// [[0, 1], [2, 3], [4, 5]]

which makes a bit of sense, because everted just reverts the order of iteration.
It is possible to do the same as above correctly with byElement and array.
However it feels wrong to have to copy the array.

b.everted.byElement.array.sliced(3,2).everted.writeln;
// [[0, 4, 3], [2, 1, 5]]

[9il]

See also #9

[wilzbach]

Hmm I like your idea of overloading opCall, but it works only for element access.
What do you think about something like the following?
(the last two are proposed)

It should basically work similar to opIndex then ;-)

auto s = iota(4).sliced(2,2);
s[].writeln; // [[0, 1], [2, 3]]
s().writeln; // [0, 2], [1, 3]]
s(1).writeln; // [[0,2]]

[9il]

Hmm I like your idea of overloading opCall, but it works only for element access.

Yes, first we need a good DIP for opCall to be like opIndex. See http://wiki.dlang.org/DIPs

It should basically work similar to opIndex then ;-)

Behavior with .writeln looks bad to me. opCall should only select sub-dimensions without any transpostion.

[wilzbach]

Yes, first we need a good DIP for opCall to be like opIndex. See http://wiki.dlang.org/DIPs

I guess one could use iota instead of .., apart from that variadic arguments should be supported ;-)

Behavior with .writeln looks bad to me. opCall should only select sub-dimensions without any transpostion.

What would you suggest s(1) should return then?

[9il]

I guess one could use iota instead of .., apart from that variadic arguments should be supported ;-)

Anyway $ is not defined for opCall

What would you suggest s(1) should return then?

s().writeln; // [[0, 1], [2, 3]] instead of [[0, 2], [1, 3]]
s(1).writeln; // [0, 2] instead of [[0,2]]

[wilzbach]

Anyway $ is not defined for opCall

You could also overload with tuples and replace the $ with -1

s = iota(9).sliced(3, 3);
// 0 1 2
// 3 4 5
// 6 7 8

// 0 3 6
// 1 4 7
// 2 5 8
s(tuple(1,2), tuple(1, 2)); // [[4,7], [5,8]]
s( tuple(1,-1), tuple(1, -1)); // same

Oh sry - made the brackets for s(1) by mistake.

For s() I am not sure yet, but by looking at the examples with everted above, I notice two things

b.everted.reshape(2, 3).everted
b().reshape(2, 3)(); // similar, but definitely harder to read

1. the opCall syntax is quite hard to distinguish/read and to understand whats going on. Why not add a simple method, e.g. b.F(2, 3) (probably better naming required though)

2. The main point of this issue was that in the examples the math index order is not stored, leading that b.everted.reshape(2, 3).everted evaluates differently than maybe expected and one needs to make a copy of the array..

[9il]

You could also overload with tuples and replace the $ with -1

-1 would significantly reduce performance.

[wilzbach]

-1 would significantly reduce performance.

and if i think about it one couldn't do stuff like (2, $-3)

[9il]

duplicate of #10