On Thu, 23 Aug 2012, George Bosilca wrote:

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

...

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

?

"sizeof" appears to be in math mode, but since it's a multi-letter variable name, it needs to be wrapped in \mathit so that LaTeX doesn't think it's a multiplication. "buf" on line 16 of that page has the same issue, while the version on line 14 doesn't.

...

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?

Both -- nothing ever says what "i" means.

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).

That's for i = 0 ... n-1, right? That is the part that is never explained in the text.

...

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.

See page 96 lines 7-9 -- why is the function defined that way (requiring the n-1 modification to calls) for Fortran?

...

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.

That is a suggestion to put on the list for the future.

...

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.

This seems like it would be a serious problem for implementations that have MPI_BOTTOM != 0; why is it too late to fix? -- Jeremiah Willcock