There was a formatting issue in that the section “Pick” shows the raw markdown (## Pick) instead of the header.
Revision
Here I include all of the things that, to the best of my knowledge and experience, should be changed/corrected.
[x] Typos and other minor issues:
[x] similar to how c-like languages → similar to how C-like languages
[x] one or more enclosed vectors each with → one or more enclosed vectors, each with
[x] i.e → i.e.
[x] bit-boolean arrays → bit-Boolean arrays
[x] using a boolean array → using a Boolean array
[x] But in the more general case we need not → But, in the more general case, we need not
[x] A monadic pick means pick first element. → A monadic pick means "pick first element"./A monadic pick picks the first element.
[x] Reach Indexing → Reach indexing
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.
[x] Indexing with [] or ⌷ returns the box, not the element, although if the element is a simple scalar, it’s the same thing. → Indexing with [] or ⌷ returns the box, not the element. However, if the element is a simple scalar, it’s the same thing. (The 4 , in the sentence made it a weird sentence to read.)
[x] Use backticks when talking about code in your prose:
[x] Indexing with [] or ⌷ returns → Indexing with [ ] or ⌷ returns
[x] Say something, somewhere, about the 4-line setup you use (setting ⎕IO, ]box, ]rows, assert); maybe a comment in the code block itself
[x] Remove the settings you don't need, especially the assert
[x] but it’s clear for a nested array: → but the distinction/difference is clear for a nested array:
[x] When you introduce squad ⌷,
[x] you say that [ ] do not bind strictly right-to-left, which I don't think is a sentence many people will understand;
[x] then you proceed to saying that ⌷ fixes some [ ] issues and introduces new ones, but I don't think you say which ones (maybe I missed them?);
[x] finally, you say “The binding is now APL-sensible:” and show three examples of indexing with ⌷; were those examples supposed to show how the binding is now sensible? To me, it felt like the examples simply showed how ⌷ works.
[x] Pick a cell from axis 1, i.e column 1 in our case: → For example, here is how we pick cell 2 from axis 1 (i.e., the third column):
2⌷[1]m
(I think it is important to index into a cell that is not the same number as the axis, so as to make the distinction between the axis and the indices abundantly clear)
[x] change
select ← 0 0 1 0 1 1 0 1 1 0 ⍝ Select elements 2, 4, 5, 7 and 8
data ← ⍳10
[x] In "large" code blocks with "many" outputs, consider splitting the code blocks to better interleave the code with the outputs. For example, in the code block where you compare sane indexing with squad, there's 5 outputs happening, and they could be perfectly well split in a 1-2-2 series.
xpqz
commented
3 years ago
There was a formatting issue in that the section “Pick” shows the raw markdown (
## Pick) instead of the header.Revision
Here I include all of the things that, to the best of my knowledge and experience, should be changed/corrected.
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.
,in the sentence made it a weird sentence to read.)[ ]or⌷returns⎕IO,]box,]rows,assert); maybe a comment in the code block itselfassert⌷,[ ]do not bind strictly right-to-left, which I don't think is a sentence many people will understand;⌷fixes some[ ]issues and introduces new ones, but I don't think you say which ones (maybe I missed them?);⌷; were those examples supposed to show how the binding is now sensible? To me, it felt like the examples simply showed how⌷works.(I think it is important to index into a cell that is not the same number as the axis, so as to make the distinction between the axis and the indices abundantly clear)
into