On Aug 23, 2012, at 20:56 , Jeremiah Willcock <[email protected]> wrote:
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.
One is inside and the other outside a math environment. Fixed.
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.
Right. We used j above so it make sense to keep referring to them as _j and not _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).
That's for i = 0 ... n-1, right? That is the part that is never explained in the text.
It is expressed on the definition of the Typemap few lines above.
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?
Answered by Rajeev.
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?
After reconsideration removing the last bullet in the list should be enough. george.
-- Jeremiah Willcock _______________________________________________ mpi-comments mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-comments