The _config file still contains the defaults for the GH repository configuration, which means that when I click the "go to repository" or "open issue" buttons in the book, I get sent to the default GH repository, instead of this one.
I'm opening this issue just to prevent this missing configuration to fall into oblivion.

Revision

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

• "Fortunately, the syntax – if we can even call it that – for user-defined functions, is super-simple." →
  • "Fortunately, the syntax – if we can even call it that –, for user-defined functions, is super-simple." or
  • "Fortunately, the syntax – if we can even call it that – for user-defined functions is super-simple." (IMO this is the best option)
• "The arrow keys instead moves up and down spatially," → "The arrow keys instead move up and down spatially,"
• Maybe I misunderstood the text, but in Dyalog 18.0 you can already do multi-line input, you just have to turn it on explicitly. In RIDE, that's setting the flag Dyalog_LineEditor_Mode = 1 (see the docs)
• "This way a function can behave" → "This way, a function can behave"
• "On way is" → "One way is"
• The snippet

]dinput
foo←{
    a←45
    _←{a←¯99⋄⍬}⍬
    a
}

has no spacing around the multiple ← and the ⋄, contrary to other snippets.

• "We could have said:

      sumred ← +/
      2 sumred ⍳10
1 3 5 7 9 11 13 15 17

to emphasize the fact that the operator really returns a function." →
Drop the ":", or rewrite beginning of next phrase as its own sentence, like "This emphasizes ..."

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.

• Keys can be enclosed in the HTML tag <kbd> for an amazing look and feel: Ctrl + Shift + Enter, for example.
• Not sure how strict you are being with the glyph names, but ∇ is called "Del", not "Recur".
• Do a "find+replace" of "boolean" with "Boolean", as the word derives from the proper noun "Boole".
• When talking about modified assignment, I confess I personally was slightly confused with the final ⋄ ⍬ in _←{a←¯99⋄⍬}⍬, _ ← {a +← 45 ⋄ ⍬}⍬, and others. Consider removing them (the trailing ⋄ ⍬).
• "is called dyadically, with 2 to its left and ⍳10 to its right." → " is called dyadically, with 2 to its left and ⍳10 to its right." (add code styling to "2" too).

This is sample session showing the error

Dyalog APL/S-64 Version 18.0.40684
Serial number: UNREGISTERED - not for commercial use
+-----------------------------------------------------------------+
| Dyalog is free for non-commercial use but is not free software. |
| A non-commercial licence can be used for experiments and        |
| proof of concept until the point in time that it is of value.   |
| For further information visit                                   |
| https://www.dyalog.com/prices-and-licences.htm                  |
+-----------------------------------------------------------------+
Wed Jan 26 22:30:45 2022

      I←⌷⍨∘⊃⍨⍤0 99 ⍝ Sane indexing

      m ← 3 3⍴(1 2 3)(3 2 1)(4 5 6)(5 3 1)(5 6 8)(7 1 2)(4 3 9)(3 7 6)(4 5 1)
      

      (0 0)(1 2)(2 2)I m ⍝ Multiple cells by index, like m[(0 0)(1 2)(2 2)]
INDEX ERROR
      (0 0)(1 2)(2 2)I m ⍝ Multiple cells by index, like m[(0 0)(1 2)(2 2)]
                     ∧
      I
   ⌷⍨ ∘⊃ ⍨ ⍤ 0 99 

Also this one in Reach indexing

      G[⊂(0 1)0]
INDEX ERROR
      G[⊂(0 1)0]
       ∧

      G[((0 0)0)((1 2)1)]
INDEX ERROR
      G[((0 0)0)((1 2)1)]
       ∧
      

And this Assignable indexing expressions

]DISPLAY m ← 3 3⍴9?9
┌→──────┐
↓┌→────┐│
│↓4 8 2││
││3 6 1││
││5 9 7││
│└~────┘│
└───────┘
(0 0⍉m) ← ¯1 ¯1 ¯1 ⍝ 0 0⍉m is the main diagonal.
DOMAIN ERROR
      (0 0⍉m)←¯1 ¯1 ¯1 ⍝ 0 0⍉m is the main diagonal.

