On Aug 18, 2012, at 20:13 , Jeremiah Willcock <[email protected]> wrote:

Chapter 4:

On page 83 line 23, "communication" should be "communications".

On page 83 line 34, "shape and size" should be "shapes and sizes".

Done.

On page 84 line 42, "sizeof" should be inside \mathit.

?

On page 84 line 45, where does "i" come from? Is the extent rounded to a multiple of k_i, or is the upper bound rounded (these differ when lb is not aligned)? If extent is rounded, the +eps term should be moved to the computation of extent, not ub, unless that definition of ub is used somewhere else.

Which i? The type_i or k_i? The upper bound is increased in such a way that the extent is a multiple of the biggest k_i (to solve all alignment issues in the case multiple instances of the same datatype are considered).

On page 95, why does MPI_TYPE_CREATE_SUBARRAY use zero-based indexing for Fortran; I believe many other places in MPI use one-based array indices when called from Fortran, even if they use zero-based indices from C.

I can't find any text that correspond to this remark.

Also, is there a version of MPI_TYPE_CREATE_SUBARRAY that allows strided indexing in the dimensions (MPI_TYPE_CREATE_DARRAY looks more limited)?

One can use a carefully hand-crafted datatype to achieve this.

On page 103 line 18, MPI_ADDRESS has now been removed, not just deprecated.

Indeed.

Is offset of a valid way to get displacements within C structs to use with MPI (rather than creating an object of that type and calling MPI_GET_ADDRESS on it and its individual fields)?

Absolutely.

Wouldn't MPI_TYPE_SIZE and a way to "flatten" an MPI datatype into a datatype with the same primitive elements but sequential in memory (or using MPI_PACKED) be better than MPI_TYPE_TRUE_EXTENT for the example on page 108 line 29?

There are multiple ways to achieve the goal depicted in the example. MPI_Type_get_true_extent is a valid one, even if not the most optimal in terms of memory.

On page 110 line 24, there should be a comma after "e.g.".

On page 111 line 42, there is some odd space at the end of the line.

Weird, I can't figure out how to get rid of this one. I'll investigate more.

On page 112 line 7, there shouldn't be a space after "datatype".

On page 112 lines 11-14, should there be an MPI_TYPE_FREE added as well?

Pedantic(!).

On page 115 line 44, it seems odd that adding MPI_BOTTOM to a valid address gives a valid address, since that allows me to create a valid address MPI_BOTTOM * n + v where n is nonnegative and v is a valid address.

Too late to change now. We realized this few weeks ago, and we amended the example 4.18.

On page 128 line 32, example 4.18 uses "class" as a field name, which makes it impossible to compile with a C++ compiler.

Fixed. Thanks, george.