SRFI 122 draft 12 comments | Sudarshan S Chawathe | 25 Sep 2016 00:00 UTC |

Re: SRFI 122 draft 12 comments | Bradley Lucier | 26 Sep 2016 20:37 UTC |

array-fold-{left|right} and array-reverse | Bradley Lucier | 29 Sep 2016 18:15 UTC |

For draft 14 (Re: SRFI 122 draft 12 comments) | Sudarshan S Chawathe | 03 Dec 2016 22:06 UTC |

Re: For draft 14 (Re: SRFI 122 draft 12 comments) | Bradley Lucier | 09 Dec 2016 18:28 UTC |

SRFI 122 draft 12 comments

*Sudarshan S Chawathe*25 Sep 2016 00:00 UTCThese comments refer to Draft #12 published: 2016/9/17. Most, but not all, are very minor. The comments are in roughly document order, not significance order, so I hope folks won't punt on the whole message because of the nitpicky/trivial nature of the first few. (They get better, I think!) I'm sorry to get these in so late given today's "last call" deadline. As such, they are the result of a rather rushed reading, and so are somewhat more likely than usual to reflect problems at my end. I'll also note that I have only skimmed the previous messages on the list, so it is possible some items have been discussed already. * (trivial, naming) Is the ->vector part of the name interval-lower-bounds->vector (and interval-upper-bounds->vector) motivated by the need to distinguish it clearly from interval-lower-bound (and interval-upper-bound)? Otherwise, it seems interval-lower-bounds (and interval-upper-bounds) would be more natural, since the objects provided to make-interval are vectors. * (trivial, formatting) Odd formatting for code explaining interval-volume. (Probably a missing 'pre' tag.) (apply * (vector->list (vector-map - (interval-upper-bounds->vector interval) (interval-lower-bounds->vector interval))) A similar comment applies to the code that explains generic-storage-class. There are a few other similar instances elsewhere in the document. * (minor) Should the signature for interval-contains-multi-index? read interval-contains-multi-index? interval index-0 index-1 ... following the Scheme reports convention (I think) that ... denotes 0-or-more of the preceding? (The following text does clarify the point, since d > 0, so this change would just emphasize the point.) * interval-curry: In the explanation, there is an instance of left-dimension that should probably read right-dimension. * (minor) interval-for-each: It was not initially clear to me whether the procedure f is required to accept multi-indices separately (one argument per dimension) or combined as a single list of indices. Given the definition of an interval as a set of multi-indices, I interpreted an element of an interval to be a tuple/list of indices and so was leaning toward the latter, but the sample implementation implies the former. It could just be my misreading of earlier material, though. (A similar comment applies to interval-reduce.) * (nit) interval-permute: The correspondence is obvious, but the text here refers to the dimension of the permutation while the definition of permutations earlier calls it length. * make-array: In the second and third paragraphs of the explanation, 'array' should read 'make-array'. There are a couple more instances in the paragraph just before the example too. * array-map: Should the constraints on f be noted (although they can be inferred)? * array-curry: There seems to be a missing pair of parentheses in the example. I believe (equal? ((array-getter A) i j k l) (array-getter ((array-getter B) i j k) l)) should read (equal? ((array-getter A) i j k l) ((array-getter ((array-getter B) i j k)) l)) instead. * array-curry: Defining A and B as in the example, I get an error when I attempt, for example, ((array-getter B) 2 3 5) => *** ERROR IN (console)@48.1 -- Wrong number of arguments passed to procedure (#<procedure #12> 2 3 5) (using the sample implementation with Gambit v4.6.0). * Related to above: The following yields true (using the sample implementation), perhaps suggesting an inconsistency between the SRFI and implementation on which "side's" (inner v. outer) dimension is specified by the second argument to array-curry. (Perhaps this is linked to the left- v. right-dimension confusion for interval-curry noted above.) (equal? ((array-getter A) 2 3 5 7) ((array-getter ((array-getter B) 2)) 3 5 7)) => #t * array-curry: I am having trouble interpreting the statement: The type of the subarrays is the same as the type of the input array. Here, does "type" refer to the mutability or domains of the (sub)arrays, or Scheme types, or something else? * array-permute: I don't think I understand the significance of the subtlety noted in the explanation (regarding permuting arguments, etc.). Is it a result of the convention used for permuting intervals, and similar to the "usual" confusion when multiplying permutations (cf. Knuth TAOCP 7.2.1.2."A general framework"), or something else? I suppose it doesn't really matter for the purpose of the SRFI, but I got the feeling I am missing some point here. * (minor, formatting) Some (pseudo)code in the array-permute section seem to be missing 'pre' tags or some such. * interval-reduce (and array-reduce): The order of the arguments in invocations of the provided 'operator' seems to differ from that used by the analogous (I think) reduce procedure from SRFI 1. Is this difference intentional? * Related to above: interval-reduce and array-reduce seem closer to SRFI 1's 'fold' than to its 'reduce' procedure (though the above comment applies in either case). * Would it make sense to include array-fold (and interval-fold) either in addition to or instead of the -reduce procedures? * array-body: Is the returned object the same as the object created by an application of the maker argument to the storage-class of the array? (A clarification near its definition may help; I found things hard to follow.) -chaw