Dyadic function: Difference between revisions
mNo edit summary |
m (Text replacement - "</source>" to "</syntaxhighlight>") |
||
| (One intermediate revision by the same user not shown) | |||
| Line 6: | Line 6: | ||
A sequence of dyadic functions is evaluated from right to left to increase the similarity to monadic function evaluation. The following example shows this evaluation: | A sequence of dyadic functions is evaluated from right to left to increase the similarity to monadic function evaluation. The following example shows this evaluation: | ||
< | <syntaxhighlight lang=apl> | ||
1 -⍨ 3 ↑ 4 | 1 -⍨ 3 ↑ 4 | ||
3 ¯1 ¯1 | 3 ¯1 ¯1 | ||
</ | </syntaxhighlight> | ||
Going from right to left, the first function to be evaluated is [[Take]] (< | Going from right to left, the first function to be evaluated is [[Take]] (<syntaxhighlight lang=apl inline>↑</syntaxhighlight>), a [[primitive function]], followed by the [[derived function]] <syntaxhighlight lang=apl inline>-⍨</syntaxhighlight> ([[Minus]] [[Commute]]). This sequence extends the [[scalar]] 4 to a [[vector]] <syntaxhighlight lang=apl inline>4 0 0</syntaxhighlight>, and then subtracts 1. | ||
Dyadic functions in APL are designed so that the right argument is primary and the left secondary. Often the right argument consists of data to be manipulated while the left controls how it is modified. For example, in [[Reshape]], the right argument contains data while the left contains a new [[shape]] for it—arguably metadata. This pattern is used because of APL's right-to-left evaluation. It improves control flow by making the left argument shorter more of the time. This reduces the need for parentheses and allows a reader to scan an expression from right to left all at once, without jumping back and forth. When a function does not fit this pattern (such a mismatch can happen with [[Squad]], in which either argument might be considered primary depending on context), the [[Commute]] operator can be used to change it so that it does. | Dyadic functions in APL are designed so that the right argument is primary and the left secondary. Often the right argument consists of data to be manipulated while the left controls how it is modified. For example, in [[Reshape]], the right argument contains data while the left contains a new [[shape]] for it—arguably metadata. This pattern is used because of APL's right-to-left evaluation. It improves control flow by making the left argument shorter more of the time. This reduces the need for parentheses and allows a reader to scan an expression from right to left all at once, without jumping back and forth. When a function does not fit this pattern (such a mismatch can happen with [[Squad]], in which either argument might be considered primary depending on context), the [[Commute]] operator can be used to change it so that it does. | ||
Latest revision as of 22:14, 10 September 2022
- For operators with two operands, see Dyadic operator. For Dyadic Systems Ltd., see Dyalog Ltd.
A dyadic function is a function with two arguments, one on the left and one on the right. It is one of three possible function valences; the other two are monadic and niladic. The term infix function or infix operator is used outside of APL to describe APL's dyadic function syntax.
In APL, a single function can be both monadic and dyadic; such a function is called ambivalent or sometimes variadic. Function pages on the APL Wiki usually only describe one valence of an ambivalent function because the connection between the two may not be consistent across languages. In this case the function is described as dyadic even though it may only be half of an ambivalent function.
A sequence of dyadic functions is evaluated from right to left to increase the similarity to monadic function evaluation. The following example shows this evaluation:
1 -⍨ 3 ↑ 4 3 ¯1 ¯1
Going from right to left, the first function to be evaluated is Take (↑), a primitive function, followed by the derived function -⍨ (Minus Commute). This sequence extends the scalar 4 to a vector 4 0 0, and then subtracts 1.
Dyadic functions in APL are designed so that the right argument is primary and the left secondary. Often the right argument consists of data to be manipulated while the left controls how it is modified. For example, in Reshape, the right argument contains data while the left contains a new shape for it—arguably metadata. This pattern is used because of APL's right-to-left evaluation. It improves control flow by making the left argument shorter more of the time. This reduces the need for parentheses and allows a reader to scan an expression from right to left all at once, without jumping back and forth. When a function does not fit this pattern (such a mismatch can happen with Squad, in which either argument might be considered primary depending on context), the Commute operator can be used to change it so that it does.