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 |

Re: SRFI 122 draft 12 comments

*Bradley Lucier*26 Sep 2016 20:37 UTCThank you for your comments. My responses are interspersed. Changes are in my local copy for now, which I will put on github later. On 09/24/2016 08:00 PM, Sudarshan S Chawathe wrote: > These 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. Originally I had *->list and *->vector procedures. Both these procedures provided new copies of the data. I then followed a suggestion to get rid of the *->list procedures. John Cowan suggested that I say what happened if someone later modifies an argument to make-interval or the result of the *->vector procedures; the answer is nothing, I make a copy of the vectors going in and a copy of the arguments coming out. So, should I now rename the *->vector procedures? > > * (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. Some places I use <pre>, some places I use <blockquote>, <code>, and <var> (mainly where the code involves arguments to procedures). I changed this one instance to make it clearer. > > * (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.) Changed. > > * interval-curry: In the explanation, there is an instance of > left-dimension that should probably read right-dimension. Fixed. > > * (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.) A multi-index is not a list, it is what's returned by "values". What "values" returns is not reified in Scheme, it can only be consumed in a closure accepting multiple values. If you want to call what's returned by "values" a tuple, then a multi-index is a tuple, not a list. I realized that interval-reduce can be defined in terms of array-reduce (just introduce an appropriate array by (make-array interval f) and apply array-reduce), so I eliminated 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. I changed the earlier reference to refer to the "dimension" of a permutation. > > * 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. Fixed (I think). > > * array-map: Should the constraints on f be noted (although they > can be inferred)? I added a sentence of explanation. > > * 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. Fixed. > > * 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). Wow, you are a close reader. Fixed by defining B as (array-curry A 1). (I changed the second argument from the left dimension to the right without changing the example.) > > * 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 You're right, I fixed the example, I think > > * 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? I added a sentence of explanation. > > * 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. Many mathematics textbooks specify a permutation by giving its range, with the domain elements implicit, so the permutation function 1->2, 2->1, 3->4, 4->5, and 5->3, or the set of ordered pairs (listed in order of the first element of the pairs, i.e., the domain element) $$ \{(1,2),(2,1),(3,4),(4,5),(5,3))\} $$ is written as $$ (2 1 4 5 3). $$ It didn't seem natural to me to work with permutations in this way, so this SRFI we list the pairs in increasing order of the second elements of the pairs (the range): $$ \{(2,1),(1,2),(5,3),(3,4),(4,5)\} $$ and then I specify the first elements, with the second elements implicit: $$ (2 1 5 3 4) $$ I didn't want to say too much about what I don't do, and rather spend the time explaining what I *do* do. I can't find the word "framework" in TAOCP 7.2.1.2 from http://www.cs.utsa.edu/~wagner/knuth/fasc2b.pdf > > * (minor, formatting) Some (pseudo)code in the array-permute section > seem to be missing 'pre' tags or some such. Yeah, sorry, I can't mix mathjax $\pi$ with <pre>, so I'm stuck with this formatting. > > * 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? I'll have to think about this. To do fold-right properly one should introduce a function (array-reverse A), which contains the same entries as in A, with the same domain, only in reverse lexicographical order. Maybe that's the way to go. > > * 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.) It's *an* "object created by an application of the maker argument to the storage-class of the array". But after a specialized array has been curried, permuted, and translated, the array elements themselves might occupy only a small subset of the body, and be stored in a rather strange order. Do you think something needs to be said? Brad