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: For draft 14 (Re: SRFI 122 draft 12 comments)

*Bradley Lucier*09 Dec 2016 18:28 UTCOn 12/03/2016 05:06 PM, Sudarshan S Chawathe wrote: > Sorry for being very late in following up on this message. > > I am including below some comments on the few items from the earlier > message that still apply to the recent draft 14, dated 2016-11-28. (I'm > also working through draft 14 more systematically and hope to post some > (mostly minor) additional comments by tomorrow.) > >>> * 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 > > I think this is very similar to the issue addressed in Knuth's > discussion of permutations. I agree. It appears on pages numbered (printed) 8 > and 9 in the above copy (PDF page numbers 12, 13). Searching for > 'framework' indeed gives no results; something to do with the PDF > encoding perhaps. > > I am not sure if using the other convention for applying a permutation > to a sequence (array/interval indices in the present case) would help > any (probably not, as it would just reverse the problem). I've thought about it a lot and the one in the document is the best I've come up with. > The main > issue seems to be that the semantics of array-permute require the > ability to 'apply' both the given permutation and its inverse, which I > guess is a bit awkward implementation-wise. Ah, implementing any of these operators requires both the basic operation and its inverse (one applied to the interval domain, the other applied to the arguments to the getter/setter). I tried to carefully note this in the section "Common transformations on Bawden-style arrays". > >>> * (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. > > Still minor, of course, but for what it's worth, given the either-or > situation, my preference would be formatting without mathjax. It's > probably just a reflection of my difficulty with reading unindented > code, though. I decided to use pure HTML to format this pseudo-code, with the HTML entity for pi, so I think this will be fixed in the next release. > >>> * 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? > > I think so. The new draft (14) doesn't seem to explicitly define > array-body explicitly at all, unless I missed it somehow. I'm at a loss here. Give me a sentence to add and tell me where you think it should be added. Brad