On 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