The "finding things" chapter should say pervasion, not extension

Hey there, I have a scrolling issue that pops up in the chapter about the key operator.
I'm not sure it's "your" fault, and I don't even know if you can do anything about it...

I have two vertical scrolling bars on the right; one right next to the content (but to the left of where the "contents" index usually is), and one at the right edge of the browser, as per usual. The outer bar scrolls just fine, but the interior one, not so much. Cf. the screenshot:

I start by scrolling down and that bar works normally, then it gets stuck in that position; if I scroll down enough, it suddenly gets unstuck and proceeds to scrolling through the remainder of the page.

This happens both in Firefox and Chrome, for me, on Windows 10.

I hypothesised it could have to do with the fact that there are no subsections in that chapter, but the chapters about ⊤⊥ and ⍥ also have no subsections and do not have this issue.

https://xpqz.github.io/learnapl/workflow.html#link-limitations

"Do read the docs for LINK." should now point to https://dyalog.github.io/link

In Indexing > Assignable indexing expressions, the first code (given) block doesn't work on my machine:

]DISPLAY m ← 3 3⍴9?9
(0 0⍉m) ← ¯1 ¯1 ¯1 ⍝ 0 0⍉m is the main diagonal.
]DISPLAY m

Expected

Replace main diagonal of matrix m.

Actual

On the second line, 0 0⍉m raises DOMAIN ERROR.

Environment Info (copied from Dyalog > About)

IDE:
Version: 4.4.1
Platform: Linux x86_64
Date: 2021-12-03 13:35:27 +0100
Git commit: 6248a881ddba8a03befe08106cd02ee7e47b1fe1
Preferences:{
"kbdLocale":"en_US"
}

Interpreter:
Version: 18.0.40684
Platform: Linux-64
Edition: Unicode/64
Date: Jun 19 2021 at 00:08:29

Dyalog has a max rank of 99

15, actually.

Revision

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

• "By “immutable” in this context we mean non-destructive" → "By “immutable”, in this context(,?) we mean non-destructive"
• "If g is nested" → "If g is nested"
• "that the g vector" → "that the g vector"
• "straight-forward" → "straightforward"
• "the major cells of an array is basically those" → "the major cells of an array are basically those"
• "access elements that are deeply nested using reach indexing which we met briefly" → "access elements that are deeply nested using reach indexing, which we met briefly"

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.

• "and the right operand indexes:" → you've used "indices" and "indexes" as the plural form of "index", I suggest choosing one and sticking to it for consistency.
• "as suggested by the unofficial style guide" →
  • "as suggested by an unofficial style guide"
  • "as suggested by abrudz's unofficial style guide"
  • ...

Revision

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

• Typos and other minor issues:
  • Instead of looping an branching → Instead of looping and branching
  • to transform your data perhaps from → to transform your data, perhaps from
  • we’ll explain what this means properly later → we'll explain properly what this means later
  • The APL version turns the vector into a 2D array and sum-reduces → The APL version turns the vector into a 2D array, sum-reduces
  • First step is to “trade depth for rank” - turn → First step is to “trade depth for rank” – turn
  • and finally, pick the first value → And finally, pick the first value / Finally, pick the first value
  • in other words something that → in other words, something that
  • So what shape does a vector have → So, what shape does a vector have
  • has two componens → has two components
  • can also be used to re-shape data → can also be used to reshape data
  • in for example Python → in, for example, Python
  • thing that it’s worth → thing that is worth
• Strictly speaking, it's "the 'iota' primitive ⍳" or "the 'index generator' function ⍳", and not "the 'iota' function ⍳".
• In some places you write "2D" and, in others, "2-D"/"3-D"; I would suggest picking one and sticking with it

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.

• use inline code when talking about code
  • the APL character array ‘hello world’ → the APL character array ‘hello world’
  • matrix called m → matrix called m
  • two arrows on the box for m, but only one arrow on the box for v → two arrows on the box for m, but only one arrow on the box for v
  • it creates a vector 0 1 2 3 4 5 6 7 → it creates a vector 0 1 2 3 4 5 6 7
