"Iteration" revision

[rodrigogiraoserrao]

Revision

Here I include all of the things that, to the best of my knowledge and experience, should be changed/corrected.

• In the beginning, when you say ×⍨1+⍳9 is using scalar extension, it is not. Scalar extension is when a scalar is extended to match the shape of another array. 2*⍨1+⍳9 would use scalar extension; in ×⍨⍵, both arguments have the same shape, by definition
• "used by Compress/replicate" → "used by Compress/Replicate" for consistency
• "Reduce first is so called" → "Reduce first is called so"
• "rank 2 integer array" → "rank-2 integer array"
• "If we wanted to sum-reduce along the rows, we can either use / which for historical reasons does just that:" →
  • "If we wanted to sum-reduce along the rows, we can either use / – which for historical reasons does just that:"
  • "If we wanted to sum-reduce along the rows, we can either use / (which for historical reasons does just that):"
• "One example is to find a function’s fixpoint:" → "One example is to find a function’s fixed point:"
• The glyph ∇ is called "Del", not "Recur".
• "both nicely tail recursive, and probably similar how you’d" → "both nicely tail recursive, and probably similar to how you’d"

To consider

In here I include things that, from my point of view, would be nice additions/modifications. Tick them as you ponder on them, feel free to disregard.

• "We can, somewhat simplified, think of the Reduce first operator injecting its left operand function in the gaps between elements in the argument:" seems like a contrived sentence, might be lack of English mastery from my side. I personally find something like "Somewhat simplifying, we can think of the Reduce first as an operator that injects its left operand function in the gaps between elements of the argument:" more pleasant.
• "In general, for consistency it’s best to prefer operators and functions that default to applying to the leading axis where possible." → There's some redundancy in "it's best to prefer" + "where possible"..?
• "we can employ a sliding window and so instead compute a set of reductions over shorter stretches of the data." I find this phrase too long to read; it's missing some punctuation, IMO.
• "sliding reduction window of size 2" the order here looks weird; "reduction with a sliding window of size 2"?
• In the English description of the recursion of your Sum dfn, you wrote "add the head of the right argument to the accumulator, and recur on this to the left, and the tail to the right". While I can understand it, I think the propositions "to" were misused; consider writing something like "add the head of the right argument to the accumulator. Recur with the accumulator on the left and with the tail on the right" if you want to preserve the spatial/location hints, or be super explicit with something like "add the head of the right argument to the accumulator. Recur with the updated accumulator as the new left argument and with the tail as the right argument."
• "If the last thing the function does is a function call, and this includes a Recur call, " for clarity, consider rewording as "If the last thing the function does is a recursive function call, ", to help distinguish cases like ⍺∇⍵+1, where tail recursion kicks in, and 1+⍺∇⍵, where tail recursion doesn't kick in.
• Avoid the usage of inline, multi-line dfns, such as the one inside bsearch, so as not to motivate that kind of style. inline, multi-line dfns are a pain to debug because program flow goes all over the place in those. Instead, assign the multi-line dfn and then call it.
• "The binary search implementation we concluded the previous section above with" →
  • "The binary search implementation with which we concluded the (previous) section (above)" (pick only one of previous/above)
  • "The binary search implementation we concluded the (previous) section (above) with" (pick only one of previous/above)
• As far as I know, the k language uses a lower case "k"