Extended Inner Product

[mikepowell]

I need some help with what I call an extension to inner product. It goes like
this.

xip is an operator taking a number n of axes as its left argument. It produces
a dyadic function which behaves like an inner product, but rather than acting on
vectors, it acts on arrays of greater rank n. For example:

a←?3 2 4⍴9
b←?2 4 5 6⍴9
⍴a(2 xip)b
3 5 6

One way I'm familiar with is to do a full outer product followed by appropriate
tensor contractions. That's a bit wasteful. An approach I'd prefer is to ravel on
the last n axes of a and the first n axes of b, followed by a regular matrix
multiplication. Something like:

xip←{(,⍤⍺⍺⊢⍺)+.×,[⍺⍺↑⍳⍴⍴⍵]⍵}

Is there a way I can avoid the ravel with axis specification and instead use the
rank operator?

Mike

[Phil Last]

I believe that

      ,[⍳⍺]⍵ ←→ ⍉,⍤⍺⊢⍉⍵

but would find it hard to prove. Also I'm not at all sure it improves either readability or efficiency.

[Phil Last]

I suggested that

      ,[⍳⍺]⍵ ←→ ⍉,⍤⍺⊢⍉⍵

It wasn't. But

      ,[⍳⍺]⍵ ←→ (1⌽⍳⍴⍴z)⍉z←,⍤⍺⊢((-⍺)⌽⍳⍴⍴⍵)⍉⍵

certainly seems to be for ⍺ from 1 to rank ⍵ 'though it's even less readable and probably far more expensive.

[Bob Armstrong]

I posted and commented on this post to the FB group FORTH PROGRAMMING LANGUAGE 21st CENTURY , https://www.facebook.com/groups/PROGRAM ... 1030236918 , as an example of " APL thinking " .

The Forth community generally works and thinks at the very minimal and direct hardware level and has a strong tendency to think that's all they need even for complex problems . They'll just build vocabulary to deal with it .

Only some understand the value of general vocabulary at a high level of abstraction and structural discipline such as APLs provide .

[mikepowell]

Phil,
Thanks for the offerings. I'll go with the original, even it does look like there's something wrong with the language.

Bob,
I no longer do Facebook in any form, but it's good to know that others are thinking along these lines.

Mike

[Phil Last]

Sorry but the former is definitely and definitively wrong for combining two axes or more. Monadic transpose is equivalent to {(⌽⍳⍴⍴⍵)⍉⍵} so two or more leading axes shifted to the end will themselves be transposed prior to the ravel then returned to the front as {⍉,⍉⍵}.

The latter algorithm merely shifts them to the end without disturbing their internal order. Then back to the front after ravel.