• when you write “Let’s ask Dyalog to give us a more verbose visualisation help first” and then turn boxing on, and rows, and whatnot, I feel the sentence is a bit awkward. I like how you are being nonchalant with all the incantations you are showing, I would just try to make the sentence simple, so that the readers feel safer more easily... Something like “Let's ask/configure Dyalog to produce more verbose outputs first” already feels "better" to me
• in the same place as the note above, I would remove the definition of assert, you don't use it in that chapter
• I would also consider not setting ⎕IO ← 0 in that same code box, because it makes it look like it has to do with the UCMDs to change session output when it has nothing to do with it; either change it later, or don't change it at all in this chapter (the chapter does use ⍳ here and there, so the outputs would become different)
• I find the paragraph

The shape vector now has two componens – as our matrix has two axes – the first axis, y, of length 3, and the second, x, of length 4. In other words, the shape of the shape tells us something about our array: its dimensionality, or its number of axes. If we instead take the length of the shape vector, we have its rank

a bit confusing. When you write "If we instead take the length ... we have its rank", it makes it look like the rank is not the dimensionality of the array, or its number of axes, which is the thing you just talked about. Sure, there's a difference between ⍴⍴ and ≢⍴, but I am sure you can put it across in a clearer way ;)

• I am not entirely sure I understood the target audience for this book; there are some things you explain with a lot of care, and other details you jump right over. For example, when you introduce ⍳, you say it creates consecutive integers “starting at the current index origin”, but you don't explain what that cryptic sentence means (this is related to the point above regarding setting ⎕IO ← 0)

Should be "already"

In functions.ipynb, section 'Direct operators', the dyadic use of Reduce is introduced as

2 (+/) ⍳10

This took a while for me to get my head around, as I was only familiar with the monadic Reduce producing the sum. It is briefly mentioned that this is a windowed reduction, but that is not properly introduced until iteration.ipynb, section 'Windowed reduction'.

Since it is used to introduce the dyadic case, a quick explanation of what this derived function does would be helpful there. The explanation used in the later section is clarifying

For example, to calculate the sum of each element in a vector with its subsequent element, we employ a reduction with a sliding window of size 2

but I could not predict that based on the understanding I had in the earlier section alone.

Many thanks for this resource, I am thoroughly enjoying it and find it very well presented!

Revision

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

• "but instead of moving it one step (the default) we want to shift it three steps each time:" → "but instead of moving it one step (the default), we want to shift it three steps each time:"

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.

• You write "2D" in here, but "2-D" in other places; consider sticking to a single one?
• "But now look what happens if we increase the window size to 3, which does not divide cleanly the operand array:" I don't understand the sentence, especially the phrase "does not divide cleanly the operand array".

You could very well only have runs of length 3 with elements from the vector:

      3 ,/ ⍳10
┌─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┐
│0 1 2│1 2 3│2 3 4│3 4 5│4 5 6│5 6 7│6 7 8│7 8 9│
└─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┘

What's happening here is that stencil goes farther than just the argument. Stencil goes up to the point where the original array ends at the centre of the window, regardless of that window size dividing the original vector length or not.
For example, with windows of size 7, the final window will be 6 7 8 9 0 0 0:

      ⊂⍤⊢⌺7⊢⍳10
┌─────────────┬─────────────┬─────────────┬─────────────┬─────────────┬─────────────┬─────────────┬─────────────┬─────────────┬─────────────┐
│0 0 0 0 1 2 3│0 0 0 1 2 3 4│0 0 1 2 3 4 5│0 1 2 3 4 5 6│1 2 3 4 5 6 7│2 3 4 5 6 7 8│3 4 5 6 7 8 9│4 5 6 7 8 9 0│5 6 7 8 9 0 0│6 7 8 9 0 0 0│
└─────────────┴─────────────┴─────────────┴─────────────┴─────────────┴─────────────┴─────────────┴─────────────┴─────────────┴─────────────┘

For even lengths, stencil goes up until the element to the right of the centre, and that's why there's no padding on windows of size 2.

