Arno Bastenhof (2) [Avatar] Offline
#1
First of all, thank you very much for writing this book. I'm looking forward to reading the next chapters.

As a bit of background, I'm mostly versed in a select few topics of discrete math (mainly set theory, logic and some graph theory), while having ended up forgetting most of my high school calculus. As so many others these days, however, I got interested in machine learning, and am brushing up on the relevant math skills. Speaking as someone who's still quite lacking in this latter regard, I think you're doing a very good job at explaining all the relevant math.

Below I include a few comments specifically about chapter 2. The last two points have more to do with the flow of the exposition and reflect only my own experience, so perhaps it's better to see how others feel in this regard. Also, in referring to page numbers, I used the PDF version of this book.

- At p.29, the cold front is said to move at a constant speed of 20 km / h. At p.33 (point 3), this is changed to 30 km / h. (EDIT: I just saw this one was already reported in another post.)

- The comment on p.37 about over- and underflow resulting in +Inf resp. -Inf might be emphasized more, given that most languages in the C lineage (which I assume your audience to be more familiar with) would would just wrap around.

- On p.38, u is called a prognostic variable. I had to look up "prognostic", but given that the results were about measuring the health condition of a system, I'm still not quite sure if I understand this term's usage in this context.

- On p.48, in dicussing the criteria for when a loop can be parallelized, it is mentioned that the variable on the left-hand side of an equation should not be used on the right-hand side. I don't see why this should be the case? In fact, in the code listing on p.52, you write

do concurrent (i = 1:im)
u(i) = u(i) - c * du(i) / dx * dt
end do

which also violates said condition.

- Section 2.2.1 (and a few other places before that) uses the term 'advection' prior to its definition in section 2.2.2. At two other places on the same page, 'movement due to background flow' is used instead, and while I came to interpret this as at least an approximation to a definition of the term, by this time I had also already looked it up elsewhere as well. Perhaps the first line of this section could be changed to something like the following?

"At this stage of our app, we will simulate only the movement of an object or fluid due to background flow; a process known as 'advection'."

I'm not sure if my usage of the word 'process' is correct here, but the main idea is to already link the new word (advection) to an approximation of its definition (movement due to background flow) as early as possible.

- On p.30 and p.31, the finite difference approach to approximating derivatives is explained using the earlier example of calculating the temperature gradient between Atlanta and Miami, i.e., the *spatial* gradient. However, right afterwards Fig. 2.5 is referenced for a "more general" illustration of this approach, which instead uses the temporal gradient. The method is, of course, no different (they're both gradients), and the exposition is fully correct, but I nonetheless found this a bit confusing initially.
Milan Curcic (13) [Avatar] Offline
#2
Hi Arno,

Thank you very much for your detailed comments! I am working on revising the early chapters for the next MEAP iteration and your comments definitely point to weak spots that need improvement and more clear language.

About the do concurrent: Yes, I realize now that my explanation on p48 is confusing. u(i) not being on the right-hand side is actually not the restriction here, i.e.:

do concurrent (i = 1:im) 
  u(i) = u(i) - c * du(i) / dx * dt 
end do 


is valid. The real restriction is that any variable that is referenced must not be defined or undefined during any other iteration. Because u(i) is referenced only in iteration i, it is allowed to be referenced on the right-hand side and assigned to on the left-hand side. Referencing u(i+1) or any element other than i would be illegal.

I find that the following question is a good test for concurrent loops: "Can the iterations go in any possible order and always yield the same result?"

I see how my statement on p48 is misleading and will correct that.