4,493
edits
Inner Product: Difference between revisions
Jump to navigation
Jump to search
m
Text replacement - "</source>" to "</syntaxhighlight>"
m (Text replacement - "<source" to "<syntaxhighlight") |
m (Text replacement - "</source>" to "</syntaxhighlight>") |
||
| Line 23: | Line 23: | ||
x+.×y ⍝ matrix multiplication | x+.×y ⍝ matrix multiplication | ||
32 | 32 | ||
</ | </syntaxhighlight> | ||
The [[shape]]s of the arguments must be compatible with each other: The last [[axis]] of the left argument must have the same length as the first axis of the right argument, or formally, for <syntaxhighlight lang=apl inline>X f.g Y</ | The [[shape]]s of the arguments must be compatible with each other: The last [[axis]] of the left argument must have the same length as the first axis of the right argument, or formally, for <syntaxhighlight lang=apl inline>X f.g Y</syntaxhighlight> it must be that <syntaxhighlight lang=apl inline>(¯1↑⍴X)≡(1↑⍴Y)</syntaxhighlight>. Although this rule differs from [[conformability]], the arguments may also be subject to [[scalar extension|scalar]] or [[singleton extension]]. The shape of the result is <syntaxhighlight lang=apl inline>(¯1↓⍴X),(1↓⍴Y)</syntaxhighlight>. | ||
For example, when applying inner product on two [[matrix|matrices]], the number of columns in the left array must match with number of rows in the right array, otherwise we will get an error. | For example, when applying inner product on two [[matrix|matrices]], the number of columns in the left array must match with number of rows in the right array, otherwise we will get an error. | ||
| Line 45: | Line 45: | ||
22 28 | 22 28 | ||
49 64 | 49 64 | ||
</ | </syntaxhighlight> | ||
== History == | == History == | ||
Inner product appeared in early [[Iverson Notation]] as <math>^f_g</math> and applied even to non-[[scalar function]]s, like [[Compress]], Iverson bringing:<ref>[[Ken Iverson]]. [[A Programming Language]]. §1.11 ''The language''.</ref> | Inner product appeared in early [[Iverson Notation]] as <math>^f_g</math> and applied even to non-[[scalar function]]s, like [[Compress]], Iverson bringing:<ref>[[Ken Iverson]]. [[A Programming Language]]. §1.11 ''The language''.</ref> | ||
| Line 85: | Line 85: | ||
\end{align} | \end{align} | ||
</math> | </math> | ||
When the inner product notation was linearised (made to fit on a single line of code) the [[glyph]] <syntaxhighlight lang=apl inline>.</ | When the inner product notation was linearised (made to fit on a single line of code) the [[glyph]] <syntaxhighlight lang=apl inline>.</syntaxhighlight> was chosed to denote what was previously indicated by positioning the two [[operand]]s vertically aligned. Thus, the above correspond to the following modern APL: | ||
<syntaxhighlight lang=apl> | <syntaxhighlight lang=apl> | ||
⍝ For example, if | ⍝ For example, if | ||
| Line 107: | Line 107: | ||
6 4 | 6 4 | ||
6 1 | 6 1 | ||
</ | </syntaxhighlight> | ||
Note that some dialects implement [[Compress]] (<syntaxhighlight lang=apl inline>/</ | Note that some dialects implement [[Compress]] (<syntaxhighlight lang=apl inline>/</syntaxhighlight>) as a [[monadic operator]] rather than as a function, which means it cannot be an operand in the inner product. Instead, a cover function is necessary: | ||
<syntaxhighlight lang=apl> | <syntaxhighlight lang=apl> | ||
∇z←a Compress b | ∇z←a Compress b | ||
z←a/b | z←a/b | ||
∇ | ∇ | ||
</ | </syntaxhighlight> | ||
== Differences between dialects == | == Differences between dialects == | ||
Implementations differ on the exact behaviour of inner product when the right operand is not a [[scalar function]]. It follows from page 121 of the ISO/IEC 13751:2001(E) [[standard]] specifies that <syntaxhighlight lang=apl inline>X f.g Y</ | Implementations differ on the exact behaviour of inner product when the right operand is not a [[scalar function]]. It follows from page 121 of the ISO/IEC 13751:2001(E) [[standard]] specifies that <syntaxhighlight lang=apl inline>X f.g Y</syntaxhighlight> is equivalent to <syntaxhighlight lang=apl inline>f/¨ (⊂[⍴⍴x]x)∘.g ⊂[1]y</syntaxhighlight>. This is indeed what [[APL2]], [[APLX]], [[APL+Win]], and [[ngn/apl]] follow, while [[Dyalog APL]], [[NARS2000]] and [[GNU APL]] differ as described by [[Roger Hui]]:<ref>[[Roger Hui]]. ''inner product''. Internal Dyalog email. 24 July 2020.</ref> | ||
<blockquote> | <blockquote> | ||
The following dop models inner product in Dyalog APL, with caveats. If you find a case where <syntaxhighlight lang=apl inline>f.g</ | The following dop models inner product in Dyalog APL, with caveats. If you find a case where <syntaxhighlight lang=apl inline>f.g</syntaxhighlight> differs from <syntaxhighlight lang=apl inline>f IP g</syntaxhighlight>, not covered by the caveats, I'd be interested. | ||
<syntaxhighlight lang=apl> | <syntaxhighlight lang=apl> | ||
IP←{ | IP←{ | ||
| Line 126: | Line 126: | ||
assert←{⍺←'assertion failure' ⋄ 0∊⍵:⍺ ⎕SIGNAL 8 ⋄ shy←0} | assert←{⍺←'assertion failure' ⋄ 0∊⍵:⍺ ⎕SIGNAL 8 ⋄ shy←0} | ||
</ | </syntaxhighlight> | ||
(Explanation: What's with the <syntaxhighlight lang=apl inline>⊃⍤0</ | (Explanation: What's with the <syntaxhighlight lang=apl inline>⊃⍤0</syntaxhighlight> in <syntaxhighlight lang=apl inline>IP</syntaxhighlight>? It's because <syntaxhighlight lang=apl inline>∘.f</syntaxhighlight> has an implicit each, applying <syntaxhighlight lang=apl inline>⊂</syntaxhighlight> to each item of its result. But the <syntaxhighlight lang=apl inline>⍺⍺/</syntaxhighlight> in <syntaxhighlight lang=apl inline>(⍺⍺/⍵⍵¨)</syntaxhighlight> also has an implicit each. So the <syntaxhighlight lang=apl inline>⊃⍤0</syntaxhighlight> gets rid of one of those encloses.) | ||
Caveats: | Caveats: | ||
* You can not use the hybrid <syntaxhighlight lang=apl inline>/</ | * You can not use the hybrid <syntaxhighlight lang=apl inline>/</syntaxhighlight> directly as an operand as it runs afoul of the parser in weird and wonderful ways. Instead, you have to use <syntaxhighlight lang=apl inline>{⍺/⍵}</syntaxhighlight>. The same goes for <syntaxhighlight lang=apl inline>\</syntaxhighlight> and <syntaxhighlight lang=apl inline>{⍺\⍵}</syntaxhighlight> I guess. | ||
* It differs from ISO/IEC 13751:2001(E) in using <syntaxhighlight lang=apl inline>⍵⍵¨</ | * It differs from ISO/IEC 13751:2001(E) in using <syntaxhighlight lang=apl inline>⍵⍵¨</syntaxhighlight> instead of just <syntaxhighlight lang=apl inline>⍵⍵</syntaxhighlight> in the central key expression (i.e. <syntaxhighlight lang=apl inline>(⍺⍺/⍵⍵¨)</syntaxhighlight> instead of <syntaxhighlight lang=apl inline>(⍺⍺/⍵⍵)</syntaxhighlight>). So does the primitive <syntaxhighlight lang=apl inline>f.g</syntaxhighlight>. | ||
* It differs from ISO/IEC 13751:2001(E) in doing full-blown single extension instead of just scalar and 1-element vector extension (as in APL2). So does the primitive <syntaxhighlight lang=apl inline>f.g</ | * It differs from ISO/IEC 13751:2001(E) in doing full-blown single extension instead of just scalar and 1-element vector extension (as in APL2). So does the primitive <syntaxhighlight lang=apl inline>f.g</syntaxhighlight>. e.g.<syntaxhighlight lang=apl> | ||
(3 4⍴5)+.×1 1 1 1⍴6 ⍝ works in Dyalog, not in ISO or APL2</ | (3 4⍴5)+.×1 1 1 1⍴6 ⍝ works in Dyalog, not in ISO or APL2</syntaxhighlight> | ||
* It differs from NARS2000 or APL\360 in not permitting unit axis extension. So does the primitive <syntaxhighlight lang=apl inline>f.g</ | * It differs from NARS2000 or APL\360 in not permitting unit axis extension. So does the primitive <syntaxhighlight lang=apl inline>f.g</syntaxhighlight>. e.g.<syntaxhighlight lang=apl> | ||
(3 4⍴5)+.×1 5⍴6 ⍝ works in NARS2000 or APL\360, not in Dyalog APL</ | (3 4⍴5)+.×1 5⍴6 ⍝ works in NARS2000 or APL\360, not in Dyalog APL</syntaxhighlight> | ||
</blockquote> | </blockquote> | ||