• "The way to think of it is that given an odd-size window, each data point in the argument array must line up with the centre of the window. With even-sized windows, we have no choice, as we can’t have fractional indexing." this makes it a bit clearer what you meant above, maybe..? But IMO you could make it clearer that there will be padding always, not just for odd numbers, or something like that.
• "With an even size we can create non-overlapping windows that don’t “overhang”:" → here's an even-sized window with overhang

      ⊂⍤⊢⌺(⍪4 4)⊢⍳10
┌───────┬───────┬───────┐
│0 0 1 2│3 4 5 6│7 8 9 0│
└───────┴───────┴───────┘

Revision

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

• "should the function be passed an empty argument we don’t want to error:" → "should the function be passed an empty argument, we don’t want to error:"

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.

• "The function derived by Key is ambivalent (can be called either monadically or dyadically). The operand function can be any dyadic function returning a value. Let’s start with the monadic case." → you talk about the valence of the derived function, then the valence of the operand function, then the valence of the derived function; what is more, the third sentence doesn't state explicitly the function we are talking about, it uses a reference, so this excerpt might be slightly confusing. Consider reordering the three sentences, or making the last one more explicit, or ...
• Consider printing teams and scores before feeding them to the key operator, so that readers can see what's in there.
• Consider not using scores for two different things: the original character vector data and the actual game scores (extracted after ⎕CSV processing).
• Instead of referring to 0 as the "template element for the array", consider referring to it as "fill element of the array", to use APL terminology.

URL for the Unit testing framework gives a File not found error over here:

Ahem. Ninja master @ngn offered up the following [unit testing framework](https://ngn.bitbucket.io/apl/unit-test-framework.dyalog) on APL Orchard:

There is a typo in the section "Rank Drills"

What currently reads:

In his paper APL Excercises...

should be (without the first "c"):

In his paper APL Exercises...

Note to self: explain relative rank in the rank chapter.

I'd be interested in reading your book offline but the PDF link in the README does not appear to have been built.

On the APL Farm matrix/discord, it was suggested that

Arrays in Dyalog APL are always collections of scalars, regardless of rank. However, we can create arbitrarily complex scalars by a process known as enclosing. This means putting something in a “box”.

is unhelpful/confusing in the long run.

@marshall suggested

A scalar like the numbers we've used above is a single value with rank 0. APL also lets you create rank 0 arrays with something inside, which also act as one unit.

@marshall

Cells (0-cells) are just one way to cut up an array. Non fundamental..

@dzaima:

In APL, everything is an array. But what about numbers? They might not look or feel like arrays, but they are. But unlike vectors, which have rank 1, or matrices, which have rank 2, etc, they have rank 0. As such, the shape of a number is ⍬. What does that entail? Do numbers contain elements..? If so, how many? What are they? Well, we can ask APL [after previously having mentioned ×/⍴x to be the number of elements]: ×/⍬ → 1. (what's that element then? Well, it's the number itself, which leads to funky recrsion, but let's not get into that). Numbers (or characters) aren't the only possible rank 0 arrays, though - you can also make your own with ⊂x - this creates a rank 0 array containing x (comparing to x y, ⊂x has one element instead of two, rank 0 instead of 1, and the previously discussed shape ⍬ instead of ,2 [ugh APL lacking a way to not properly make a 1-item list is annoying here])

The example of finding a function's fixed point using ⍣= confused me

2÷⍨⍣=10 ⍝ Divide by 2 until we reach a fixed point

I understand that ⍣= will keep evaluating until the result no longer changes, but 10 (or any number) repeatedly divided by 2 only asymptotes to 0

      2÷⍨⍣1⊢10
5
      2÷⍨⍣2⊢10
2.5
      2÷⍨⍣10⊢10
0.009765625
      2÷⍨⍣100⊢10
7.888609052E¯30

so (I think) it only returns 0 because it loses precision.

I tried to find another more useful example. Application of the Collatz Conjecture always reaches 1, so that's perhaps not so interesting.

I suspect the canonical example of the Golden Ratio is more illuminating

      +∘÷⍣1⍨1
2
      +∘÷⍣2⍨1
1.5
      +∘÷⍣3⍨1
1.666666667
      +∘÷⍣=⍨1
1.618033989

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"

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.

• Typos and other minor issues:
  • similar to how c-like languages → similar to how C-like languages
  • one or more enclosed vectors each with → one or more enclosed vectors, each with
  • i.e → i.e.
  • bit-boolean arrays → bit-Boolean arrays
  • using a boolean array → using a Boolean array
  • But in the more general case we need not → But, in the more general case, we need not
  • A monadic pick means pick first element. → A monadic pick means "pick first element"./A monadic pick picks the first element.
  • 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.

• 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.)
• Use backticks when talking about code in your prose:
  • Indexing with [] or ⌷ returns → Indexing with [ ] or ⌷ returns
• Say something, somewhere, about the 4-line setup you use (setting ⎕IO, ]box, ]rows, assert); maybe a comment in the code block itself
• Remove the settings you don't need, especially the assert
• but it’s clear for a nested array: → but the distinction/difference is clear for a nested array:
• When you introduce squad ⌷,
  • you say that [ ] do not bind strictly right-to-left, which I don't think is a sentence many people will understand;
  • 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?);
  • 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.
