On Mon, 24 Jan 2022, Henry Rich wrote:
Your expectation of easy extension is unfounded.
The trivial case is still trivial, though, no? For any application at rank which is fast, and which has a direct expression as an application under transpose, it should be trivial to divert the latter to the codepath used by the former.
For anything which didn't have a fast expression in terms of rank, there was no existing expectation that it will be fast. So you do not _lose_ performance in any event.
(The difficulty of implementing and supporting virtual shapes pervasively is acknowledged.)
If you want this function, I think you should write your own conjunction for it and get some experience.
I will. But first, an argument I did not think of earlier:
In my code, I have sometimes needed to transpose before an operation but very seldom have I needed to transpose before and then transpose back.
I find it very plausible that, for a given problem, it is possible to find a data representation that minimizes the need for transpositions. However, easy access to transpose means that it is easier to develop and iterate without worrying so much about the underlying representation.
Case in point: I made a quadratic bezier curve renderer recently, representing the curve data using a three-dimensional array. So I had to choose how to order the axes. I got it wrong the first time, and had to restructure some code as a result. It might not have mattered so much, had there been a primitive to put the axes directly in the right order at the point where that was needed.
-E ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