• 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)

• change

select ← 0 0 1 0 1 1 0 1 1 0 ⍝ Select elements 2, 4, 5, 7 and 8
data   ← ⍳10

into

 data   ← 0 1 2 3 4 5 6 7 8 9
 select ← 0 0 1 0 1 1 0 1 1 0 ⍝ Select elements 2, 4, 5, 7 and 8

• In ”The full list of selective assignment functions is available from the Dyalog documentation. ”, replace the URL http://help.dyalog.com/18.0/index.htm#Language/Primitive%20Functions/Assignment%20Selective.htm#SelectiveAssignment with http://help.dyalog.com/latest/index.htm#Language/Primitive%20Functions/Assignment%20Selective.htm
• 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.

Just started to read this wonderful book, and I'm seeing some font issues. For example:

It also doesn't look right on the PDF version:

Is this a known issue?

Thanks,
Boaz

Revision

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

• Typos and other minor issues:

  • Here the left argument vector → Here, the left argument vector
  • it’s tempting think → it’s tempting to think
  • Take 1 is equivalent to Squad-0, not Pick-0: →
    • Take 1 is equivalent to Squad 0, not Pick 0:
    • Take-1 is equivalent to Squad-0, not Pick-0:
  • Take and Drop works on any rank array → Take and Drop work on any rank array
  • Ravel, monadic , and Enlist, monadic ∊ do related things →
    • Ravel, monadic ,, and Enlist, monadic ∊, do related things
    • Ravel (monadic ,) and Enlist (monadic ∊) do related things
  • You can of course get a similar → You can, of course, get a similar
  • The commute operator – by shifting the complex expression to the right side, avoids this. →
    • The commute operator, by shifting the complex expression to the right side, avoids this.
    • The commute operator – by shifting the complex expression to the right side – avoids this.
  • these twins are called grade up, ⍋ and grade down, ⍒. → these twins are called grade up (⍋) and grade down (⍒).

• You show

      1 2 3 4 , 5 6 'hello'
      1 2 3 4 5 6 , 'hello'

┌→────────────────────┐
│             ┌→────┐ │
│ 1 2 3 4 5 6 │hello│ │
│             └─────┘ │
└∊────────────────────┘
┌→────────────────┐
│1 2 3 4 5 6 hello│
└+────────────────┘

and then say “The distinction above is perhaps not obvious - and without ]box on they would look identical. Catenate ravels its right argument.”. I don't think I got what you were trying to say, but the sentence is wrong – catenate does not ravel its right argument! (If it did, I wouldn't be able to catenate two matrices, for e.g....)
These two cases are different because, in the first case, 5 6 'hello' is a nested array, whereas 'hello' is just a regular vector:

      5 6'hello'
┌─┬─┬─────┐
│5│6│hello│
└─┴─┴─────┘
      'hello'
hello

• “If selfie is given an array operand, it becoms constant: it always returns its left argument, kind of like a left-tack, or {⍺}:”
  A⍨, with an array A, derives a new function that can be monadic or dyadic. When you say “it always returns its left argument”, you are technically saying that X (A⍨) Y should return X, when it returns A. You can replace “argument" with “operand” and you will be correct, but then it could be nice to show a couple of examples of A⍨ used monadically and dyadically, and also show that A⍨ is not a scalar function, e.g., with

      1⍨ 2
1
      3 (1⍨) 2
1
      1⍨ 2 3 4 5
1
      1⍨¨ 2 3 4 5
1 1 1 1

• Right after the above, you write “If we give no left argument we also get constant but in a slightly different way. It echoes its right argument to its left:”. Because you already introduced A⍨ with an array A, readers cannot tell you are trying to talk about f⍨ with a function f. What is more, the name of f⍨ that “echoes its right argument to its left” is still "commute/switch", it is not "constant". (See, for e.g., this orchard msg, or check the docs to see the official name.)
• [ ]

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 “Learning what each glyph does is an unavoidable chunk of time investment, and there are some mnemonic cues sometimes based on where they sit on the keyboard, or that related functions sometimes have glyphs that are visually similar.”, the first statement (we have to invest time) should be contrasted with the fact that there are mnemonics, meaning "unavoidable chunk of time investment, and there" could probably be rewritten as something like

  • unavoidable chunk of time investment, but there
  • unavoidable chunk of time investment; thankfully, there
  • unavoidable chunk of time investment. However, there

• Be consistent in the way you write the names of the glyphs and the functions. In previous chapters, they were used as regular words. In this chapter, the capitalisation and italicisation of those names was rather inconsistent. I just want you to know, however, that I know how hard it is to be consistent with these tiny things 😛

• “We can somewhat simplified think of match being “deep equals for arrays”” needs something. I think the “simplified” there is conjugated in the wrong tense, or something like that; but the sentence is, at least, missing commas around “somewhat simplified”. It might also be me missing something, but the sentence would be simpler if it were just “We can think of match being “deep equals for arrays””.

• You use ⊢var←value all the time, so why did you opt for

transpose ← ⎕ ← ⍉mat
reverse ← ⎕ ← ⌽mat
revfirst ← ⎕ ← ⊖mat

instead of

⊢transpose ← ⍉mat
⊢reverse ← ⌽mat
⊢revfirst ← ⊖mat

• as the zip() found in for example Python, → as the zip() found in Python, for example,
• use “index of” or “index-of” for dyadic ⍳, but not both
• Talking about index of, you say “The right argument can have any shape, but the left argument is usually restricted to a vector.”. Maybe consider dropping the word "restricted" from there? IMO that will make it clearer that we generally see vectors on the left of ⍳, but doesn't make it look like ⍳ can only work with vectors on the left.
• see the ‘find’ section later! → Jupyter notebooks and the jupyter book tool have support for internal cross references, so it would be neat if ‘find’ were linked to the correct place :)
• When talking about selfie, consider presenting the two usages of f⍨ first, and only then talking about A⍨
• When talking about implementing ≢ as +/=⍨, refer to =⍨ as "self-equals" instead of "constant-equals", to prevent any confusion with the fact that ⍨ is also the "constant" operator, which is not what ⍨ is doing in =⍨
• We have the full complement of relational algebra operations at our disposal. → We have the full complement of set operations at our disposal. (?)
• When exemplifying grade up, it might help if the data you are ordering has numbers significantly different from the indices you will get

In Glyphiary, there is the sentence:

A nifty feature is that if the right element isn’t found, the returned index is 1+≢⍺ – one more than the length of the left argument.

This is true only if the index origin is 1. However, this very chapter (and the entire book so far) starts with setting it to 0:

      ⎕IO ← 1
      staff⍳'Bob' 'David'
┌→──┐
│2 4│
└~──┘
      ≢staff
 
3
 
      ⎕IO ← 0
      staff⍳'Bob' 'David'
┌→──┐
│1 3│
└~──┘
      ≢staff
 
3

Therefore, the sentence should instead read something like:

A nifty feature is that if the right element isn’t found, the returned index is ≢⍺ – the length of the left argument.

Alternatively:

A nifty feature is that if the right element isn’t found, the returned index is ⎕IO+≢⍺ – sum of the index origin and the length of the left argument.

Revision

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

• Inconsistent casing of programming language names (APL, J, K, Q all show up in upper-case, but then we can find java, c, c++, rust, go, etc)
• typos and similar issues:
  • "c, c++, Java, Python etc" → "c, c++, Java, Python, etc"
  • "code you write in other languages suddenly become" → "code you write in other languages suddenly becomes"
  • "Learning how to solve problems the data-parallel way, no loops, no branching is the" → "Learning how to solve problems the data-parallel way, no loops, no branching, is the"
  • "have to be a math-wiz to understand, or benefit from APL" → "have to be a math-wiz to understand, or benefit, from APL"
  • "no other general purpose programming language" → "no other general-purpose programming language"
  • "Tack might seen" → "Tack might seem"
  • "the function takes both a left, and a right argument, like" → "the function takes both a left, and a right, argument, like"
  • "only takes a right-side argument" → "only takes a right argument"
  • "argument, for example factorial, !:" → "argument; for example, factorial !:"
  • "if you hover over a glyph in the menu bar" → "if you hover over a glyph in the language bar"
  • "both its monadic, and dyadic uses, where applicable." → "both its monadic and dyadic uses, where applicable."

To consider

In here I include things that, from my point of view, would be nice additions/modifications.

• Adding the link to the original xkcd comic, either as a hyperlink for the image itself, or when you mention the name of xkcd
• Changing "d-fun" and "dfun" to "dfn" (possibly adding a note on pronunciation, if that was the original concern)
• Add link to the online mdapl (https://mastering.dyalog.com) when you mention that work on it is afoot
• Use double ~ in "an endless source of confusion joy" to add the actual strikethrough over "confusion"

See https://gist.github.com/xpqz/ae862364abdceb933fb14de7cb43fd7c

Hi,

I'd like to start off with a huge thank you because this book is nigh exactly what I was looking for to learn APL: not overly descriptive so as to waste time describing what is meant by a nested array, but good for someone like me who has experience programming in multiple other languages.

Attached is a screenshot. I am running this on Safari on Mac OS:

If you cannot see the image by some miracle of the internet, then just know that the font is not monospace; in fact it is very thin, making spacing go all over the place; it's not impossible but is indeed quite difficult to read and interpret matrices, especially as they get more complex.

I see this isn't the first time you've encountered this issue, and I really commend you for writing this book in the first place! Please do not hesitate to ask questions :)

In the Del section, where the example of the sum is shown:

(⍺+⊃⍵)sum 1↓⍵

The s in sum should be capital.

Here:

×⍨¨1+⍳9  ⍝ Square elements via each (but see below!)
1 4 9 16 25 36 49 64 81

It should be:

      ×⍨¨1+⍳9
4 9 16 25 36 49 64 81 100

the output is:

6 23 19 22 24 12 11 3 18 20 21 4 1 0 14 9 8 16 17 5 2 7 10 15 13

the text is:

the smallest element is to be found at index 24. The second-smallest is at index 12. The third smallest at index 6 etc.

should be:

the smallest element is to be found at index 6. The second-smallest is at index 23. The third smallest at index 19 etc.

⍸ isn't touched on in great enough extent.

There is a passing comment here - "Note that there is another glyph that looks similar, iota underbar, ⍸, that does something entirely different, so don’t confuse the two!" (And the Finding Thing's section)

Monadic ⍸ is a common way of filtering (especially in trains), besides coming up often in many popular problems for beginners (such as Project Euler), further, dyadic ⍸ is a confusing concept at first which may benefit from a thorough explanation.

Unlike other omitted symbols such as ○,⌹,⍟ & ! - iota underbar's ideas are unique to APL and may be useful for a beginner to be introduced to.